传递结构体指针比值传递更快，因为大结构体值传参会触发完整内存拷贝，而指针仅复制8字节地址；但小结构体值传参更高效，且需结合逃逸分析与并发场景权衡使用。
为什么传递结构体指针比值传递更快
当结构体较大（比如字段超过 3–4 个，或含 slice/map/chan 等 header 类型）时，值传递会触发完整内存拷贝，而指针传递只复制 8 字节（64 位系统）。go 编译器不会自动把大结构体转为指针传参——这是开发者责任。
常见误判场景：type User Struct { ID int; Name String; Email string; Avatar []byte }，其中 Avatar 是 slice，其底层数据不随结构体拷贝，但 slice header（24 字节）仍要复制；若 Avatar 长达几 MB，反复传值会显著拖慢函数调用性能。
- 实测：1KB 结构体在循环中值传参比指针传参慢约 1.8×（基准测试
BenchmarkUserValueVsPointer） - 编译器无法逃逸分析优化跨 goroutine 的大值传递，此时指针是唯一可控手段
- 注意：小结构体（如
struct{ x, y int }）值传递反而更高效，避免间接寻址开销
哪些函数签名该强制用指针接收者
方法接收者类型直接影响调用开销和语义。不是“所有方法都要用指针”，而是看是否满足以下任一条件：
- 方法内修改接收者字段（否则编译报错）
- 接收者是大结构体（建议 > 4 words，即约 32 字节）
- 类型实现了接口，且该接口被高频调用（如
io.Reader），值接收者会导致每次接口装箱都拷贝 - 结构体含 mutex（
sync.Mutex）等不可拷贝字段——值传递直接 panic："cannot copy sync.Mutex"
反例：func (u User) GetName() string 对大 User 不仅低效，还可能掩盖逃逸问题；应改为 func (u *User) GetName() string。
立即学习“go语言免费学习笔记（深入）”；
逃逸分析怎么看指针是否真省了内存
不能只凭直觉改指针——得验证是否真避免了堆分配。用 go build -gcflags="-m -l" 查看逃逸信息：
go build -gcflags="-m -l" main.go关键线索：
-
... moves to heap：该变量逃逸到堆，无论值/指针传参，都已失去栈优化意义 -
leaking param: ...：参数被返回或存入全局变量，强制堆分配 - 没输出逃逸提示 → 变量留在栈上 → 指针传参确实减少拷贝
注意：-l 禁用内联后结果更真实；生产构建默认开启内联，可能掩盖部分逃逸路径。
指针传递的隐藏成本：缓存行与 false sharing
在高并发场景下，盲目用指针可能引入新瓶颈。多个 goroutine 频繁读写同一缓存行（64 字节）里的不同字段，即使用不同指针访问，也会因 CPU 缓存同步导致性能下降（false sharing）。
典型例子：type Counter struct { Total, Failed, Retried uint64 }，三个字段紧挨着，多 goroutine 同时 c.Total++ 和 c.Failed++ 会竞争同一缓存行。
- 解决方式：用填充字段隔离热点字段，例如
Total uint64; _ [8]byte; Failed uint64 - 工具辅助：
go tool trace中观察 “Synchronization” 时间突增，可能指向 false sharing - 指针本身不解决并发争用——它只是让共享更廉价，但共享逻辑仍需设计
真正影响性能的从来不是“用不用指针”，而是“共享什么、谁在读写、频率多高”。指针只是把选择权交还给开发者，而不是交给编译器猜。