结构体大了需用指针接收者以避免值拷贝开销，但须兼顾语义、正确性与性能；含不可复制字段或需修改接收者时必须用指针，小结构体（≤16字节）可优先值接收者。
为什么结构体大了就得用指针接收者
Go 函数传参是值拷贝，结构体作为参数或接收者时，整个结构体内容都会被复制。如果结构体含大量字段、切片、map 或嵌套结构，一次方法调用可能触发几 KB 甚至 MB 级内存分配和拷贝——这在高频调用（比如 HTTP handler、循环遍历）中会明显拖慢性能。
指针接收者 func (p *MyStruct) Method() 只传一个指针（通常 8 字节），完全规避复制开销。但要注意：这不是“只要大就一定用指针”的万能规则，得看语义和使用场景。
哪些结构体必须用指针接收者
以下情况不加 * 会出错或行为异常：
- 方法内部需要修改接收者字段 → 值接收者改的是副本，原结构体不变
- 结构体包含不可复制字段，例如
sync.Mutex、chan、map、slice（注意：slice 本身可复制，但其底层数组共享；真正不可复制的是含 mutex 的结构体） - 接口实现要求一致性：若某方法用了指针接收者，那所有该接口的方法都得用指针接收者，否则类型无法满足接口
示例：sync.Mutex 不能被复制，所以含它的结构体只能用指针接收者：
type Cache struct {
mu sync.Mutex
data map[string]int
}
func (c *Cache) Set(k string, v int) { // 必须用 *Cache
c.mu.Lock()
defer c.mu.Unlock()
c.data[k] = v
}
值接收者 vs 指针接收者：性能与语义的权衡
小结构体（如 type Point struct{ X, Y int }）用值接收者反而更高效：避免解引用、缓存局部性更好，且语义清晰（方法不改变原值）。盲目全上指针反而可能引入不必要的间接访问和 GC 压力。
判断依据优先级：语义 > 正确性 > 性能。实操建议：
- 结构体大小 ≤ 2×指针宽度（即 ≤16 字节 on amd64）→ 优先值接收者
- 含指针、slice、map、chan、mutex 等字段 → 强制指针接收者
- 不确定是否会被修改，或未来可能扩展 → 从一开始就用指针接收者，避免后期重构接口
- 用
go tool compile -gcflags="-m" main.go查看逃逸分析：若值接收者导致结构体逃逸到堆，说明复制开销已隐含在分配中，此时指针更优
容易踩的坑：混用值和指针接收者
同一个结构体上同时定义值接收者和指针接收者方法，会导致调用歧义和接口实现断裂：
- 对变量调用方法时，Go 会自动取地址或解引用，但仅限于“明确可转换”的情况；若接收者类型不一致，编译器不会帮你补指针
- 例如：
var c Cache调用c.Set()没问题（c是变量，可取地址），但Cache{}这种字面量调用Set()会报错：cannot call pointer method on Cache literal - 更隐蔽的是接口赋值失败：若接口方法集基于指针接收者，而你传入值类型变量，
var i MyInterface = c编译不通过
统一策略最安全：要么全用值接收者（仅适用于纯数据、无状态、小结构体），要么全用指针接收者（推荐大多数业务结构体）。
真正麻烦的不是性能数字，而是调用点散落在几十个文件里，某处传了个临时结构体字面量，突然 panic 或静默失效——这种 bug 往往要花半天才定位到接收者类型不匹配。
