方法接收者该用指针而非值，因值接收者无法修改原始数据、导致接口实现不一致、内嵌类型方法不可见，且语义清晰性远重于小结构体拷贝性能。
Go语言中方法接收者该用值还是指针，取决于是否需要修改原始数据、类型大小、以及接口实现一致性——不是看“要不要改”，而是看“改了有没有效”和“会不会意外复制”。
修改字段必须用指针接收者
值接收者接收到的是结构体的副本，对字段的任何赋值都不会影响原变量。哪怕编译通过，运行时也毫无效果。
常见错误现象：func (u User) SetName(n string) { u.name = n } 调用后 u.name 完全没变。
正确做法是统一用指针：
立即学习“go语言免费学习笔记（深入）”；
func (u *User) SetName(n string) {
u.name = n // 这样才真正改到原结构体
}
- 只要方法名含
Set、Update、Reset等语义，几乎都该用*T - 即使结构体只有几个字段，只要逻辑上要“改状态”，就别图省事用值接收者
小结构体用值接收者也可能出问题
有人觉得 type Point struct{ x, y int } 很小，用值接收者“更高效”。但问题不在性能，而在方法集不一致。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
Go 的接口实现判定规则是：只有拥有相同接收者类型的方法才属于同一方法集。这意味着：
-
var p Point可以调用值接收者方法，但var pp *Point不能调用（除非显式解引用） -
var pp *Point可以调用指针接收者方法，而var p Point也能自动取地址调用——但反过来不行 - 一旦你混用，某个接口变量可能因传入值或指针而突然无法满足接口
典型报错：cannot use p (variable of type Point) as type fmt.Stringer in argument to fmt.Println: Point does not implement fmt.Stringer (String method has pointer receiver)
嵌套结构体和组合时必须统一接收者类型
如果类型 A 内嵌了 B，而 B 的方法用了指针接收者，那么只有 *A 才能“继承”这些方法；A 值本身无法访问。
示例：
type B struct{ v int }
func (b *B) Get() int { return b.v }
type A struct{ B } // 内嵌
var a A
a.Get() // ❌ 编译失败：a 是值，B.Get 要求 *B
- 只要内嵌类型有指针接收者方法，外层类型最好也统一用指针接收者定义方法
- 否则组合行为会断裂，尤其在实现接口或使用泛型约束时容易静默失败
性能差异通常不值得单独优化
现代 Go 编译器对小结构体（如 ≤ 2 个机器字）的值传递做了优化，拷贝开销极低。但“值 vs 指针”的真实代价不在内存，而在语义清晰性和维护成本。
- 用值接收者：适合纯函数式操作，比如
func (p Point) Distance(q Point) float64 - 用指针接收者：只要涉及状态变更、避免拷贝大对象（如
[]byte、map、大 struct）、或需保持接口一致性，就选它 - 没有“默认推荐值接收者”的场景——Go 标准库中绝大多数自定义类型方法都用
*T
最容易被忽略的一点：同一个类型的方法接收者类型必须保持一致。混用会导致方法集分裂，让接口断言、泛型类型推导、甚至测试 mock 都变得不可靠。
