指针传递不一定更快，因小结构体值传可避免间接寻址、缓存未命中和堆分配；小于16字节时值传通常更优；指针易致逃逸增加GC压力；需用Benchmark实测对比。
为什么 Go 中指针传递不一定更快
Go 函数参数默认是值拷贝，但“用指针就一定省内存/提速”是个常见误解。是否提升效率，取决于被传递值的大小和使用方式。小结构体（如 struct{a, b int}）按值传可能比指针更快——因为避免了间接寻址、缓存未命中和逃逸分析导致的堆分配。
- 小于 16 字节的结构体，值传递通常更优（CPU 缓存友好，寄存器可容纳）
- 指针传递强制变量逃逸到堆上，增加 GC 压力（可用
go build -gcflags="-m"验证） - 如果函数内只读且不取地址，编译器可能优化掉部分拷贝，但无法依赖此行为
如何实测指针 vs 值传递的真实开销
用 testing.Benchmark 对比是最直接的方式。注意控制变量：确保被测函数逻辑一致，仅交换参数类型；避免编译器因无副作用而优化掉整个调用。
func BenchmarkStructValue(b *testing.B) {
s := MyStruct{X: 1, Y: 2, Z: 3}
for i := 0; i < b.N; i++ {
consumeValue(s) // 接收 MyStruct
}
}
func BenchmarkStructPtr(b *testing.B) {
s := &MyStruct{X: 1, Y: 2, Z: 3}
for i := 0; i < b.N; i++ {
consumePtr(s) // 接收 *MyStruct
}
}
- 运行
go test -bench=.查看 ns/op 差异 - 加
-benchmem观察 allocs/op，指针常带来额外堆分配 - 对大于 64 字节的结构体，指针优势才开始稳定显现
哪些场景必须用指针传递
性能不是唯一维度。以下情况指针是语义必需，而非单纯为“快”：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 需要修改原值（如
func reset(s *MyStruct)） - 类型实现了接口，且方法集包含指针接收者（否则无法满足接口）
- 结构体含
sync.Mutex等不可复制字段（Go 编译器会报错：cannot use ... as type ... in argument to ...: ... is not assignable） - 切片、map、channel 本身已是引用类型，再传指针通常是设计错误（除非真要替换底层数组头）
容易被忽略的逃逸陷阱
即使你没显式用 new 或 &，只要函数返回局部变量地址，或将其存入全局/堆结构，该变量就会逃逸。这时“看似值传”，实则已堆分配，指针传反而多一次解引用。
立即学习“go语言免费学习笔记（深入）”；
- 检查逃逸：运行
go build -gcflags="-m -l" main.go（-l禁用内联，让分析更准） - 常见逃逸点：闭包捕获局部变量、传入
fmt.Printf的非字面量参数、作为 map value 存储 - 若基准测试中指针版本 allocs/op 更高，大概率是逃逸 + 堆分配拖慢了整体表现
真正影响性能的，往往不是“传指针还是值”，而是数据布局、缓存行对齐、是否触发逃逸——这些比参数传递方式更底层，也更容易被忽视。
