[Gaoshou101]

v0.2.13 发版 PR：P1 的三项优化，以及版本号与文档更新。全部在本地模拟上游下完成验证，未访问真实上游，也未访问任何服务器。已 rebase 到包含 #14 的 main。

1. Linux glibc 要求从 2.34 降到 2.28（2bef63b）

原因：v0.2.12 的 .so 在 runner 的新 glibc 上构建，amd64 与 arm64 发布包的最高符号版本均为 GLIBC_2.34（另含 2.32）。CPA 宿主本身只要求 glibc 2.3.2。在 glibc 2.28 环境中，dlopen 加载 v0.2.12 正式包失败。

改动

• linux-amd64/arm64 改在 manylinux_2_28 容器中构建，镜像按摘要固定，复用 runner 上的官方 Go 工具链。
• 构建后用 objdump 校验符号版本 ≤ 2.28。
• 新增 CI 步骤：在 glibc 2.28 用户态内执行 dlopen，并跑 CPA v8.0.23 的 e2e、count_tokens 和思考后缀测试。
• package.py 在 BUILD.json 中记录 glibc_minimum=2.28 和 glibc_symbol_version_max。
• checksums.py --max-glibc 2.28 作为发布门槛（两处），并新增拒绝用例。

CI 结果：amd64 包实际只需 GLIBC_2.3.2，arm64 只需 GLIBC_2.17。

2. 减少运行数据写盘（b858ed0）

• requests.json、statistics.json、usage.json 及其检查点改为紧凑 JSON，结构不变。
• 后台写入时，按同一文件上次写入的大小把重写间隔折算成约 1 MiB/s，下限 250ms，上限 10s；插件关闭时立即写入全部待写文件。

合成测量（90 天 × 2 模型，共 21,768 个桶）：

项目	修改前	修改后
统计文件大小	9,823,672 B	7,450,959 B
统计文件持续写入速率	约 39.29 MB/s	约 1.05 MB/s（约 1/37.5）
1,000 条请求记录写入速率	约 3.92 MB/s	约 1.05 MB/s

代价：进程被强制结束时，大文件最多可能丢失约 10 秒内的变更。

3. 可选的首字节超时与流空闲超时（ab34339）

• first_byte_timeout_seconds / stream_idle_timeout_seconds：0 为关闭（默认），开启时 5–1800 秒；控制台与 YAML 均可配置，保存后立即生效。
• 触发时关闭上游连接，返回 504，错误类型 upstream_first_byte_timeout / upstream_stream_idle_timeout。
• 默认关闭：真实上游中长推理模型的首字节延迟和段间间隔还没有实测。
• 5 个单元测试；cpa_reliability.py 新增宿主联测（v0.2.12 DLL 失败、新 DLL 通过）；设置页浏览器实测可保存并回读。

4. 发布 v0.2.13（791b055）

• 版本号 0.2.13（types.go、registry.json），CHANGELOG / README / DEPLOYMENT / 发布说明 / CPAMP 集成说明同步，Linux 下载说明改为 glibc ≥ 2.28（注明 v0.2.12 及更早为 2.34）。
• CI 热升级联测的前一版本改为 v0.2.12。
• docs/VALIDATION.md 新增本轮验证记录。

本地验证（版本 0.2.13 的最终 DLL）

• go vet ./internal/... ./cmd/...、gofmt、go test ./internal/... ./cmd/... -count=1 通过；Node 31 项通过；test_cpamp_panel_validation.py（WSL）6 项通过。
• 实际 Windows CPA v8.0.23 和 v8.0.59 上各跑 9 项宿主联测，共 18/18 通过，包括以 v0.2.12 正式包为前一版本的同进程热升级（0.2.12 → 0.2.13）。

尚未验证

• 真实上游下超时的合适取值、思考后缀等级效果与 count_tokens 客户端行为；热升级是否清除宿主已记录的冷却。
• 真实 glibc 2.28 物理主机部署（目前为容器与 CI 验证）。