Go接口接收指针或值直接影响方法调用：值类型T的方法集仅含T接收者方法，T的方法集包含T和T接收者方法；nil指针赋给接口后接口非nil，需类型断言后判空；嵌入*T可继承全部方法，嵌入T仅继承值方法。
接口接收指针还是值，直接决定方法能否被调用
Go 中接口的底层是 (type, value) 二元组，当把一个值赋给接口时，Go 会复制该值；若赋的是指针，则复制的是地址。关键在于：**只有实现了某方法的类型，其对应的方法集才被接口认可**。而方法集规则是：值类型 T 的方法集只包含接收者为 T 的方法；指针类型 *T 的方法集则包含接收者为 T 和 *T 的所有方法。
常见错误现象：cannot use t (type T) as type interface{Do()} in argument to call: T does not implement interface{Do()} (Do method has pointer receiver)
- 如果结构体方法接收者是
*T（比如修改字段、避免拷贝大对象），那就必须传&t给接口变量，不能传t - 如果希望值和指针都能满足同一接口，方法接收者统一用
T—— 但注意：这会导致方法内对字段的修改不反映到原值上 -
标准库中
io.Reader、json.Marshaler等都允许值或指针实现，是因为它们的方法接收者都是值类型（如Read([]byte) (int, error)）
nil 指针赋给接口后，不是 nil 接口
这是最常踩的坑：var p *MyStruct = nil，然后 var i fmt.Stringer = p，此时 i != nil！因为接口变量本身非空（它存了 (*MyStruct, nil)），只是底层指针是 nil。
典型问题场景：函数返回 interface{}，内部逻辑可能返回 nil 指针，但调用方用 if i == nil 判断会失效。
立即学习“go语言免费学习笔记（深入）”；
- 判断接口是否“真正为空”，需先类型断言再判指针：
if v, ok := i.(*MyStruct); ok && v == nil - 更安全的做法是让函数返回明确的指针类型（如
*MyStruct）而非接口，避免模糊语义 - 在实现接口方法时，若接收者是
*T，方法开头应加if t == nil { return ... }防 panic
嵌入结构体时，指针嵌入和值嵌入对接口实现的影响不同
嵌入（embedding）是 Go 类型组合的关键机制，但嵌入的是 T 还是 *T，会直接影响外层类型是否自动获得被嵌入类型的方法——尤其是那些带指针接收者的方法。
例如：type A struct{ *bytes.Buffer } 与 type B struct{ bytes.Buffer }，两者对 io.Writer 的满足情况就不同：前者能调用 Write（因 *bytes.Buffer 实现了它），后者不能（因 bytes.Buffer 的 Write 接收者是 *Buffer）。
- 嵌入
*T可以继承T和*T方法；嵌入T只能继承T方法 - 如果被嵌入类型有指针接收者方法且你依赖它满足某个接口，优先嵌入
*T - 但嵌入
*T后，外层结构体零值中该字段是nil，调用其方法前必须初始化，否则 panic
接口字段里存指针，序列化/比较时容易出意外
当结构体字段是接口类型（如 data interface{}），实际存入的是 *SomeType，后续用 json.Marshal 或 == 比较时行为可能不符合直觉。
-
json.Marshal对接口中的nil指针默认输出null，但若接口里存的是&struct{}{}，就会输出完整对象 —— 注意别混淆“接口 nil”和“接口里存的指针 nil” - 两个接口变量
a和b，即使都含相同地址的*T，a == b仍为false（接口比较只在二者均为 nil 或底层type和value完全相同时才真） - 需要深比较或序列化控制时，别依赖接口字段的默认行为，显式做类型断言并处理指针语义
接口和指针交织时，真正的复杂点不在语法，而在“谁拥有值”“谁负责非空检查”“方法集是否覆盖目标接口”这三个问题上。一旦其中任一环节没对齐，运行时 panic 或逻辑错位就很难靠测试全覆盖发现。
