结论：传指针或传值不影响 benchmark 框架开销，但显著影响被测函数性能；大结构体传值会复制，传指针仅传8字节地址，应确保被测函数实际操作数据以真实反映差异。
Go benchmark 中 func(b *testing.B) 里传指针还是值？
直接说结论：在 Benchmark 函数体内，对被测函数的调用方式（传指针 or 传值）**完全不影响基准测试本身的开销**，但会显著影响被测函数内部的性能表现——尤其是当结构体较大或有复制成本时。
很多人误以为 testing.B 的参数传递方式会影响 b.ResetTimer() 或 b.N 循环的效率，其实不会。真正耗时的是你反复调用的那个函数本身。
- 如果被测函数签名是
func(processData Data) {...}，每次迭代都会复制整个Data结构体 - 如果签名是
func(processData *Data) {...}，只传 8 字节指针（64 位系统），复制开销趋近于零 - 编译器几乎不会对大结构体的值传递做逃逸优化，尤其在循环中频繁调用时
怎么写才能真实反映“传值 vs 传指针”的差异？
关键在于：被测函数必须操作数据，且操作逻辑要触发复制或解引用行为；否则 benchmark 测的只是空壳。
常见错误是写成这样：
立即学习“go语言免费学习笔记（深入）”；
func BenchmarkValue(b *testing.B) {
d := Data{...}
for i := 0; i < b.N; i++ {
_ = d // 没调用任何函数，没触发复制语义
}
}
这根本测不出差异。正确写法要让编译器无法优化掉复制动作：
- 把结构体字段设为导出（首字母大写），避免内联/消除
- 在函数内对字段做读写（如
d.Field++），强制访问内存 - 返回结果并赋值给局部变量（如
res := processData(d)），阻止死代码消除
go test -bench 下结构体大小如何影响结果？
实测表明：当结构体超过 128 字节，值传递的 benchmark 结果通常比指针慢 3–10 倍（取决于字段数量和 CPU 缓存行填充）；小于 32 字节时差异常小于 5%，可忽略。
这不是玄学，是硬件层面的缓存与内存带宽限制。每次值传递都意味着一次完整的内存拷贝，而指针只是地址搬运。
- 用
unsafe.Sizeof(Data{})确认实际大小（注意 padding） - 避免嵌套大量小结构体，它们会累积 padding 开销
- 如果结构体含
[]byte、map、chan等 header 类型，值传递只复制 header（24 字节），但底层数据仍共享——这时性能差异反而可能反转
为什么有时指针版本 benchmark 更慢？
最常见原因是：指针引发额外的内存访问延迟或 false sharing，尤其在并发 benchmark（b.RunParallel）中。
比如多个 goroutine 同时修改同一结构体的不同字段，但这些字段落在同一个 cache line（64 字节）里，就会相互干扰。
- 用
go tool compile -S看汇编，确认是否真有MOVQ大块内存指令 - 检查是否意外触发逃逸分析，导致本该栈分配的结构体被抬到堆上
- 并发场景下优先用
sync.Pool复用结构体，而不是盲目传指针
真正的瓶颈往往不在“传什么”，而在“怎么用”——特别是数据布局和访问模式是否友好缓存。
