release: prepare v0.6.0-preview

PERFORMANCE.md

@@ -13,13 +13,25 @@ python3 scripts/verifyPerformance.py --load --output /tmp/goOmniPerf.json
 
 # 只运行独立进程矩阵，默认每档 2 秒、3 轮
 go run ./internal/perfcheck --duration 2s --count 3 --output /tmp/goOmniPerf.json
+
+# 在 Linux Docker 容器内固定运行 race、vet、build 和 TLS 压测
+python3 scripts/verifyLinux.py --load --tls --duration 30s \
+  --concurrency 128 --idle 512 --count 1 \
+  --output performance/linuxSoakTLS.json
+
+# 发布候选验收可把持续流量延长到 30 分钟
+python3 scripts/verifyLinux.py --load --tls --duration 30m \
+  --concurrency 128 --idle 512 --count 1 \
+  --output performance/linuxSoakTLS-30m.json
 ```
 
 可通过 `--concurrency 1,32,128` / `--idle 128,1024` 调整矩阵；传空字符串可跳过对应场景。工具只监听本机随机端口，每个场景启动独立服务进程，并在结束后关闭客户端、检查连接排空、关闭服务。响应状态、完整响应体、requestId 或传输错误均计入失败，不能把快速返回的错误页算成成功吞吐。
 
+Linux 验收脚本使用 `golang:1.25` 容器，固定执行 `go test -race ./...`、`go vet ./...`、`go build ./...`，再按参数运行 perfcheck。perfcheck 在 Linux 读取 `/proc/self/fd`，报告连接建立期间的文件描述符峰值以及回收后的数量；同时记录服务端堆、goroutine、连接数和累计 accept 数。30 秒报告用于快速回归，30 分钟命令用于发布前持续压测。
+
 ## 2026-09-21 本机测量
 
-环境：Go 1.25.0、darwin/arm64、Apple M2 Max、GOMAXPROCS=12。网络实现来自 `3d5f225` 工作树（native 与 v0.5.0 相同）；本次新增测量工具，不修改服务端实现。原始测量值见 [tcpBaseline.json](performance/tcpBaseline.json)。报告时间为 UTC，北京时间是 9 月 21 日。
+环境：Go 1.25.0、darwin/arm64、Apple M2 Max、GOMAXPROCS=12。网络实现来自 `3d5f225` 工作树（native 与 v0.6.0-preview 相同）；本次新增测量工具，不修改服务端实现。原始测量值见 [tcpBaseline.json](performance/tcpBaseline.json)。报告时间为 UTC，北京时间是 9 月 21 日。
 
 每个并发档位持续约 2 秒、重复 3 轮，每轮交替标准库/native 的先后顺序。下表为各指标的三轮中位数；全部流量场景共完成 **2,660,828** 次请求，错误 **0**。另有 128 / 1,024 条空闲长连接的建立、保持和回收测试。
 
@@ -48,6 +60,7 @@ go run ./internal/perfcheck --duration 2s --count 3 --output /tmp/goOmniPerf.jso
 - 并发模型为闭环：每个 worker 等上一个请求完成后发下一个。实际经过时间包含最后请求排空；吞吐只计算成功响应。不能据此推断开放到达流量下的排队或过载表现。
 - 延迟从客户端发起请求到完整响应校验完成，包含失败请求。直方图使用每个 2 的幂区间内 16 档，报告桶上界，舍入误差至多约 6.25%。小幅差别不应过度解释。
 - 服务端 `runtime.MemStats` 通过独立 stdin/stdout 控制通道读取，客户端内存不计入。累计分配差值包含少量采样开销。堆峰值每 200 ms 采样，可能错过瞬时峰值；这些指标不是进程 RSS。
+- Linux 文件描述符来自服务端子进程的 `/proc/self/fd`，包含标准输入输出、监听 socket 和连接；macOS 等没有该路径的平台会省略该字段。回收后的数量应回到启动附近，不能代替内核 socket 缓冲或 RSS 测量。
 - 空闲场景在所有连接完成健康请求后做 GC 再采样。新增堆内存包括连接、缓冲区及分摊的运行时开销。`after` 为客户端断开并排空后一次 GC，`afterReclaim` 为第二次 GC，用于观察对象池缓存释放。
 - native 配置上限为 8,192 连接 / 4,096 活跃请求；本轮并发低于上限，未验证过载保护容量。标准库没有同样的并发闸门；比较包括各自真实实现的开销。
 - 可用 `python3 scripts/verifyPerformance.py --load --tls --duration 2s` 运行 TLS 版本的独立进程矩阵。该模式在每个子进程生成短期自签名证书，客户端仅用于本机基准验证；本报告的历史表格仍是无 TLS 数据。
@@ -60,10 +73,12 @@ macOS arm64 本机的 5 秒 TLS 矩阵见 [tlsBaseline.json](performance/tlsBase
 
 Linux arm64 容器使用 Go 1.25.14、GOMAXPROCS=4 运行 3 秒矩阵，见 [tlsBaselineLinux.json](performance/tlsBaselineLinux.json)：1 / 32 / 128 并发和 128 / 512 条空闲连接均为 0 错误；native 在 128 并发约 99,876 req/s，512 条空闲 TLS 连接的服务端堆增量约 4.47 MiB，连接关闭后 goroutine 回到基线。容器验证同时通过全量 race、vet、build。
 
+Linux arm64 的 30 秒高并发回归见 [linuxSoak.json](performance/linuxSoak.json) 和 [linuxSoakTLS.json](performance/linuxSoakTLS.json)：两份报告均使用 128 并发流量和 512 条空闲连接，所有场景错误为 0；native 非 TLS 约 146,614 req/s、TLS 约 149,720 req/s，空闲连接堆增量分别约 2.57 MiB 和 4.47 MiB，FD 均由 7 增至 519 并回到 7，goroutine 均回到启动附近。
+
 `BenchmarkTransportTCPApplicationRequest/{nethttp,native}/concurrency{1,32,128}` 使用同一测试入口、客户端、应用与响应检查。原先独立的 `BenchmarkNativeApplicationRequest` 已合并，避免两个入口配置漂移。`verifyPerformance.py` 会一并运行。
 
 并行 benchmark 的 **`ns/op` 是总经过时间除以请求数，反映吞吐成本，不是单请求延迟**。`B/op` / `allocs/op` 统计同一进程中的客户端与服务端总分配。此前报告的 native 15.4–16.7 µs/op、约 7.8 KB/op、100 allocs/op 应按这个含义理解，不能作为服务端延迟或独立内存指标。
 
 `BenchmarkTransportRouteDispatch` 和 `BenchmarkTransportApplicationRequest` 继续保留，分别测进程内路由分发和完整框架处理链；不包含 TCP，不能直接与上述网络延迟比较。
 
-后续优先补 Linux 目标环境、持续压测、大请求体/慢客户端、连接反复建立回收和协议边界验证，再通过 profile 决定是否优化对象分配或事件状态机。
+后续通过 30 分钟命令完成发布前持续压测，并在目标反向代理和部署环境继续观察内核 socket 缓冲、FD 上限与真实业务流量；再通过 profile 决定是否优化对象分配或事件状态机。