方法集决定调用与赋值能力：T仅含值接收者方法，*T包含值和指针接收者方法；接口赋值严格按方法集匹配，不自动取址；嵌入类型时接收者类型影响方法提升；接收者选择应兼顾语义与一致性。
方法集决定“能不能调用”和“能不能赋值”
Go 里没有“类方法”的概念，只有“类型的方法集”——它不是运行时动态计算的，而是编译期就确定的硬规则。一个变量能否调用某个方法，取决于它的类型（T 还是 *T）是否包含该方法在自己的方法集中；一个值能否赋给某个接口，也完全看它的方法集是否覆盖接口要求的所有方法签名。
常见错误现象：cannot call pointer method on u 或 T does not implement Interface (Method has pointer receiver)，根本原因不是语法写错，而是方法集不匹配。
-
T的方法集：只含func (t T) M()这类值接收者方法 -
*T的方法集：同时含func (t T) M()和func (t *T) M() - 哪怕
T上定义了所有接口方法，只要其中一个是*T接收者，T就无法实现该接口
值变量能调用指针接收者方法，但不等于它实现了接口
这是最容易混淆的一点：你写 u := User{}; u.SetName("x") 能成功，是因为编译器自动把 u 取地址转成 (&u).SetName()——但这只适用于可寻址的变量（比如局部变量、结构体字段），不适用于函数返回值、map 中的值、切片元素等不可寻址场景。
而接口赋值不走这套自动转换逻辑，它严格按方法集检查。所以：
立即学习“go语言免费学习笔记（深入）”；
-
var u User; var i io.Writer = u→ 报错，因为io.Writer.Write是指针接收者，User类型不含该方法 -
var u User; var i io.Writer = &u→ 成功，*User方法集完整覆盖io.Writer -
fmt.Println(User{})不会报错，但若内部试图把User{}当作fmt.Stringer调用，且String()是指针接收者，则实际不会调用（fmt包会 fallback 到默认格式）
嵌入结构体时，方法集不会自动“提升”指针方法
嵌入 T 字段，只带出 T 的值接收者方法；嵌入 *T 字段，才能带出 T 和 *T 的全部方法。这直接影响外层类型能否满足接口。
示例：
type Logger struct{}
func (*Logger) Log(s string) {}
type App struct {
Logger // 嵌入值类型
}
func (a *App) Run() { a.Log("start") } // ❌ 编译失败：a.Logger.Log 不在 App 方法集中
修复方式只有两种：
- 把嵌入字段改成
*Logger（推荐，语义更清晰） - 显式调用
a.Logger.Log("start")，但此时a.Logger必须是可寻址的（比如是结构体字段而非临时值）
小结构体用值接收者，大结构体或需修改时必须用指针接收者
性能不是唯一考量，语义一致性更重要。标准库中 time.Time 全是值接收者（24 字节，不可变），bytes.Buffer 全是指针接收者（含动态扩容的 []byte）。混用接收者类型会让方法集分裂，导致同一类型在不同上下文里“有时能用、有时不能用”。
关键判断点：
- 方法要改字段？→ 必须用
*T - 结构体含 slice/map/chan/大数组？→ 建议用
*T避免拷贝 - 所有方法都只读且结构体小于 16 字节？→
T更轻量，但务必全统一 - 类型要实现某个已有接口（如
json.Marshaler）？→ 查清该接口方法的接收者类型，照着写
最常被忽略的是：接口实现检查发生在赋值瞬间，而不是调用瞬间。传参前多看一眼变量是 T 还是 *T，比事后 debug 花半小时查方法集更省时间。
