用途：在 Go 1.24+ 上测量并改进程序性能，适用于用 pprof、runtime/trace、flight recording 或 IDE 采集的 pprof 兼容剖析数据来诊断 CPU 热点、分配压力、堆增长、goroutine 堆积、调度延迟以及锁与 channel 竞争，也用于编写或修复基准测试并用 benchstat 对比性能变化，判断某项优化是否值得增加复杂度。
不适用：尚无实际性能问题的测量数据时不应优化；任务属于正确性、重构或 API 设计且无吞吐、延迟、资源关切时不适用；用户需要 Go 教程或一般代码审查时也不适用。
主要能力与用法：先复现问题并明确关键指标（ns/op、B/op、allocs/op、吞吐、尾延迟、暂停时间、goroutine 增长、CPU 饱和）。改代码前先补或修基准测试，Go 1.24+ 新写或修改的基准优先用 b.Loop()，除非仓库需兼容旧版本。多次运行并用 benchstat 对比，不信任单次结果。按症状选剖析类型：CPU 用于活跃计算，heap/allocs 用于内存，goroutine/block/mutex 用于等待与竞争，trace 用于调度时间线。优先修复主导成本（算法复杂度、重复工作、数据布局、过量分配、竞争），再重跑同一基准对比。代码路径正确且剖析具代表性后再应用 PGO。生产专属问题用 runtime metrics、net/http/pprof 或 flight recording 在真实服务条件下验证。
规则：优先算法或架构修复而非风格微优化；用基准证据和剖析支撑复杂度；长运行服务需剖析实际运行形态；仅跑基准用 -run='^$'；竞争或调度问题用 trace、block、mutex 工具；间歇性生产延迟可考虑 Go 1.25+ flight recorder。Go 1.26 下应重新测量旧变通方案，Linux 容器中 Go 1.25+ 默认 GOMAXPROCS 已感知容器，无实测理由不要照搬 automaxprocs；需要保留剖析输出时可用 testing.T.ArtifactDir 配合 go test -artifacts -outputdir ...。报告需说明瓶颈与证据、具体改动及预期影响的指标、前后基准或剖析差异，并指出残余风险、版本假设与生产环境缺口。