Go 接口的实现取决于类型的方法集，而值类型 T 和指针类型 T 的方法集互不包含；只有当接口方法由 T 实现时，必须传入 *T 实例才能满足接口，这是由 Go 类型系统严格保证的。
go 接口的实现取决于类型的方法集，而值类型 t 和指针类型 *t 的方法集互不包含；只有当接口方法由 *t 实现时，必须传入 *t 实例才能满足接口，这是由 go 类型系统严格保证的。
在 Go 中，一个类型是否满足某个接口，完全由其方法集（method set）决定，而非运行时行为或编译器能否“自动取地址”。这是 Go 类型系统的核心设计原则之一，旨在保证接口实现的明确性、可预测性和零隐式转换。
方法集规则简明回顾
- 类型
T的方法集：所有接收者为func (T)的方法； - 类型
*T的方法集：所有接收者为func (T)和func (*T)的方法（即包含值接收者与指针接收者）； - 因此：
*T可以调用T的方法（自动解引用），但T不能调用*T的方法——因为T的方法集中根本不包含这些指针接收者方法。
回到你的示例：
func (u *user) modify() { u.name = "My name" }该方法仅属于 *user 的方法集，不属于 user 的方法集。因此：
-
u.modify()能成功编译，是因为 Go 编译器将其语法糖展开为(&u).modify()—— 这是语言层面的特殊规则（仅适用于直接调用），编译器在此处主动取址并调用*user的方法； - 但
interfaceModify(u)失败，是因为u是user类型值，其方法集不含modify()，故不满足modifier接口；接口赋值是静态类型检查，绝不允许隐式取址。
正确用法与常见误区
✅ 正确方式（显式传递指针）：
u := user{"Default Name"}
interfaceModify(&u) // &u 是 *user 类型，方法集包含 modify()
fmt.Println(u.name) // 输出: "My name"❌ 错误方式（值传递，即使方法存在）：
interfaceModify(u) // 编译错误：user 不实现 modifier
⚠️ 注意：即使你为 user 同时定义了值接收者和指针接收者的 modify()，它们仍是两个独立方法，且接口仍需按方法集精确匹配。例如：
func (u user) modify() { u.name = "value-receiver" } // 属于 user 方法集
func (u *user) modifyPtr() { u.name = "ptr-receiver" } // 属于 *user 方法集此时 user{} 满足含 modify() 的接口，但不满足含 modifyPtr() 的接口。
为什么不允许接口隐式取址？设计考量
Go 明确拒绝在接口赋值时自动取地址，主要原因有二：
- 语义清晰性：避免调用方误以为修改会影响原值（如传值后修改副本却期望原变量变化）；
-
性能与所有权明确：接口值内部存储的是具体类型的拷贝（或指针）。若对
user值做接口赋值，内部存储的是user的完整副本；若此时允许调用*user方法，实际修改的是副本的字段，对原始变量无影响——这违背直觉且易引发 bug。
总结：三步自查接口实现问题
- ✅ 查看接口声明的方法签名；
- ✅ 确认目标类型（T 或 *T）是否在其自身方法集中拥有完全匹配的方法（含接收者类型）；
- ✅ 调用时确保传入的实参类型与方法集要求一致（必要时显式取址
&x或解址*p）。
记住：Go 的接口满足是编译期静态判定，不是运行时能力推断。写代码时，始终问自己：“这个类型的 func (X) M() 是否真的在它的方法集中？”——答案决定了接口能否成立。
