必须用指针接收者当方法需修改接收者本身、字段，或满足含指针方法的接口；值接收者仅适用于小而不可变类型且方法只读。混用会导致接口实现失效，标准库及多数场景推荐统一用指针接收者。
什么时候必须用指针接收者
当方法需要修改接收者本身（而非其字段）或修改其字段时，必须用指针接收者。常见于实现 sort.Interface、encoding.BinaryMarshaler 等接口，或方法内部调用了其他指针接收者方法。
典型错误现象：
cannot call pointer method on x<br>cannot take address of x——比如对字面量或临时值调用指针接收者方法。
- 结构体字段是 map/slice/channel/func/interface 且需在方法内重新赋值（如
nil切片扩容后要更新原变量） - 方法签名需满足某个接口，而该接口中已有指针接收者方法被定义（Go 接口匹配看方法集，
*T的方法集包含T和*T的所有方法，但T的方法集只含T的值接收者方法） - 结构体较大（如含大数组、大量字段），避免每次调用都复制（虽不是“必须”，但属强推荐）
值接收者适用的明确场景
当方法只读访问字段，且接收者是小对象（如 int、string、小结构体）、或语义上代表不可变值（如 time.Time、url.URL）时，值接收者更自然、安全。
常见使用场景：计算哈希、格式化输出、类型转换、校验逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 接收者是基本类型或不超过 4–8 字节的小结构体（如
type Point struct{ X, Y int }） - 方法不修改任何状态，也不调用其他指针接收者方法
- 希望明确表达“该类型是值语义”，例如自定义数字类型
type Celsius float64的String()方法
混用指针和值接收者会破坏接口实现
如果一个类型 T 同时有值接收者和指针接收者方法，它的方法集是分裂的：T 只能调用值接收者方法；*T 才能调用全部方法。这会导致接口实现意外失效。
错误示例：定义了 func (t T) Read(...)（值接收者），但接口要求 Read() error 被 *T 实现——此时 T 类型变量无法赋值给该接口，因为 T 不满足接口（缺少 Read 方法）。
- 一旦类型实现了某个接口，后续所有方法接收者应统一为指针或统一为值（推荐统一为指针，除非有强理由）
- 检查方式：用
go vet或 IDE 提示“method set mismatch”，或显式测试var _ YourInterface = (*YourType)(nil) -
标准库中几乎所有结构体都统一用指针接收者（如
net/http.Request、os.File），这是事实标准
性能与可维护性的隐性成本
值接收者看似轻量，但若结构体含 slice/map/chan，它们底层是头信息+指针，复制开销小；真正危险的是误以为“没改字段就安全”，结果因方法内修改了 map 元素或切片底层数组，导致调用方看到未预期的副作用。
- 值接收者方法里修改
m[key] = val（map）或s[i] = x（slice）是允许的，且会影响原变量——因为 map/slice 本身是引用头，复制只是复制头，不是深拷贝 - 真正“安全”的值语义，需确保所有字段都是纯值类型且无引用穿透（如不含指针、函数、接口、map、slice、chan）
- 团队协作中，统一用指针接收者可降低认知负担：不用每次看方法是否修改状态，也不用纠结“这个 struct 算不算大”
int 或 string 那样被拷贝和比较。实际项目里，绝大多数结构体不属于这个例外。 
