*t 调用接口失败是因为方法集规则是静态绑定而非继承：t 实现 i 时，*t 并不自动实现 i，除非方法接收者为 *t 或 t 可寻址且方法被显式包含；接口赋值只检查变量自身类型的方法集。
值类型 T 实现了接口 I，为什么 *T 有时调用失败？
因为 Go 的方法集规则不是“继承”而是“静态绑定”：*T 的方法集包含 (*T).X 和 (T).X（如果 T 可寻址），但 T 的方法集只包含 (T).X。接口赋值时，编译器检查的是“变量本身的类型”的方法集，不是底层类型。
常见错误现象：var t T; var i I = t 成功，但 var pt *T; i = pt 编译失败，报错 cannot use pt (type *T) as type I in assignment —— 即使 T 实现了 I 的所有方法。
- 根本原因：接口要求“该类型的方法集必须包含接口所有方法”，而
*T虽能调用(T).X，但(T).X不属于*T的方法集（除非显式为*T定义） - 只有当方法接收者是
*T时，*T的方法集才包含它；T的方法集也包含它（只要T可寻址），但反向不成立 - 典型场景：结构体字段是
T，你传&s.field给期望I的函数，结果编译不过
T 和 *T 哪个该实现接口？看值语义还是指针语义
取决于你是否需要修改接收者状态、是否涉及大对象拷贝、以及是否已有指针使用习惯。Go 标准库倾向统一用 *T，但不是铁律。
- 如果方法会修改字段（如
func (t *T) SetX(x int)），必须用*T接收者，此时T无法实现该接口 - 如果方法只读且
T很小（如type ID int），用T接收者更轻量，*T反而不自动满足接口 - 如果已有大量
T值存在（如切片元素、map value），又想让它们满足接口，就别把接收者全写成*T—— 否则你得手动取地址，还可能触发拷贝或 panic（对不可寻址值取地址）
如何快速判断某个类型是否实现了接口？别靠猜，用编译器说话
最可靠的方式是直接赋值或传参，让编译器报错。不要查文档、不要看方法名匹配，Go 不支持鸭子类型。
立即学习“go语言免费学习笔记（深入）”；
- 写一句
var _ I = T{}或var _ I = (*T)(nil)放在测试文件里，编译失败时错误信息明确告诉你缺哪个方法 - 注意：
var _ I = &T{}检查的是*T是否实现；var _ I = T{}检查的是T是否实现 —— 二者完全独立 - 工具如
go vet或 IDE 的 interface satisfaction 提示有时滞后或不准，以编译器为准 - 避免常见坑：嵌入字段的提升不改变方法集归属。比如
type S struct{ T }，S有T的方法，但S是否实现I，仍取决于T是用T还是*T实现的
接口字段里存 T 还是 *T？影响内存和 nil 判断
存什么类型，决定了后续调用方法时的接收者类型，也决定了 nil 检查行为是否自然。
- 如果接口变量里存的是
T值，那么即使原始变量是*T，装进去后也是拷贝，方法内修改不影响原值 - 如果存的是
*T，那方法内可修改原值，但也引入了 nil panic 风险：var p *T; var i I = p; i.Method()如果Method接收者是*T且没判 nil，就会 panic - 性能上：小类型（
int、string）存值无压力；大结构体（>16 字节）建议存指针，避免接口底层数据复制开销 - 一个容易被忽略的点：空接口
interface{}存T和*T的底层结构不同（前者是值+类型，后者是指针+类型），会影响reflect.ValueOf的Kind()和IsNil()行为
