指针接收者本身不引发并发问题，但会放大共享状态风险；真正危险的是多个goroutine同时调用修改共享字段且未加锁的方法。
指针接收者本身不引发并发问题，但会放大共享状态风险
指针接收者不会自动导致竞态，它只是让方法能修改原始结构体——真正危险的是“多个 goroutine 同时调用该方法，且方法内部修改了共享字段却没加锁”。Go 把接收者当成第一个参数传递，myObj.Do() 等价于 Do(myObj)，而 myPtr.Do() 等价于 Do(myPtr)。传进去的是同一个地址，后续是否安全，全看 Do 里干了什么。
- 如果
Do只读字段、不改*r、也不碰全局变量 → 并发安全 - 如果
Do执行r.count++或r.cache[key] = val→ 必须用sync.Mutex或sync/atomic保护 - 即使方法只读，若字段本身是
map或[]byte，且被其他 goroutine 修改过 → 仍可能竞态（只读语义不传递到深层）
什么时候必须给指针接收者加锁？看三个信号
不是所有指针接收者都要锁，但以下情况不加锁就等于开闸放水：
-
struct字段被写入：比如user.Name = "Alice"、cfg.Timeout = 30 * time.Second - 方法内修改了非局部容器：如
r.items = append(r.items, x)（改 header）、r.m[key] = val（改 map 底层） - 方法调用了非线程安全的外部资源：比如操作未加锁的
log.Logger、复用未重置的*bytes.Buffer（尤其从sync.Pool获取后）
注意：sync.Mutex 字段本身必须是值类型（不能是指针），否则结构体拷贝会导致锁失效；推荐内嵌在 struct 里，统一由方法封装加锁逻辑。
比加锁更安全的替代方案：传值 or 通道移交
很多场景下，与其费力设计锁策略，不如从源头避免共享：
立即学习“go语言免费学习笔记（深入）”；
- 小结构体（≤ 3 个机器字，如
type Point struct{ X, Y int }）→ 直接用值接收者，func (p Point) Distance(q Point) float64，天然无竞态、无逃逸 - 只读配置或 DTO 类型（如
type Config struct{ Timeout time.Duration }）→ 值接收者 + 不暴露可变字段，比指针+锁更轻量可靠 - 必须可变又高频访问？用 channel 移交所有权：
ch 后，仅接收 goroutine 拥有该指针，其他方不再持有 → 避免锁、避免误用
传指针不是错，错在默认把它当“共享句柄”而不定义访问契约。
容易被忽略的坑：循环变量取地址 + race detector 捕不到
这个错误不直接源于指针接收者，但常在调用指针方法时一起发生：
for _, u := range users {
go func() {
u.Process() // ❌ 所有 goroutine 共享同一个 &u 地址
}()
}编译器不报错，go run -race 有时也漏检。真正安全的写法是：
for _, u := range users {
u := u // 显式创建新变量
go func() {
u.Process() // ✅ 每个 goroutine 拥有自己的 u 副本（或其地址）
}()
}指针的危险性，往往不在语法层面，而在你忘了它背后那块内存正被谁读、被谁写、写了几次。
