go 程序因并发读写 map 触发 fatal error，表面看已加锁，实则因结构体被值拷贝导致多个 goroutine 操作不同实例的锁和 map，使同步机制完全失效。
go 程序因并发读写 map 触发 fatal error，表面看已加锁，实则因结构体被值拷贝导致多个 goroutine 操作不同实例的锁和 map，使同步机制完全失效。
在 Go 中，map 本身不是并发安全的，必须通过互斥锁（如 sync.RWMutex 或 sync.Mutex）保护其读写操作。但仅“加锁”并不等于“线程安全”——锁的作用域必须覆盖所有访问共享数据的代码路径，且锁与被保护的数据必须属于同一内存实例。
本例中，问题根源并非锁使用错误，而是典型的 结构体值拷贝陷阱：
cc := NewCCache() // 返回 *CCache 指针（正确） ccCopy := *cc // ⚠️ 危险！值拷贝：复制整个结构体，包括 lock 字段和 metricCache 字段
由于 CCache 是一个结构体，其字段 lock sync.RWMutex 和 metricCache map[string]*CCacheMetric 均被逐字节复制。结果是：
-
cc实例的evictLoop()goroutine 持有原始lock并操作原始metricCache； -
ccCopy实例的Add()调用则持有另一份独立的lock，并操作另一份独立的metricCache（注意：map类型是引用类型，但map变量本身是包含指针的 header 结构；值拷贝时，新结构体中的metricCache字段指向同一底层哈希表！这是关键）。
⚠️ 这正是竞态的根源：
-
ccCopy.metricCache和cc.metricCache指向同一个底层 map 数据结构（因为 map header 被复制，但其中的buckets指针未变）； - 但
ccCopy.lock和cc.lock是两个完全无关的互斥锁； - 因此
ccCopy.Add()和cc.evict()实际上在无任何同步的情况下并发读写同一块 map 内存 ——race detector报告的Read at ... by goroutine 215和Previous write at ... by goroutine 155正是这一现象的直接证据。
✅ 正确做法：始终通过指针操作共享结构体，禁止对含锁或 map 字段的结构体做值拷贝：
// ✅ 正确：所有 goroutine 共享同一指针实例
cc := NewCCache() // 返回 *CCache
// 直接使用 cc.Add(), cc.evict() 等方法
// ❌ 错误：触发隐式值拷贝（尤其在赋值、函数传参、切片/Map 存储时）
var cacheList []*CCache
cacheList = append(cacheList, cc) // ok: 存指针
// cacheList = append(cacheList, *cc) // ❌ 绝对禁止！
func processCache(c CCache) { ... } // 参数为值类型 → 触发拷贝！应改为 func processCache(c *CCache)? 预防建议：
- 在
CCache结构体中添加noCopy字段（来自sync包），在go vet阶段捕获意外拷贝：type CCache struct { sync.NoCopy // 编译期提示：该结构体不应被拷贝 lock sync.RWMutex metricCache map[string]*CCacheMetric accnt *accnt.FlatAccnt } - 启用
-race编译标志进行竞态检测，它比运行时 panic 更早暴露问题； - 对于高频读、低频写的缓存场景，可考虑
sync.Map（但需权衡其非通用接口和性能特性），或更推荐：保持map + sync.RWMutex组合，并严格保证指针语义。
总结：Go 的并发安全不取决于“是否写了 Lock()”，而在于“所有访问者是否受同一把锁保护”。值拷贝会无声地分裂锁与数据的绑定关系，是 Go 并发编程中最隐蔽也最危险的陷阱之一。
