结构体大小是传值或传指针的关键分水岭：≤16字节优先值传递，≥64字节倾向指针；含引用类型字段或需修改状态时也应传指针；逃逸分析比传递方式更影响性能，压测验证才是最终依据。
传指针不等于性能优化，结构体大小是分水岭
go 函数参数默认值传递，复制整个结构体；指针只传 8 字节地址。但“更快”不是绝对的——Small{int, int}（16 字节以内）值传递通常比指针更快，因为避免了指针解引用、缓存未命中和潜在逃逸。而 LargeStruct{[1000]int, String, map[string]int} 这类超过 64 字节的结构体，指针传递在基准测试中常快 30%–50%，尤其在高频调用场景下。
- 经验阈值：结构体大小 ≤ 16 字节 → 优先值类型；≥ 64 字节 → 指针更稳妥
- 含
slice、map、chan或Interface{}字段的结构体，即使很小也建议传指针（头信息复制 + 易逃逸） - 别被“大”字误导：一个只有两个字段但含
[2048]byte的 struct 就算“大”，而time.Time（24 字节）因编译器深度优化，值传依然高效
方法接收者用指针，不只是为了性能
是否用指针接收者，首要判断标准不是性能，而是语义：是否需要修改原结构体状态。比如 (*Person).SetName() 必须用指针，否则改的是副本，调用方完全无感。
- 统一性更重要：同一类型的方法集应保持接收者一致（全用
*T或全用T），混用会导致方法集分裂，interface{}实现失效 -
sync.Mutex是典型反例：它必须按值传递，传*sync.Mutex可能引发竞态或误用（标准库所有方法都是值接收者） - 性能只是附带收益：对大结构体，指针接收者顺便省了拷贝；但对小结构体，强行用指针反而可能因逃逸推到堆上，得不偿失
逃逸分析比指针/值选择更关键
真正拖慢性能的往往不是一次拷贝，而是变量逃逸到堆上带来的 GC 压力。一个局部 Config 结构体，哪怕你传值，只要被闭包捕获或返回其地址，就会逃逸；而传指针有时反而让编译器更早确定生命周期，保留在栈上。
- 验证手段：
go build -gcflags="-m -l"查看“moved to heap”提示 - 常见逃逸诱因：
fmt.printf("%p", &x)、把局部变量地址传给未知函数、返回局部变量的指针 - 不要为“避免拷贝”而加
*：如果func f(s *MyStruct)导致MyStruct逃逸，那它已经失去栈分配优势，拷贝成本反而成了次要问题
压测才是唯一可信的依据
所有经验规则都只是起点。真实性能差异必须靠 go test -bench=. 验证，尤其当结构体处于 32–64 字节模糊区间，或涉及复杂字段嵌套时。
立即学习“go语言免费学习笔记（深入）”；
- 写两组 benchmark：
BenchmarkProcessValue和BenchmarkProcessPointer，确保输入数据构造方式一致（如都从new()或字面量初始化） - 关注
Benchmem输出：对比Allocs/op和Alloced B/op，高分配率往往比纳秒级差异更伤性能 - 并发场景额外检查：
go run -race main.go，指针共享不加锁就是数据竞争，再快也没用
最常被忽略的一点：性能优化的终点不是“用了指针”，而是“这个变量是否真的需要被共享、修改或频繁搬运”。很多时候，重构数据流、改用切片而非大数组、拆分臃肿结构体，比纠结指针符号有效得多。