必须用指针接收者才能实现接口，因为Go接口实现要求方法签名（含接收者类型）完全匹配；若接口方法定义为 T接收者，则只有 T类型而非T类型能实现该接口。
为什么用指针接收者才能实现接口？
Go 中接口的实现判定是静态的：编译器检查类型是否提供了接口要求的所有方法，且方法签名（包括接收者类型）必须完全匹配。如果接口方法定义的是 *T 接收者，而你用 T 类型去实现——哪怕方法体一模一样，也不算实现该接口。
常见错误现象：
cannot use t (type T) as type MyInterface in assignment:
T does not implement MyInterface (Method needs pointer receiver)
- 结构体值
t和指针&t是两种不同类型，不能混用 - 即使
T有*T方法，T本身不“拥有”这些方法；只有*T拥有 - 反之亦然：若接口方法是值接收者
func (t T) Foo()，那么T和*T都能实现它（因为 Go 会自动解引用）
哪些场景必须用指针接收者？
当方法需要修改接收者字段时，必须用指针接收者——这是语言层面的要求，和接口无关，但直接影响能否满足接口契约。
例如：
type Counter struct {
count int
}
func (c *Counter) Inc() { c.count++ } // 必须用 *Counter
func (c *Counter) Value() int { return c.count }
type Counterer interface {
Inc()
Value() int
}
-
Counter{}无法实现Counterer：它的Inc方法只存在于*Counter - 传值调用
counter.Inc()会编译失败，因为counter是Counter类型，不是*Counter - 即使你不改字段，只要接口里声明了指针接收者方法，你就得用指针实例去赋值，比如
var c Counterer = &Counter{}
值接收者 vs 指针接收者：性能与语义差异
值接收者会复制整个结构体，指针接收者只传地址。对小结构体（如几个 int/bool）影响不大；但对大结构体或含 slice/map/channel 的类型，值接收者可能引发意外拷贝和性能损耗。
立即学习“go语言免费学习笔记（深入）”；
- 含可变内部状态的类型（如
sync.Mutex字段）必须用指针接收者：否则每次调用都锁副本，起不到同步作用 - 如果类型实现了多个接口，且其中至少一个要求指针接收者，建议统一用指针接收者，避免混淆（比如
json.Marshaler通常用*T实现） - 导出类型对外暴露接口时，接收者一致性很重要：用户不希望一会儿传
T，一会儿非得传&T
嵌入字段时的接口实现陷阱
嵌入结构体时，Go 会提升其方法，但提升规则仍遵守接收者类型。如果嵌入的是 T，它只能提升 T 自己的方法；嵌入 *T 才能提升 *T 的方法（不过嵌入指针本身不推荐）。
典型坑：
type Base struct{}
func (*Base) ServeHTTP(w http.ResponseWriter, r *http.Request) {}
type Server struct {
Base // 嵌入值类型
}
// Server 不实现 http.Handler！因为 *Base 的方法没被提升到 Server 上
// 正确做法是：Base 字段改为 *Base，或让 Base 用值接收者实现 ServeHTTP（但 ServeHTTP 需要修改状态，通常不行）
- 嵌入
T不等于 “继承*T的能力” - 想让外层类型实现某个接口，最稳的方式是：确保嵌入字段类型本身能以相同接收者方式实现该接口，并且嵌入方式匹配（即嵌入
*T才能获得*T方法） - 更推荐显式实现：在
Server上写func (s *Server) ServeHTTP(...)，逻辑委托给s.Base，语义清晰且可控
最容易被忽略的一点：接口变量存储的是具体类型的动态信息，包括接收者类型。同一个结构体，T 和 *T 在接口系统里是两个独立实现者。别假设“反正都差不多”，Go 的类型系统在这里非常严格。
