必须用指针接收者：当方法需修改结构体字段、操作map/slice、调用其他指针方法、实现含指针方法的接口、配合json.unmarshal等写入操作，或结构体含sync.mutex/*t字段时；值接收者仅适用于纯计算且不含引用类型的小型结构体。
必须用指针接收者的情况
方法要改结构体字段、往 map/slice 里写数据、调用其他指针方法、实现含指针方法的接口，或者配合 json.Unmarshal 等写入操作——这些场景下不用 *T 就会出问题。
常见错误现象：struct 字段没变，但代码里明明调用了 SetX()；或编译报错 cannot assign to struct field in argument to method；反序列化后字段全为零值，比如 json: Unmarshal(nil *T)。
-
json.Unmarshal(data, &v)要求v是指针，对应的方法接收者也得是*T，否则字段不会被写入 - 结构体含
sync.Mutex或*T字段时，值接收者会复制锁或指针，导致并发失效或 panic - 如果已有某个方法用了指针接收者，而你想让该类型满足某个接口，那所有方法都得统一成指针接收者，否则
T无法满足该接口
值接收者不是“只读保险丝”
值接收者看似安全，实则容易掩盖逻辑缺陷。它不阻止你修改字段——只是改了白改。
适用场景很窄：纯计算型方法，如 Len()、String()、IsValid()，且结构体不含引用类型字段（map、slice、channel）或需同步的字段（sync.Mutex）。
- 字段全是
int、string等不可变类型时，值接收者没问题 - 但只要字段是
map[string]int，哪怕只读访问，也建议用指针接收者——避免意外触发 copy-on-write 或 map panic - 值接收者方法返回新实例（如
func (t T) WithName(s string) T）会让调用方误以为原变量已更新，易引发状态不一致
性能影响不能靠猜
小结构体（比如 3–4 个 int/string）用值接收者开销极低；但一旦含 []byte、大数组、嵌套结构或 map，拷贝成本立刻上升。
Go 不会自动优化大结构体的值传递，go tool compile -S 可看到实际内存拷贝指令。别依赖直觉，该测就测。
- 用
go test -bench=.对比func (t T) M()和func (t *T) M()的基准耗时 - 结构体大小超过 16 字节（常见阈值），优先考虑指针接收者
- 注意：编译器对空结构体或仅含指针字段的结构体可能做优化，但别假设它总生效
混用接收者是隐形炸弹
Go 允许同一个结构体上同时定义 func (t T) M() 和 func (t *T) N()，但会导致方法集分裂：只有 *T 有全部方法，T 只有值接收者方法。
这在泛型约束、接口赋值、反射调用时极易出错，而且 go vet 不报，IDE 很难提示。
- 定义接口
type S interface{ M(); N() }，只有*T能满足，T{}编译失败 - 导出类型一旦暴露了指针接收者方法，后续加值接收者方法会破坏下游兼容性
- 团队协作中，混用会让新人难以判断“该不该取地址”，增加调试成本
最常被忽略的是：方法集差异不体现在调用语法上（t.M() 和 t.N() 都能写），而是在类型约束和接口实现层面静默失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
