BenchmarkStructByValue与BenchmarkStructByPtr对比需禁用内联、防止优化、确保内存访问真实发生，并用b.ReportAllocs()和globalResult避免消除，结构体宜≥32字节且需检查逃逸。
基准测试中 go test -bench 怎么写才公平
直接用 BenchmarkStructByValue 和 BenchmarkStructByPtr 对比，结果大概率失真——因为编译器可能内联、消除或重排操作。必须确保被测逻辑不可被优化掉，且每次迭代都真实触发内存访问或函数调用开销。
实操建议：
- 用
b.ReportAllocs()开启内存分配统计，确认两种方式是否意外触发堆分配 - 将计算结果赋值给全局变量（如
globalResult = ...），防止整个循环被优化为无用代码 - 避免在基准函数里做初始化（如构造大结构体），应提前提前放到
BenchmarkXxx函数外，或用b.ResetTimer()在热身之后再计时 - 运行时加
-gcflags="-l"禁用内联，否则指针版本的函数调用可能被抹平，掩盖真实调用成本
struct 大小如何影响 copy 开销
Go 中值传递本质是内存拷贝。当结构体超过几个字节，拷贝成本就不可忽略；而指针始终是 8 字节（64 位系统）。但“多大算大”得看具体场景和 CPU 缓存行（通常 64 字节）。
常见错误现象：测试一个只有两个 int 的结构体，发现值传递反而略快——因为小结构体可能被寄存器承载，且避免了指针解引用的间接跳转。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 测试对象至少包含 4 个字段以上，或总大小 ≥ 32 字节（例如
[8]int64或含字符串/切片的结构体） - 用
unsafe.Sizeof(T{})显式确认实际大小，注意字段对齐带来的 padding - 如果结构体含
[]byte或string，值传递只拷贝 header（24 字节），不复制底层数组，此时差异变小，但要注意逃逸分析是否把数据推到堆上
如何避免逃逸干扰基准结果
值传递可能让原本栈上的结构体因过大而逃逸到堆，指针传递则大概率保持栈分配（除非显式取地址后传给逃逸函数）。一旦发生堆分配，malloc 和 GC 压力会污染性能数据。
使用场景：结构体字段含指针类型（如 *sync.Mutex）、或作为返回值传出、或被闭包捕获时，极易触发逃逸。
实操建议：
- 用
go build -gcflags="-m -l" main.go检查关键结构体是否逃逸 - 在基准函数中避免返回该结构体、避免传入
fmt.Println等可变参函数（它们接收interface{}，强制装箱逃逸） - 若需打印调试，改用
fmt.Printf("%p", &v)这类不依赖反射的方式
真实示例：对比 64 字节结构体的传递开销
下面是一个可控、可复现的基准测试片段，聚焦拷贝与解引用的核心成本：
var globalResult MyStruct
type MyStruct struct {
A, B, C, D int64
E, F, G, H [8]byte
}
func BenchmarkMyStructByValue(b *testing.B) {
s := MyStruct{A: 1, B: 2}
b.ReportAllocs()
b.ResetTimer()
for i := 0; i < b.N; i++ {
s.A++
s.B++
globalResult = s // 防止优化
}
}
func BenchmarkMyStructByPtr(b *testing.B) {
s := &MyStruct{A: 1, B: 2}
b.ReportAllocs()
b.ResetTimer()
for i := 0; i < b.N; i++ {
s.A++
s.B++
globalResult = *s // 强制解引用并赋值
}
}
运行命令：go test -bench=.^ -benchmem -gcflags="-l"
注意点：两次都用了 globalResult = ... 来保证副作用；*s 解引用是必须显式写的，否则循环体为空；-bench=.^ 匹配所有 benchmark 函数。
真正难控制的是 CPU 缓存局部性——值传递可能让多个副本分散在不同 cache line，而指针共享同一块内存。这种效应在高并发压测时才会明显暴露，单 goroutine 基准很难反映全貌。
