b.ResetTimer()必须在初始化之后调用，因为基准测试默认从函数入口计时，若初始化代码（如make、JSON解析）位于其后，会错误计入ns/op，导致结果虚高或不可比。
热路径微基准测试不是比谁的 ns/op 数字小，而是看它是否真实反映了你最常调用、最不能慢的那一小段逻辑——测错位置、漏掉初始化、忽略分配，ns/op 再低也没用。
为什么 b.ResetTimer() 必须写在初始化之后？
基准测试默认从函数入口开始计时，但构造测试数据（比如 make([]byte, 1e6)、解析 JSON 字符串、预热 map）不属于被测逻辑。如果这些代码在 b.ResetTimer() 后面，就会被计入 ns/op，导致结果虚高或不可比。
- 错误写法：
data := make([]byte, 1e6); b.ResetTimer(); for i := 0; i ——make被计时了 - 正确写法：
data := make([]byte, 1e6); b.ResetTimer(); for i := 0; i - 若函数首次调用有明显 warm-up 效应（如 JIT 编译、page fault），可在
b.ResetTimer()后加一次 dummy 调用：f(data)，再进主循环 -
b.N是动态调整的，不是固定值；不要在循环里依赖它的具体数值做条件判断
-benchmem 不是可选项，是必开项
热路径往往高频调用，哪怕每次只多一次堆分配，上线后 GC 压力就可能指数级放大。ns/op 看不出这点，但 allocs/op 会直接暴露。
- 必须加
-benchmem，否则压根看不到B/op和allocs/op -
allocs/op == 0是热路径的理想状态；若为 1 或更高，要立刻查：是不是写了&MyStruct{}、make([]int, n)、str += "x"？ - 改用栈上结构体、
make([]int, 0, n)、strings.Builder，通常能归零allocs/op -
B/op是总字节数，allocs/op是次数——后者对 GC 更敏感；100 次 10B 分配比 1 次 1KB 分配更危险
怎么判断“快了 15%”是真的？
单次 go test -bench=. 输出的 ns/op 波动常达 ±10%，靠眼睛比数字毫无意义。显著性必须靠统计验证。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 至少跑
-count=5（推荐-count=10），用benchstat对比：benchstat old.txt new.txt -
benchstat用 Welch’s t-test 判定差异是否统计显著，并给出置信区间；它会告诉你“快了 12.3% ± 1.8%，p - CI 中拦截回归的标准不是“变慢”，而是“统计显著劣化 ≥20%”——太敏感会误报，太宽松会漏掉毛刺
- 对 I/O 类热路径（如序列化、磁盘写），方差 ≥25% 的结果行应直接忽略，共享 runner 的 I/O 噪声可能高达 ±90%
MB/s 怎么算出来？不手动设就等于没测吞吐
热路径如果是编解码、网络包处理、日志序列化这类吞吐敏感操作，ns/op 完全失焦。MB/s 才是关键指标，但它不会自动出现。
- 必须在
b.ResetTimer()前调用b.SetBytes(int64(len(data)))，告诉框架“这次迭代处理多少字节” - 传错单位后果严重：
b.SetBytes(1024)（1KB）和b.SetBytes(1024*1024)（1MB）输出的MB/s差 1000 倍，但ns/op可能几乎一样 - 适用场景明确：JSON 序列化、Protobuf 编解码、文件块读写、HTTP body 解析
- 若被测函数处理的是结构体而非原始字节，需先估算其序列化后大小，或用
binary.Size()/json.Marshal()预估
热路径微基准最难的不是写，而是确认你测的就是线上真正在跑的那条路——参数是否带真实分布、缓存是否预热、GC 是否被干扰、并发是否模拟到位。这些细节不控住，ns/op 就只是个好看的整数。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
