该用指针接收者当需修改原值或类型较大，值接收者适用于小结构体且不修改原值；方法集差异导致T和*T接口实现不一致，混用易引发赋值错误。
方法定义时该用值接收者还是指针接收者？
看接收者是否需要修改原始值，以及类型大小。值接收者拿到的是副本，改了不影响原变量；指针接收者能改原值，也避免大结构体拷贝。
- 如果方法要修改接收者字段，必须用
*T（指针接收者） - 如果接收者是 map、slice、chan、func、interface 或指针本身，值接收者也“能改”——但这是底层引用语义的副作用，不是值接收者的本意，别依赖它
- 结构体字段多或含大数组/切片时，用
*T更省内存和 CPU - 小结构体（比如两个 int 字段）用
T或*T性能差异微乎其微，但要保持一致性：同一类型所有方法最好用同一种接收者
调用方法时报错 “cannot call pointer method on …”
典型现象：变量是值，却调用了指针接收者方法，或者反过来——Go 不会自动取地址或解引用，除非明确允许。
- 变量是值（如
v := MyStruct{}），只能调用T接收者方法；若只有*T方法，会报cannot call pointer method on v - 变量是指针（如
p := &MyStruct{}），既能调用*T方法，也能调用T方法（Go 自动解引用） - 接口赋值时更严格：接口变量存储的是具体值，如果接口要求的方法集包含
*T方法，你就不能用T类型的值去赋值，会报cannot use v (type T) as type MyInterface in assignment: T does not implement MyInterface (method Modify needs pointer receiver)
为什么同一个类型混用值和指针接收者会导致接口实现不一致？
因为 Go 的方法集（method set）对 T 和 *T 是不同的：值类型 T 的方法集只包含 T 接收者方法；而 *T 的方法集包含 T 和 *T 接收者方法。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 定义接口
type Sayer interface { Say() }，如果只有func (t T) Say()，那么T和*T都实现该接口 - 但如果接口还有
Modify()，且只有func (t *T) Modify()，那只有*T实现该接口，T不实现 - 所以不要在一个类型上一部分方法用
T，一部分用*T，除非你明确知道哪些值要满足哪些接口 - 常见坑：测试时传
&v没问题，生产代码里传v就 panic，因为接口断言失败
字符串、整数等基本类型能定义方法吗？
不能直接给内置类型（如 string、int）定义方法，但可以基于它们定义新类型，再为新类型定义方法。
立即学习“go语言免费学习笔记（深入）”；
- 正确：
type MyString string，然后func (s MyString) Len() int { return len(s) } - 错误：
func (s string) Len() int { ... }—— 编译报cannot define new methods on non-local type string - 注意：新类型不继承原类型的任何方法，哪怕名字一样、底层一样
- 如果想让新类型“兼容”原类型的方法，得自己重写一遍，或用嵌入（但嵌入只适用于 struct）
最常被忽略的一点：方法集规则不是语法糖，是编译期硬约束。写的时候看着能跑，一到接口赋值或泛型约束就暴露——别靠“好像能调通”来判断设计是否合理。
