Go中string本身并发读取天然安全，因其只读不可变、底层为指针+长度且读操作不修改内存；真正需保护的是共享变量（如*string、结构体字段、map），而非字符串值本身。
string 本身并发读取天然安全，但别误判“共享对象”
Go 的 string 类型是只读不可变值，底层由指针 + 长度构成，所有读操作（s[i]、len(s)、s[1:3]、传参）都不修改内存，也不触发拷贝 header。多个 goroutine 同时读同一个 string 变量，完全无需加锁。
真正出问题的，是“共享变量”不是 string 本身，而是：
-
*string：多个 goroutine 写*s = "new"→ 竞态 - 结构体字段：
type User struct{ Name string }，并发执行u.Name = "x"→ 非原子赋值，尤其当结构体含多个字段时更危险 -
map[string]string：读m["k"]看似只读 string，实则要访问 map 内部哈希表 → 并发读写 panic
map 并发读写必须加锁，RLock 也得用对
Go 的 map 不是并发安全类型。只要有一个 goroutine 调用 Put（写），所有其他 goroutine 的 Get（哪怕只是读 value）都必须同步保护，否则运行时直接 fatal error: concurrent map read and map write。
sync.RWMutex 是标准解法，但注意细节：
-
RLock()和RUnlock()必须成对出现，推荐用defer m.rw.RUnlock()，漏掉会导致后续所有 goroutine 永久阻塞 - 读锁内不能做耗时操作（如 HTTP 请求、DB 查询），应先读出数据、解锁、再处理
- 如果 map 生命周期固定（启动时初始化完毕，之后只读），可不用锁；但一旦存在任何写路径，就必须统一加锁
立即学习“go语言免费学习笔记（深入）”；
sync.RWMutex vs sync.Mutex：读多写少才值得用 RLock
sync.RWMutex 的读锁开销比 sync.Mutex 略高，且在写操作频繁时反而可能降低吞吐。它只在明确满足“读远多于写”时才有优势。
判断是否该用 RWMutex，看实际访问模式：
- 缓存类场景（如
MemoryCache.Get调用频次是Put的百倍以上）→ 适合RWMutex - 配置热更新（每秒数次
SetConfig，同时数百 goroutineGetConfig）→ 适合RWMutex - 计数器或状态标志（读写频率接近）→ 直接用
sync.Mutex更简单稳定 - 纯只读（确认永不写）→ 连
RWMutex都多余
atomic、channel、sync.Map：别为了“高级”而绕开基础锁
sync/atomic 只适用于 int32、int64、uintptr、unsafe.Pointer 这几类底层类型，对 string 或结构体无效；sync.Map 适合键值对生命周期不一、读写随机的场景，但不支持遍历一致性，且初始化成本高；channel 适合事件驱动协调，不适合高频共享状态访问。
多数业务代码中，最直接可靠的方案仍是：
- 小范围共享变量（如单个 int、bool）→
sync/atomic - 结构体或 map →
sync.RWMutex或sync.Mutex - 需要跨 goroutine 通知变更 →
channel+ 单 goroutine 管理
sync.Map 替代简单 map 加锁，常带来隐蔽的性能倒退和语义混淆。
最容易被忽略的一点：竞态检测器（go run -race）能发现大部分问题，但它无法覆盖所有执行路径——比如某个写操作只在特定错误分支下触发，测试没跑过去，线上就崩。所以设计阶段就要明确每个变量的读写归属，而不是等 -race 报错才补锁。
