go 原生 map 非并发安全，多 goroutine 同时读写会触发数据竞争；即使使用 sync.rwmutex，也必须确保所有共享变量（包括临时接收值的变量）的访问均受同一锁保护，否则仍会引发 race。
go 原生 map 非并发安全，多 goroutine 同时读写会触发数据竞争；即使使用 sync.rwmutex，也必须确保所有共享变量（包括临时接收值的变量）的访问均受同一锁保护，否则仍会引发 race。
在 Go 中，map 类型默认不是并发安全的——这意味着多个 goroutine 同时对同一个 map 执行读+写、写+写，或甚至多个 goroutine 同时写入不同 key，都可能引发 panic 或未定义行为。虽然你使用了 sync.RWMutex 来保护 dictionary 的读写，但原代码中存在两个关键问题，导致 go test -race 报告数据竞争：
? 问题定位：竞争不在 map，而在 value 变量
Race detector 明确指出竞争发生在 value = dictionary["Key"] 这一行。原因在于：
-
value是一个跨 goroutine 共享的局部变量（声明在 goroutine 外部，但在闭包中被多个 goroutine 并发赋值）； - 多个
go func()并发执行value = dictionary["Key"]，而value本身未加任何同步保护； -
RWMutex.RLock()只保护了dictionary的读操作，但无法阻止对value的并发写入。
此外，原代码还存在其他严重隐患：
-
for { }无限启动 goroutine，造成资源爆炸（goroutine 泄漏）； -
log.Println(value)在 goroutine 内部执行，但value的最终值不可预测，且该语句实际永远不会执行（因for无退出条件）； -
RLock()/RUnlock()成对使用缺失（当前代码中RUnlock()被遗漏，会导致死锁风险）。
✅ 正确解决方案：统一锁保护 + 避免共享可变状态
最稳妥的做法是：所有对共享状态（包括 map 和其关联的读取结果变量）的访问，均由同一把互斥锁串行化。以下是修复后的完整示例：
func TestConcurrency(t *testing.T) {
var mu sync.RWMutex
dictionary := make(map[string]interface{}) // 使用 string 作为 key 更符合常规（interface{} key 效率低且易错）
// 启动一个长期运行的 goroutine 模拟并发读写
done := make(chan struct{})
go func() {
defer close(done)
ticker := time.NewTicker(10 * time.Millisecond)
defer ticker.Stop()
for i := 0; i <blockquote>
<p>? <strong>关键改进说明</strong>：</p>
<ul>
<li>使用 <code>strconv.Itoa</code> 需导入 <code>"strconv"</code>；</li>
<li>所有对 <code>dictionary</code> 的读写均通过 <code>mu</code> 保护；</li>
<li>读取结果 <code>val</code> 是<strong>函数内局部变量</strong>，每个 goroutine 独立持有，彻底消除 <code>value</code> 竞争；</li>
<li>避免无限 goroutine 创建，改用 <code>ticker</code> 控制节奏；</li>
<li>显式调用 <code>RLock()</code>/<code>RUnlock()</code>，确保成对出现。</li>
</ul>
</blockquote><h3>? 进阶建议：何时用 <code>sync.Map</code>？</h3><p>若场景满足以下条件，可考虑 <code>sync.Map</code>（专为高并发读、低频写优化）：</p>
- Key 类型固定（如
string），且读远多于写； - 不需要遍历全部 key（
sync.Map不提供安全迭代接口）； - 无需原子性地执行“读-改-写”复合操作（如
LoadOrStore可用，但LoadAndDelete等受限）。
示例：
var syncDict sync.Map
syncDict.Store("Key", "value")
if val, ok := syncDict.Load("Key"); ok {
_ = val
}
⚠️ 注意：sync.Map 并非万能替代品——它在写密集或需强一致性（如计数器累加）场景下性能反而更差，且 API 更复杂。绝大多数情况，优先选择 map + sync.RWMutex 并严格遵循“锁住所有共享访问”原则。
✅ 总结
- Go map 本身不支持并发读写，必须显式同步；
-
sync.RWMutex仅保护被其包裹的代码段中的变量，不能自动保护闭包捕获的外部变量； - 共享变量（如
value）若被多个 goroutine 写入，必须单独加锁，或改为局部变量； - 始终确保
Lock/Unlock、RLock/RUnlock成对出现，避免死锁； - 使用
-race是发现并发问题的黄金工具，应纳入常规测试流程。
