Go E06：PGO 在真实负载下有无收益

E05只换了 HTTP 路由器。现在回到原任务服务的实际负载：同一个 Go 1.27.1 工具链，给编译器提供一份代表性 CPU profile，构建 PGO 开关两版程序，然后让真实进程完成同一批任务。完整源码和原始结果在素材包，另有SHA-256及独立复跑说明。

profile 是输入，不是收益证明

下列 profile 与耗时数字来自初版 Linux 实验，原始输出保留在包内 evidence/E06/。2026-10-12 的 Darwin/arm64 补齐复跑使用同一 Go 1.27.1 源码、实际训练 profile 和运行前记录摘要的两版二进制：训练同形负载 off/on 中位 106.838/112.170ms，比值 1.050；留出负载 102.627/113.742ms，比值 1.108，两组均观察到退化。新原始记录位于仓库 writing-plans/go-language/completion/evidence/pgo/；不同平台和轮次的绝对耗时不能互相替换。

固定 BenchmarkTaskAnalyzeContext 已有输入 "Go one two 你好 " * 128，跑三秒 CPU profile 得到 train.pprof；原始文件与 SHA 均保留。go tool pprof -top 的实际样本中，stats.analyzeContextWith flat 2450ms，占 75.38%，其余包括 UTF-8 解码与 Unicode 空白识别。profile 说明这次训练时间花在哪里，不能由 top 表直接推出哪条 HTTP 请求会更快。

固定工具链 go help build 明确支持 -pgo file 和 -pgo=off。从同一源码分别运行 go build -trimpath -pgo=off 与 go build -trimpath -pgo=train.pprof，生成两个独立可执行文件；go version -m 在后一版显示 build -pgo=train.pprof，字节 SHA 不同。基准产物 20,115,913 字节，PGO 产物 20,103,313 字节；二进制大小的变化不是吞吐收益。传入不存在的 profile 实际构建非零、无产物，防止误以为编译器在静默跳过实验。

把未训练的输入也放进账本

verification/E06-load.py 启动真实 loopback 任务服务进程，每次先跑八条预热任务，再计时 100 条 POST/按实际 ID GET 到终态；每条都要 SUCCEEDED 且词数正确，进程响应 SIGTERM 后退出 0。训练同形输入为 512 词，留出输入 "新任务 🌟 now " * 96 为 384 词；后者没有参加 profile 采样。两个二进制在相同 worker、队列上限和运行环境各跑五轮，按 off/pgo 交替并反序，不用一次最好值代替对照。负载使用原服务内存存储，不把 PostgreSQL 等待混入这个 CPU 对照。

此次原始 summary.stdout：训练同形输入关闭 PGO 的中位数为 138.304ms，启用为 131.675ms；PGO/off = 0.952。未参与训练的输入关闭 PGO 为 127.717ms，启用为 130.657ms；比值 1.023，本机观察到退化。各轮范围彼此重叠，这不是统计上证明某版更快或跨机器的固定收益；测量包含 HTTP 解析、进程调度、任务排队和本机 loopback，profile 却来自分析器基准。两条结论能同时成立：构建确实消费了 profile，本轮整体服务负载没有稳定的全面增益。

练习：①只看 go tool pprof -top 就声称服务快了，漏了什么？答：漏了相同源码的 off/pgo 构建、相同负载重复测量、业务正确性和留出输入。②未训练输入 PGO 中位数变大是否要删掉结果？答：不能；保存全部原始轮次和波动，报告退化及因果的不确定性。③内存 HTTP 的 100 条任务测量可以外推 PostgreSQL 请求耗时吗？答：不可以；真正数据库回归单独验证正确性，未做 SQL PGO 性能对照。

同名包在新目录重采 profile、独立构建两版二进制、复测两类输入各五轮，再做真 PostgreSQL 两包测试/race 和旧 CLI；网站页面与下载另验。无 race 报告只覆盖执行路径；其他 CPU、远端、全站构建与部署均 NOT_RUN。E07把复用的客户端移到单独 module，再检查 workspace 是否掩盖依赖。