在 go 中，接口是否能被某个类型实现，取决于该类型（或其指针）是否拥有接口要求的所有方法，且方法签名必须完全匹配——尤其是接收者类型（值接收者 vs 指针接收者）直接影响接口赋值是否合法。
Go 的接口实现规则是严格而明确的：一个类型 T 要实现接口 I，当且仅当 T（或 *T）显式定义了接口中所有方法，且方法的接收者类型必须一致。这与“自动解引用”无关，而是编译期的静态类型检查。
以你的代码为例：
type IA interface {
Method()
}
type SA struct{}
func (this *SA) Method() {} // ✅ 指针接收者- *SA 实现了 IA，因为 (*SA).Method 存在且签名匹配；
- SA 并未实现 IA，因为 SA.Method 并不存在（你没定义值接收者版本）；
- 因此 var i IA = SA{} 编译失败：SA 类型不满足接口；
- 而 var i IA = &SA{} 成功：*SA 类型完整实现了 IA。
⚠️ 注意：这与 obj.Method() 调用成功不是同一机制。
Go 在方法调用时提供了便捷语法（见 Go 语言规范：Method Values）：
- 若方法有值接收者 func (T) M()，允许 t.M() 和 (&t).M()（后者自动解引用）；
- 若方法有指针接收者 func (*T) M()，允许 (&t).M() 和 t.M()（后者自动取地址）——但仅当 t 是可寻址值（addressable）时才成立。
在你的例子中：
var obj = SA{} // obj 是可寻址的变量（栈上分配）
obj.Method() // ✅ 合法：Go 自动将 obj 转为 &obj，再调用 (*SA).Method但接口赋值 var i IA = SA{} 是类型兼容性检查，不是方法调用，不触发任何自动转换。SA{} 是一个临时的、不可寻址的结构体字面量，即使它“看起来像”能调用 Method，其类型仍是 SA，而 SA 没有实现 IA。
✅ 正确实践建议：
- 若希望值和指针都能赋值给接口，统一使用值接收者（适用于小、可复制的类型）；
- 若需修改 receiver 状态或避免拷贝大对象，使用指针接收者，并确保统一用 &T 赋值接口；
- 不要依赖“调用能行，赋值就该行”的直觉——接口实现是类型系统层面的契约，而方法调用语法糖仅作用于表达式求值阶段。
总结：Go 的优雅在于清晰分离——接口实现看类型，方法调用看语法糖。理解接收者类型与可寻址性，是写出健壮 Go 接口代码的关键基础。
