值类型 T 无法实现含指针接收者方法的接口，只有 T 可以；因 T 的方法集不包含 T 接收者方法，接口实现是编译期静态检查，仅看方法集是否完整覆盖接口签名。
值类型 T 无法实现含指针接收者方法的接口，只有 *T 可以——这不是语法糖能绕过的规则，而是编译器严格按方法集校验的结果。
为什么 T{} 赋值给接口会报错 “does not implement”
错误现象：cannot use myStruct{} (type MyStruct) as type MyInterface in assignment: MyStruct does not implement MyInterface (Value method has pointer receiver)
根本原因不是“没写对”，而是 MyStruct 的方法集里压根没有 Value 方法——它只属于 *MyStruct 的方法集。Go 不会因为你能写 myStruct.Value() 就认为 myStruct “拥有”这个方法；那只是编译器对可寻址值自动加 & 的调用便利，不改变类型归属。
- 接口满足是编译期静态检查，只看类型的方法集是否完整覆盖接口方法签名
-
T的方法集 = 所有接收者为T的方法 -
*T的方法集 = 所有接收者为T和*T的方法 - 只要接口中任意一个方法的接收者是
*T，T就不可能满足该接口
如何快速验证某个类型是否真实现了接口
最可靠、零运行时开销的方式是编译期断言：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
var _ MyInterface = (*MyStruct)(nil)
如果编译通过，说明 *MyStruct 确实实现了 MyInterface；报错则直接指出缺哪个方法、接收者类型是否匹配。比 reflect.TypeOf(t).Implements() 准确得多，后者在运行时无法区分值/指针接收者差异。
- 别依赖 IDE 提示：它只比对方法签名，不检查接收者类型是否落入该类型的方法集中
- 别在测试里用
interface{}(t).(MyInterface)断言来“验证”：那只是运行时行为，掩盖了编译期本可捕获的问题 - 查标准库文档（如
pkg.go.dev）：比如bytes.Buffer所有方法都是指针接收者，所以必须用&bytes.Buffer{}
嵌入结构体时，子类型能否满足父类型接口
取决于你嵌入的是 Parent 还是 *Parent：
-
type Child struct { Parent }：Child 的方法集不包含*Parent的方法（因为Parent是值嵌入，其提升方法的接收者仍是*Parent，而Child并不等价于*Parent） -
type Child struct { *Parent }：可以，*Parent的方法被提升后，接收者类型仍为*Parent，而Child包含一个*Parent字段，可寻址 - 常见坑：
Child{}无法赋值给某接口，但&Child{}可以——问题不在Child，而在嵌入字段本身的方法集归属
什么时候必须用指针接收者实现接口
当方法需要修改接收者状态时，必须用指针接收者——这不是接口问题，而是 Go 的值拷贝语义决定的。但一旦用了指针接收者，就锁死了「只有指针能实现该接口」。
- 典型场景：结构体字段赋值、
map/slice内容变更、sync.Mutex加锁等 -
sync.Mutex的Lock()和Unlock()都是*Mutex接收者，所以你绝不能把sync.Mutex{}当作sync.Locker接口值直接传——必须传&mu - 即使结构体很小（如两个
int），只要方法用了指针接收者，值类型就无法满足该接口 - 接口变量存储的是「动态类型 + 动态值」：把
T{}赋给接口，存的是值拷贝；把&T{}赋给接口，存的是指针——这直接影响方法调用时能否修改原值，也影响内存分配和逃逸分析
最容易被忽略的一点：方法集规则不是“能不能调用”，而是“类型归属”。你能写 t.Method()，不代表 t 满足含 Method 的接口——只要 Method 的接收者是 *T，你就得用 &t。
