当结构体方法使用值接收器时，调用会触发整个结构体的复制，导致字段读取发生在锁保护之前，从而被竞态检测器（-race）标记为数据竞争。
当结构体方法使用值接收器时，调用会触发整个结构体的复制，导致字段读取发生在锁保护之前，从而被竞态检测器（-race）标记为数据竞争。
在 Go 中，方法接收器类型（值接收器 func (c Counter) vs 指针接收器 func (c *Counter)）不仅影响语义和性能，更直接关系到并发安全性。上述代码中 get() 方法声明为值接收器：
func (c Counter) get() int {
c.mtx.Lock()
res := c.value
c.mtx.Unlock()
return res
}表面看，c.mtx.Lock() 似乎已加锁，但问题发生在方法调用的一瞬间：为执行该方法，Go 必须先将 counter 的当前值完整复制一份（即构造一个 Counter 值副本），而这个复制过程会隐式读取 c.value 字段——注意，此时锁尚未获取！该读操作与另一 goroutine 中 inc() 对 counter.value 的写操作（发生在 c.mtx.Lock() 之后）构成无同步的并发读-写，触发 race detector 报警。
关键点在于：结构体复制是原子性内存读取操作，不受方法内锁控制。即使 mtx 是 *sync.Mutex（指针），复制时仍需读取 value int 字段的当前值，而这一读取不在任何锁保护范围内。
✅ 正确做法是统一使用指针接收器：
立即学习“go语言免费学习笔记（深入）”；
func (c *Counter) get() int {
c.mtx.Lock()
defer c.mtx.Unlock() // 更安全：确保解锁
return c.value
}此时调用不产生复制，c 直接指向原结构体，c.value 的读取发生在 Lock() 之后，受互斥锁保护。
⚠️ 补充注意事项：
- 若
mtx改为sync.Mutex（值类型），则值接收器会导致sync.Mutex被复制，违反“禁止拷贝锁”原则（go vet -copylocks可捕获），引发未定义行为； - 即使
mtx是指针，只要结构体含任何可被并发读写的字段（如value），值接收器就天然存在竞态风险； - 最佳实践：只要结构体需要修改状态或涉及同步，所有方法均应使用指针接收器，保持一致性与安全性。
综上，这不是 *sync.Mutex 的特例问题，而是 Go 值语义与并发控制的根本交集——值接收器的复制行为绕过了锁的保护边界，必须通过指针接收器消除不必要的内存读取，才能实现真正线程安全的访问。
