值接收器方法无法修改原结构体字段，因为Go会复制整个结构体传入；指针接收器才能修改原始字段，且涉及赋值或需“留下痕迹”时必须使用。
值接收器方法改不了原结构体字段
因为 Go 在调用值接收器方法时，会把整个结构体复制一份传进去——你改的是副本，原变量完全不受影响。这和 C 的传值、Python 的不可变对象行为逻辑类似，但 Go 里 struct 默认就是可复制的值类型。
常见错误现象：user.Name 调用 SetName() 后还是空，或 counter.Inc() 调完 counter.Value 没变。
- 只有指针接收器（
func (u *User) SetName(n string)）才能修改原始结构体字段 - 值接收器适合只读操作：计算哈希、生成字符串、校验字段等无副作用场景
- 如果结构体很大（比如含
[]byte或嵌套 map），值接收还会带来明显内存和性能开销
什么时候必须用指针接收器
只要方法里有任何字段赋值，或者你想让方法调用能“留下痕迹”，就必须用指针接收器。这不是风格选择，是语义强制。
使用场景包括但不限于：sync.Mutex.Lock()、bytes.Buffer.Write()、自定义类型的 Reset() 或 UnmarshalJSON()。
立即学习“go语言免费学习笔记（深入）”；
- 哪怕只改一个
int字段，也得用*T接收器，否则编译通过但逻辑失效 - 接口实现时要注意：如果某个方法用了指针接收器，那只有
*T类型才能满足该接口，T值类型不行 - Go vet 会警告「method modifies field in value receiver」，但不会报错，容易被忽略
值接收器不是完全没用：安全性和一致性
值接收器真正价值在于明确表达「这个方法不改变状态」，对并发和测试都更友好。比如 time.Time.Before() 就是典型值接收器——它不可能也不应该改 Time 本身。
参数差异很关键：值接收器接收的是 T，指针接收器接收的是 *T，两者在方法集上不兼容。
- 小结构体（如
type Point struct{ X, Y int }）用值接收器反而更高效，避免解引用开销 - 如果结构体含指针字段（如
map、slice、chan），值接收器也能间接修改底层数组/哈希表——但这属于“共享底层数据”，不是改结构体自身字段 - 别指望靠值接收器 + 修改 slice 元素来“假装”改了结构体：虽然
s.Data[0] = 1生效，但s.Len = len(s.Data)这类字段赋值依然无效
如何快速判断该用哪种接收器
看方法签名第一眼：有没有赋值语句。有，就换 *T；没有，再看结构体大小和用途。
容易踩的坑是写完发现逻辑不对，又回头改接收器，结果一堆调用点要加 &——尤其是当方法已经暴露给外部包时，改接收器是破坏性变更。
- 新建类型时，如果未来可能需要修改字段，直接从
*T开始，别省那一个星号 - 用
go vet -shadow可以捕获部分误用，但不能替代设计意识 - 最隐蔽的问题：同一个类型混用两种接收器，导致部分方法只能被指针调用、部分只能被值调用，调用方极易困惑
值接收器的“副本机制”不是 bug，是 Go 显式控制所有权的体现。问题不在机制本身，而在人是否清楚自己正在操作的是哪个实例。
