只有指针接收器方法属于指针类型的方法集，值类型无法实现含指针接收器的接口；结构体需修改状态或较大时优先用指针接收器，嵌入结构体时指针接收器方法不自动提升。
为什么用指针接收器才能满足接口？
Go 的接口实现是隐式的，但有个关键约束：类型 T 实现了接口，不代表 *T 也自动实现，反之亦然。编译器只检查「方法集」是否匹配。值类型 T 的方法集只包含值接收器方法；而指针类型 *T 的方法集包含值接收器和指针接收器方法。所以如果你的接口方法是用指针接收器定义的（比如 func (p *User) Save()），那只有 *User 能赋值给该接口，User 值会报错：cannot use u (type User) as type Saver in assignment: User does not implement Saver (Save method has pointer receiver)。
实操建议：
- 定义接口前先想清楚：这个类型后续是否需要修改内部状态？如果会，优先用指针接收器，避免后期改接口或到处取地址
- 如果结构体较大（>16 字节），值接收器会引发不必要的拷贝，性能敏感场景默认用指针接收器更稳妥
- 不要混用：同一个接口方法，别一部分用值接收器、一部分用指针接收器——这会让实现逻辑碎片化，调用方难以预测行为
接口变量里存的是值还是指针？
接口变量本身是两个字宽的结构体：type iface struct { tab *itab; data unsafe.Pointer }。它不关心你传的是 User 还是 *User，只关心「能调用对应方法」。但底层 data 字段存放的内容，取决于你赋值时用的是值还是指针。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 传
User{}给接口后，在方法里修改字段，原变量不受影响（因为接口里存的是副本） - 传
&User{}后修改字段，原变量同步变化——但若原变量是栈上临时值（如func() { u := User{}; f(&u) }），可能触发逃逸分析，影响性能
实操建议：
- 用
go tool compile -gcflags="-m" main.go看逃逸分析，确认大结构体是否意外堆分配 - 调试时可打印
fmt.Printf("%p", &u)和接口方法内fmt.Printf("%p", p)对比地址，快速判断是否共享同一块内存
动态派发真的“动态”吗？
Go 没有运行时的虚函数表查找机制。接口调用在编译期就确定了具体类型和方法地址，只是把跳转逻辑延迟到运行时做一次间接寻址（查 itab）。所以它不是 C++ 那种多级 vtable 查找，也不是 Java 的 JIT 重编译优化，而是“静态绑定 + 运行时查表”的折中。
性能影响：
- 一次接口调用比直接调用多一次内存加载（读
itab）和一次跳转，但现代 CPU 分支预测很准，开销通常可忽略 - 如果接口变量生命周期短、调用频繁（如循环内），且底层类型固定，可考虑改用类型断言+直接调用绕过查表：
if u, ok := i.(Userer); ok { u.Do() } - 注意：空接口
interface{}的itab查询开销略高于非空接口，因为要处理更多类型组合
嵌入结构体时指针接收器的陷阱
当一个结构体嵌入另一个结构体（比如 type Admin struct { User }），Go 会提升嵌入字段的方法到外层类型。但提升只对「值接收器方法」生效；如果 User 的方法是用指针接收器写的，Admin 不会自动获得该方法——除非你显式嵌入指针：type Admin struct { *User }。
容易踩的坑：
- 嵌入
User后发现不能把Admin赋给某个接口，但单独User可以——大概率是那个接口方法用了指针接收器，而你嵌入的是值类型 - 嵌入
*User后，Admin的零值是nil指针，调用提升的方法会 panic：panic: runtime error: invalid memory address or nil pointer dereference - 如果嵌入的是
*User，记得在初始化时手动分配：a := Admin{User: &User{Name: "x"}}，否则字段为nil
真正麻烦的地方不在语法，而在团队协作时——有人改了 User.Save 的接收器从值改为指针，所有嵌入它的类型都得跟着检查是否断裂。这种隐式依赖很难被测试覆盖到。
