Go 35：profile 如何定位热点而不替代测量

上篇看到等待中的 worker 并不等于正在消耗 CPU。要找实际计算热点，先选负载，再采样；profile 给出下一步该改哪里的线索，改动是否有收益则要回到多轮基准与业务断言。本篇仍使用同一任务服务的 AnalyzeContext 和已完成任务 HTTP GET。工程包、SHA-256及独立复跑步骤带完整原始 profile。

一组 profile 必须注明两种负载

新增的 BenchmarkTaskAnalyzeContext 在计时循环外固定 strings.Repeat("Go one two 你好 ", 128)，每轮实际运行当前 worker 使用的 stats.AnalyzeContext，校对词数、字节和 rune 数以及错误返回；原有 BenchmarkTaskHTTPRead 则查已完成任务，检查 200/终态/词数。两者都在 profile 采样的进程里跑，但不是同一个业务路径。未开 profile 的五轮基线、原始 -cpuprofile 和 -memprofile 文件，以及 go tool pprof -top 原文分别存于 writing-plans/go-language/evidence/35/。采样运行与不采样 benchmark 分开，不能把采样时的纳秒数当成日常延迟。

旧版 CPU top 在这个混合负载中，stats.analyzeContextWith 为 0.62s flat/29.38%，unicode.IsSpace 为 0.19s flat/9.00%；还有 UTF-8 解码、JSON、运行时 profile 栈等条目。它提示词数分析里空白判断值得试一处改动，但这个百分比的分母包括 HTTP GET 和采样器。不能说“9% CPU 用在空白判断，所以改完必定快 9%”。

同一进程的 heap profile 以 go tool pprof -alloc_space 读取累计分配，不是默认的仍在使用中的堆空间。旧 top 包括 net/http.Header.Clone 38.79MB、net/textproto.MIMEHeader.Set 34.24MB、httptest.NewRecorder 14.86MB；其中 recorder 是基准自己每轮新建的响应对象。把这张图当成线上服务“一次请求的堆构成”会错：没有网络传输，而且每轮请求还是只查已有结果。BenchmarkTaskHTTPRead 的正常五轮仍稳定报告每次 1,232 B/14 allocs，这一指标和 profile 的按运行时样本累计 MB 是不同分母。

从热点到单处改动

只改变 stats/count.go:analyzeContextWith 的空白判断：ASCII 的 ' ' 与 \t 到 \r 直接判断，其他 rune 仍走 unicode.IsSpace。UTF-8 解码、每个 rune 的取消检查以及结果写入没有改变；测试额外纳入所有 ASCII 空白字符，并保留中文、非法 UTF-8 和取消闸门回归。若把 \v 或 \f 漏掉，AnalyzeContext 与原函数的词数会不一致，这些输入不是跑分之外的可选项。

改动后 profile 里 unicode.IsSpace flat 采样为 0.03s/1.49%，但主函数 analyzeContextWith 仍占显著 CPU，heap top 仍由 HTTP recorder、Header.Clone 等占据。不能把两个样本百分比相减解释为任务提速；CPU 采样随机、执行次数变化、profile 自身开销及总负载组合都会改变比例。

真正的复核来自旧提交 cc57a93b 的同一工程快照：旧源码在临时模块中编译，补入同一份新增 benchmark，按旧→新→新→旧顺序，各跑五轮。原始摘要是：

不带 profile 的词数分析	首轮五次 ns/op	倒序五次 ns/op	分配
旧版 `AnalyzeContext`	14,752–17,078	15,593–23,044	0 B/0 allocs
ASCII 空白快路径	12,791–13,770	13,170–21,972	0 B/0 allocs

第一组中位数旧 15,747、新 13,581 ns/op；倒序组新 15,498、旧 16,233 ns/op。中位数在本机两组均降低，区间却在倒序组重叠：这是一项有条件的观察，不是“性能提升 20%”的跨环境保证。HTTP GET 没有调用这段新判断，两边依旧 1,232 B/14 allocs，不能把它的耗时波动算进收益。实际完整服务还涉及入队、取消、数据库与关闭，其吞吐与任务延迟没有在此直接测量。

练习：① heap 的 alloc_space 顶部出现 Recorder，能否立即重写业务存储？不能；先确认它属于基准工具自身，换合适负载或分开采样，才知道业务分配。② unicode.IsSpace 样本比例下降能否代替多轮测量？不能，它提供的是热点方向，是否保留改动取决于相同负载的时间、分配和业务断言。③ 更新后的取消检查能否改为每 64 个 rune 一次以继续提速？本章未做这项改动；这会改变取消响应边界，必须另外制定契约、增加受控失败输入和退出确认，不能偷偷合入这次优化。

真实 PostgreSQL 16.15 的 SQL 回归、两包测试、race 的实际执行路径与旧 CLI 正反均在本章证据目录及完整包的独立复跑中；CPU/heap 文件不能替代 Go/SQL 的正确性检查。HTTP 202 与 worker 完成不同，数据库提交与外部副作用不同，race 无报告只限执行到的路径。远程网络、其他平台、含 35 的全站构建与发布仍 NOT_RUN。下一篇用 trace 与 block/mutex profile 把墙钟等待和 CPU 时间分开。