热路径基准测试必须用b.N控制循环、禁用time.Now()、显式隔离setup开销，否则测的不是热路径而是编译器优化后的空壳；常见错误是函数体未用b.N循环、误用常量导致被优化，需通过go tool compile -S验证关键函数未被inline消除。
热路径基准测试必须用 b.N 控制循环、禁用 time.Now()、显式隔离 setup 开销，否则测的不是热路径，而是编译器优化后的空壳。
为什么热路径 Benchmark 一跑就快得离谱？
常见错误是函数体里没写 for i := 0; i ，或者写了但被编译器“优化掉”——比如循环内只做无副作用赋值、或结果没被使用（<code>_ = xxx 没加）。Go 测试框架会检测到逻辑可被完全消除，最终 b.N 被压成 1 或直接跳过。
- 确认被测函数返回值是否被丢弃：必须用
_ = yourFunc(...)或赋给局部变量，否则编译器可能 inline + elide - 避免在循环里构造新对象（如
map[string]int{}）而不复用——这会把初始化成本算进热路径 - 检查是否误用了
testing.T：签名必须是func BenchmarkXxx(b *testing.B)，参数类型错一个字符（比如少*）就编译失败
b.ResetTimer() 和 b.StopTimer() 到底该在哪调？
热路径指“反复执行的核心逻辑”，它前面的预热、数据准备、缓存填充等都不属于热路径。不剥离这些，ns/op 就包含大量噪声。
-
b.StopTimer()放在循环前：做耗时 setup（如生成 1MB 测试 payload、初始化sync.Pool、warm up map hash seed） -
b.ResetTimer()紧跟其后：丢弃冷启动阶段（第一次 GC、page fault、CPU 频率爬升）造成的抖动 -
b.StartTimer()不需要显式调——ResetTimer()已自动恢复计时；除非你中间又StopTimer()了多次 - 错误模式：在
for循环内部反复Stop/Start，这会让实际执行次数远小于b.N，结果失真
怎么让 go test -bench 真正压出稳定热路径数据？
默认 -benchtime=1s 对热路径太短——尤其当单次 ns/op b.N 可能才刚到几万就停了，统计方差大。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 强制延长采样：用
-benchtime=5s或-benchtime=10000000x（指定迭代次数而非时间） - 排除环境干扰：加
-count=5运行 5 轮，用benchstat看 p 值是否 - 必须带
-benchmem：热路径常伴随高频小对象分配（如fmt.Sprintf），B/op比ns/op更早暴露问题 - 别信
-cpu=1单核结果：真实服务是多 GOMAXPROCS，建议至少测-cpu=1,4,8观察扩展性
HTTP handler 热路径压测容易漏的关键点
用 httptest 模拟请求看似简单，但 handler 内部常隐含状态依赖（如全局 http.ServeMux、未 reset 的中间件 context），导致每次迭代实际不是独立执行。
- 每次循环前重建
*httptest.ResponseRecorder和*http.Request：不能复用，否则 response body 被 consume 后第二次Write失败 - 若 handler 依赖
http.Request.Context()中的值（如 trace ID），需在每次循环中req = req.WithContext(...)重置 - 禁止在 handler 里调
log.Printf或fmt.Println：I/O 会放大方差，且b.N越大，日志锁争用越明显 - 真实服务有连接复用、TLS handshake 缓存等，
httptest测的是纯 handler 逻辑，和 wrk/ab 结果不可直接对比
热路径最危险的错觉，是看到 12ns/op 就以为没问题——可能只是编译器把整个循环优化掉了。务必检查输出里 b.N 是否合理（比如 >1e6），并用 go tool compile -S 确认关键函数没被 inline 消除。
