核心原因是方法集不匹配：T的方法集仅含值接收器方法，T则包含值和指针接收器方法；当接口方法由指针接收器实现时，只有T满足。
为什么 *T 能赋值给接口，而 T 不行？
核心原因不是“写了指针就对”，而是方法集不匹配。Go 编译器检查的是：接口要求的方法是否全部落在你传入值的「方法集」里。
值类型 T 的方法集只包含所有「值接收器」方法；指针类型 *T 的方法集则同时包含「值接收器」和「指针接收器」方法。所以当接口方法由指针接收器实现时，只有 *T 满足条件。
- 常见错误现象：
cannot use t (type T) as type MyInterface in assignment: T does not implement MyInterface (method Modify requires pointer receiver) - 使用场景：结构体带状态修改（如
Write()、Reset()、Scale()），通常用指针接收器 - 性能影响：值接收器会拷贝整个结构体；指针接收器只传地址，大结构体必须用指针避免开销
- 兼容性注意：一旦某个方法用了指针接收器，想让
T类型也满足接口，就得把所有方法都改成值接收器——但可能破坏语义（比如无法修改原对象）
T 和 *T 都实现了同一个接口，能混用吗？
不能直接混用。虽然两者都满足接口，但它们是不同底层类型，接口变量内部存储的动态类型不同，会影响后续类型断言或反射行为。
例如：var i MyInterface = T{} 和 var i MyInterface = &T{} 在运行时分别存的是 T 和 *T，哪怕方法行为一致，i.(*T) 对前者 panic，i.(T) 对后者 panic。
立即学习“go语言免费学习笔记（深入）”；
- 常见错误现象：
panic: interface conversion: MyInterface is T, not *T - 使用场景：需要做类型断言或传给只接受具体类型的函数（如
func f(*T)）时，必须确保接口值底层类型一致 - 建议做法：统一用
*T初始化，尤其当结构体有指针接收器方法时——这是最安全、最常见、也最符合 Go 实践的默认选择 - 例外情况：只读小结构体（如
Point、Color），且所有方法都是值接收器，可放心用T
空接口 interface{} 为什么总能成功赋值？
因为空接口不定义任何方法，所有类型的方法集都天然包含「空集合」，所以任意类型都能满足它。但它不解决方法集问题，只是绕过了方法集检查。
真正要注意的是：一旦你把 T 或 *T 赋给 interface{}，再想转回具体接口（如 MyInterface），仍要重新校验方法集——此时依然受 T/*T 差异约束。
- 常见错误现象：
var any interface{} = T{}; var i MyInterface = any.(MyInterface)→ panic，即使T理论上满足接口，但运行时类型是T，而接口要求的是*T方法集 - 使用场景：通用容器（如
map[string]interface{}）、JSON 解析、日志字段传参 - 性能影响：空接口值需额外存储类型信息和数据指针，比直接传
T或*T略重；频繁装箱/拆箱可能成为瓶颈 - 调试提示：用
fmt.Printf("%#v", any)可看到底层具体类型，有助于定位断言失败原因
如何快速验证某个类型是否实现了某接口？
最可靠的方式不是靠经验猜，而是让编译器帮你报错或用静态检查语句。
推荐两种写法：
- 在包级别加一行：
var _ MyInterface = (*MyStruct)(nil)—— 如果没实现，编译直接失败，且明确指出缺哪个方法 - 在测试文件中写：
func TestMyStructImplements(t *testing.T) { var _ MyInterface = &MyStruct{} }—— CI 中自动跑，防重构漏掉实现 - 不要依赖 IDE 提示或“看起来像就对了”——Go 的方法集规则严格，细微差异（如参数名不同、error vs *error）都会导致失败
- 特别注意：方法签名必须完全一致，包括参数名（虽不参与类型系统，但影响 IDE 和文档生成）、返回值顺序、是否带命名返回值等
