值接收器在结构体≤16字节时更快，因缓存友好且避免解引用与逃逸；但含sync.mutex、需修改字段或接口方法用指针接收器时必须用指针。
结构体≤16字节时值接收器反而更快
现代CPU缓存对紧凑数据更友好，而指针多一次解引用（*p），还可能触发逃逸到堆上。实测中，struct{X, Y int64}（16字节）、time.Time（24字节但字段布局紧凑）、甚至含string字段的小结构体（只拷贝16字节header）走值接收器，在高频路径（如HTTP中间件）中常比指针接收器快10%–30%。
常见错误现象：看到“结构体大就该传指针”，给Point这类小类型盲目加*，结果引入不必要的解引用延迟，还让编译器更难内联。
- 用
unsafe.Sizeof查真实大小，别数字段个数 - 含
[]byte、map[string]int的结构体，即使unsafe.Sizeof只有24字节，值接收器也会复制header，后续写操作仍可能触发底层数组重分配 - 禁用内联测试：
go test -gcflags="-l" -bench=.，否则编译器可能把两种调用都优化成直接展开，掩盖真实差异
必须用指针接收器的三种硬性场景
性能不是唯一决定因素，语义和正确性往往更关键。以下情况不传指针，代码根本跑不通或逻辑错乱：
- 结构体含
sync.Mutex等不可拷贝字段——编译直接报错：cannot assign to struct field ... (unaddressable) - 方法需修改接收者字段（如
func (u *User) SetName(name string)）——值接收器改的是副本，原变量不变 - 结构体已实现某个接口，且该接口方法用的是指针接收器（如
func (u *User) GetName() string）——传User{}字面量会报错：User does not implement Namer
注意：User{}是不可寻址字面量，连&都取不了；而var u User; u.GetName()能自动取址，这是编译器语法糖，但底层仍是传指针。
逃逸分析比传值/传指针选择影响更大
一个局部变量只要被取地址并传出作用域（比如返回&s、传给goroutine、存入map），就注定逃逸到堆，此时再纠结“拷贝16字节还是8字节”意义不大。真正要盯的是go build -gcflags="-m -l"输出里的escapes to heap提示。
- 如果
BenchmarkByValue也显示escapes to heap，那值传递没省下拷贝，反而多了一次堆分配 - 用
b.ReportAllocs()统计基准测试中的堆分配次数，比单纯看ns/op更反映真实压力 -
globalResult = f(s)代替_ = f(s)，防止编译器优化掉整个调用链
同一结构体方法接收器类型应保持一致
一旦某个方法因需修改状态用了指针接收器（*T），其余方法最好全用指针接收器。否则会出现接口断层：调用方拿到&T能调所有方法，拿到T却只能调部分方法，语义边界模糊。
最常被忽略的是这种隐式不一致：func (u User) Validate() error（值） + func (u *User) Save() error（指针）。表面看没问题，但若User被嵌入到另一个结构体中，嵌入字段的方法集会因接收器类型分裂，导致接口赋值失败或意外行为。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
