T能实现接口而T不能，因T的方法集仅含值接收者方法，T则包含值和指针接收者方法；故指针接收者方法仅由*T实现，T无法自动转换。
为什么 *T 能实现接口，但 T 不能被 *T 自动转换调用？
Go 接口的实现判定是静态的、编译期完成的，不看运行时值类型，只看方法集是否匹配。一个类型 T 的方法集只包含「值接收者」方法；而 *T 的方法集包含「值接收者 + 指针接收者」方法。所以即使 T 有指针接收者方法，它自己并不“拥有”该方法——只有 *T 才算实现了那个接口。
- 常见错误现象：
cannot use t (type T) as type MyInterface in argument to foo: T does not implement MyInterface (Method needs pointer receiver) - 如果你写了
func (t *T) Do() {}，那只有*T实现了接口，T{}字面量或变量直接传参会报错 - 使用场景：结构体需要修改内部字段（比如计数器、缓存、状态标记），必须用指针接收者；此时若想让该类型满足接口，就得用
*T实例去赋值/传参 - 注意：
var t T; var i MyInterface = &t是合法的，但var i MyInterface = t编译失败
nil 指针接收者调用方法不会 panic，但解引用会崩溃
Go 允许对 nil 指针调用方法——只要方法体内没实际访问 nil 的字段或方法。这常被用于“惰性初始化”或“空对象模式”，但也是最容易翻车的地方。
- 常见错误现象：
panic: runtime error: invalid memory address or nil pointer dereference，发生在方法里写了t.field或t.Helper()这类操作 - 安全写法：在指针接收者方法开头加
if t == nil { return }或明确处理nil分支 - 性能影响：几乎为零，
nil判断是 cheap 的；但逻辑遗漏会导致线上 panic，比值接收者更隐蔽 - 反例：
func (t *T) String() string { return t.name }—— 若t是nil，这里必然 crash
接口变量里存的是 *T 还是 T，会影响方法调用和内存布局
接口底层是两个字长的结构：type iface struct { tab *itab; data unsafe.Pointer }。当存 *T 时，data 指向堆/栈上的地址；存 T 时，data 直接复制整个值。这个差异在大结构体或需保持唯一实例时很关键。
- 使用场景：比如
sync.Mutex必须用指针传递，否则每次传参会复制锁状态，失去互斥意义 - 参数差异：
func f(m sync.Locker)接收接口，传&mu正确，传mu（值）虽能编译（因为sync.Mutex值接收者实现了Lock/Unlock），但完全无效 - 兼容性影响：32 位系统上，
*T是 4 字节，T若大于 4 字节，接口存储开销明显上升；64 位下更明显 - 容易踩的坑：把大结构体（如含切片、map、大数组）以值方式塞进接口，触发不必要的内存拷贝
动态类型解析时，reflect.TypeOf(x).Kind() 返回的是 Ptr 还是 Struct？
反射看到的是接口变量里实际存储的“动态类型”，不是声明类型。如果接口变量里存的是 *T，reflect.TypeOf 就返回 Ptr；存的是 T，就返回 Struct。这点直接影响 reflect.Value.Field 或 .Elem() 的可用性。
立即学习“go语言免费学习笔记（深入）”；
- 常见错误现象：
reflect.Value.Interface(): cannot return value obtained from unexported field or method或call of reflect.Value.Field on ptr Value - 正确做法：先判断
v.Kind() == reflect.Ptr，再用v.Elem()获取所指对象；否则直接v.Field(i)会 panic - 示例：
var i interface{} = &T{}; v := reflect.ValueOf(i); fmt.Println(v.Kind()) // Ptr - 容易忽略：从
json.Unmarshal或database/sqlScan 得到的接口值，其底层可能是*T或T，取决于你传进去的是地址还是值
最麻烦的不是语法记不住，而是同一个结构体，在不同上下文里被当成 T 或 *T 用，而编译器只在赋值点报错，调用链深了根本看不出哪一层漏了取地址。
