go中sync.mutex和sync.rwmutex本身不竞争，真正竞争的是多goroutine对共享内存的并发读写；-race仅检测实际执行路径上的数据竞争，未触发的读写并发则无法捕获，且rwmutex漏锁或误用会导致死锁而非panic。
go 语言里 sync.mutex 和 sync.rwmutex 本身不“竞争”，真正竞争的是多个 goroutine 对同一块共享内存的并发读写——锁只是暴露竞争的媒介。用错锁类型、漏加锁、或锁粒度不当，会让竞争更隐蔽、更难定位。
go run -race 检测不到 RWMutex 相关竞争？
不是检测不到，而是它只报「实际执行路径上的数据竞争」。RWMutex 的读写冲突如果没在运行时同时触发（比如测试没真正并发读+写），-race 就完全沉默。
- 常见漏测场景：测试里只跑
RLock()+RUnlock()，没构造写操作并发进入；或者写操作被 if 条件挡住，压测前没覆盖到 -
-race报告里若出现Previous write at ... Current read at ...，且堆栈指向RWMutex.RLock()和RWMutex.Lock()，说明读写确实撞上了——这不是锁的问题，是业务逻辑没串行化好 - 别依赖
-race发现 RWMutex 使用不当（比如读操作含副作用），它只管内存访问，不管语义
RLock() 后 panic 是因为没 Unlock 吗？
不是 panic，是死锁。RWMutex 的 RLock() 失败不会 panic，但漏掉 RUnlock() 会导致后续所有 Lock() 卡住，现象是 goroutine 数暴涨、HTTP 接口超时、CPU 反而偏低。
- 最常见位置：error 分支提前 return，
defer rwmu.RUnlock()没执行；或RLock()后接了可能 panic 的操作（如 JSON 解析），defer 被跳过 - 定位方法：用
curl 'http://localhost:6060/debug/pprof/goroutine?debug=2'搜sync.runtime_SemacquireRWMutexR，看哪些函数卡在读锁等待 - 安全写法：把
RLock()和defer RUnlock()写在同一作用域开头，中间不插任何可能提前退出的逻辑
Mutex 和 RWMutex 性能差异到底在哪？
差异不在“锁本身多快”，而在「锁的持有模式是否匹配你的访问分布」。RWMutex 在读多写少时吞吐更高，但一旦写占比超 10%，或单次读操作耗时 >100µs，它反而比 Mutex 慢。
- RWMutex 的读锁要原子增减计数器，写锁必须等所有读锁释放——写饥饿就是这么来的
- Mutex 更轻量，lock/unlock 是纯用户态原子操作；RWMutex 的
Lock()在有活跃读锁时会进内核调度，延迟不可控 - 别为字段级并发拆一堆 RWMutex，比如给 struct 每个字段配一个
sync.RWMutex：cache line 伪共享会让 CPU 频繁同步 L1 cache，实测吞吐可能下降 30%+
为什么 Mutex 值拷贝后就失效了？
因为 sync.Mutex 和 sync.RWMutex 是非复制安全类型，底层包含 runtime.mutex 结构体，值拷贝会复制锁状态字段（如 state、sema），导致两个变量指向不同内核信号量，失去互斥意义。
- 典型错误：把带 Mutex 的 struct 当参数传进函数，函数内修改了副本的锁；或用 map[string]MyStruct 存储，然后取出来赋值给新变量
- 正确做法：始终用指针传递（
*MyStruct），或把锁定义为字段指针（mu *sync.Mutex），但后者更易出错，不推荐 - 编译期无法捕获，只能靠
-race或 pprof 发现异常阻塞，所以代码审查时盯紧结构体赋值和函数参数传递
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
