T{} 不能直接赋给需指针接收器方法的接口，因为值类型 T 的方法集仅含值接收器方法，而 T 的方法集才包含指针接收器方法；故当接口方法由 T 实现时，T{} 不满足该接口。
接口赋值时 T{} 为什么不能直接赋给需要指针接收器方法的接口
因为 Go 的接口赋值检查的是「类型是否实现了接口」，而实现关系由方法集决定：值类型 T 的方法集只包含值接收器方法；只有 *T 的方法集才包含指针接收器方法。所以当接口 I 的方法是用 *T 实现的，T{} 就不满足该接口。
- 常见错误现象：
cannot use T{} (type T) as type I in assignment: T does not implement I (method XXX has pointer receiver) - 不是编译器“不自动取地址”，而是语义上
T{}和&T{}是两个不同类型的值，方法集不重叠 - 即使
T是小结构体、无副作用，Go 也不会隐式转换——这是显式性设计原则
什么时候必须用 &T{} 而不是 T{} 赋值给接口
只要接口中任一方法的接收器是 *T，且你没有为 T 单独定义对应值接收器方法，就必须传 &T{}。
- 典型场景：自定义类型带状态（如缓存、计数器）、需修改字段的方法，几乎都得用指针接收器
- 注意嵌入：如果
T嵌入了另一个类型S，而S的某个方法是*S接收器，那T自身仍不自动获得该方法在值类型上的实现 - struct 字段含 sync.Mutex 等非可复制类型时，Go 强制要求用指针接收器，否则无法编译
T{} 和 &T{} 在接口变量中的底层表现差异
两者都可被接口变量持有，但底层存储不同：值接收器实现时，接口里存的是 T 的副本；指针接收器实现时，接口里存的是指向堆/栈上 T 实例的指针。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 性能影响：大 struct 用值接收器 + 接口赋值 → 每次拷贝开销明显；指针则恒定大小（通常 8 字节）
- 生命周期风险：若
&T{}指向的是栈上临时对象（如函数内var t T; i = &t），逃逸分析会自动将其挪到堆上，不必手动干预 - nil 检查：接口变量本身非 nil，但内部指针可能是 nil —— 调用指针接收器方法前务必确认接收器非 nil，否则 panic
如何快速判断一个类型能否赋给某接口
别靠猜，用编译器报错或工具辅助验证最可靠。
立即学习“go语言免费学习笔记（深入）”；
- 把赋值语句写出来，看报什么错：如果是
does not implement I (missing method XXX)，就去查XXX的接收器类型 - 用
go vet -shadow或 IDE 的“Find Usages”跳转到接口定义和实现处对比接收器 - 临时加一行
var _ I = (*T)(nil)或var _ I = T{}，让编译器帮你断言（推荐放在 *_test.go 里） - 切记：同一个类型，
T和*T是两个独立类型，各自有独立方法集，互不继承
最容易被忽略的是：方法集规则对嵌入类型也生效，而且不传递。哪怕你写了 type MyInt int 并给 *MyInt 实现了接口，MyInt(42) 依然不能直接赋过去——它不是指针，也不等于 *MyInt。
