方法接收者用 T 还是 T 取决于是否需修改原值：只读用 T，修改必用 T；结构体大时 T 可减拷贝开销；混用导致方法集不一致；sync.Mutex 等状态类型必须用 T 且禁止复制。
方法接收者用 *T 还是 T？看值是否要被修改
Go 中方法接收者本质是函数的第一个隐式参数，T 是值拷贝，*T 是指针拷贝。关键不在“性能”，而在“语义”：你是否需要在方法内修改原值？
- 如果方法只读字段（比如
String()、Len()），用T更清晰，调用方无感知，也避免意外修改 - 如果方法要改字段（比如
Reset()、SetID()），必须用*T，否则改的是副本，原值不变 - 结构体很大（比如含切片、map 或大数组）时，值拷贝开销明显，即使只读也建议用
*T—— 但这是次要原因，别本末倒置
混用 T 和 *T 接收者会导致方法集不一致
这是最常踩的坑：同一个类型，T 和 *T 的方法集完全不同。接口实现、方法调用、甚至编译都可能因此失败。
-
var v T只能调用T接收者的方法；&v才能调用*T接收者的方法 -
var p *T既能调用*T方法，也能调用T方法（Go 自动解引用） - 如果某个接口要求
Do() error，而你只给*T实现了它，那么T{}类型值无法赋给该接口变量 - 错误示例：
type MyInt int; func (m MyInt) Get() int { return int(m) }; var x MyInt; var i interface{Get() int} = &x // 编译失败：*MyInt 没实现 Get
sync.Mutex 必须用指针接收者，且不能复制
这是典型因忽略接收者语义引发 panic 的场景。Mutex 是运行时需跟踪锁状态的类型，值拷贝会破坏其内部一致性。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 所有标准库中带状态的类型（
sync.Mutex、bytes.Buffer、strings.Builder）都只提供*T接收者方法 - 哪怕你写
func (m Mutex) Lock()，Go 编译器也会报错：不能在不可寻址值上调用指针方法 - 更隐蔽的问题：把含
sync.Mutex的结构体作为函数参数传值，或放入 map/slice 后再取出来调用方法，都会触发 “copy of locked mutex” panic - 正确做法：始终用指针传递、存储、调用，且确保结构体本身不可复制（可加
mu sync.Mutex // +build ignore注释提醒，或用-copylocksvet 检查）
接收者选择对逃逸分析和内存分配有实际影响
值接收者可能导致不必要的堆分配，尤其当编译器无法证明该值生命周期局限于栈上时。
立即学习“go语言免费学习笔记（深入）”；
- 例如：结构体较大，又作为返回值或闭包捕获变量，
T接收者容易触发逃逸到堆；*T则大概率保持栈上地址不变 - 用
go build -gcflags="-m -l"查看逃逸分析结果，关注类似... escapes to heap的提示 - 但别过早优化：小结构体（如两个 int 字段）用
T或*T在性能上几乎没差别，优先保证语义正确 - 真正要注意的是：不要因为“听说指针快”就统一全用
*T，反而让代码难以推理——比如一个纯计算型方法突然能改状态，调用方会懵
