必须用指针接收者修改字段、实现接口或含指针/切片/map/mutex等字段；值接收者适用于小而不可变的纯值类型。选择依据是设计意图：承载状态用指针，表达值用值接收者。
面试官爱问值接收者和指针接收者，不是考你背定义，而是看你能不能在真实场景里做对选择——尤其当代码行为出人意料、接口实现失败、并发读写报错时，根子往往就在这儿。
需要修改字段？必须用指针接收者
值接收者操作的是副本，改了也白改。比如一个计数器：
- func (c Counter) Inc() { c.count++ } —— 调用后原始 c.count 完全不变
- func (c *Counter) Inc() { c.count++ } —— 才真能加一
哪怕结构体只有两个 int 字段，只要方法逻辑上要改状态，就必须用指针。这不是性能问题，是正确性问题。
实现接口时，类型一致性决定能否满足
接口是否被实现，看的是“方法集”，而方法集严格区分值类型和指针类型：
- 如果只有 func (T) Method()（值接收者），那 T 和 *T 都能调用它，但只有 T 的方法集包含该方法
- 如果只有 func (*T) Method()（指针接收者），那只有 *T 的方法集包含它；T 类型变量无法赋值给该接口
常见踩坑：定义了一个 type Config struct{...}，只给它写了 func (*Config) Validate()，结果传 Config{} 给需要 Validator 接口的函数，编译直接报错。
结构体含指针、切片、map、channel 或 sync.Mutex？优先指针接收者
这类字段本身就不适合拷贝：
- 拷贝含
sync.Mutex的结构体 → 副本里的锁和原锁无关，失去并发保护意义 - 拷贝含
map或slice的结构体 → 看似安全，但若方法里做了delete(m, k)或append(s, x)，改的只是副本，容易误判逻辑 - 含
io.Reader等接口字段 → 拷贝后底层资源引用可能失效或重复关闭
Go 官方包里绝大多数带状态或含复杂字段的类型（如 bytes.Buffer、http.Client）都统一用指针接收者，这是经过验证的工程惯例。
小而纯的不可变类型？值接收者更自然
像 time.Time、image.Point、type UserID string 这类类型，天生就是值语义：
- 字段全是基础类型，无指针、无 map、无 mutex
- 方法只读取、不修改（如
func (t Time) Year() int） - 拷贝开销极小（≤ 2–3 个机器字），且避免意外共享状态
这时候用值接收者，语义清晰，还能让编译器把接收者保留在栈上，减少逃逸和 GC 压力。
不复杂但容易忽略：选接收者类型，核心不是“结构体多大”，而是“这个类型的设计意图是什么”——它是用来承载状态的实体，还是表达一个不可变的值？顺着这个想，答案就清楚了。
