Go map lookup 读取 map 时能否安全并发

可以，但要把“并发读取”和“并发读写”分开。多个 goroutine 同时查找或遍历同一个 map，期间没有任何 goroutine 对它赋值、删除或清空时，Go 允许这样做；只要出现一个写入者，普通 map 的读取就不能继续裸奔，必须用锁、专用并发容器，或改成不可变快照。

先判断 map 是只读还是读写并发

判断标准不是“调用的是读取语法”，而是 map 的生命周期里是否存在修改。m[key]、len(m) 和只读 range 都属于读取；m[key] = value、delete(m, key)、clear(m) 以及会改变 map 内容的初始化过程则属于写入。初始化完成后再启动 worker，所有 worker 只查找，是最简单的安全场景。

下面这类写法看起来只是“后台刷新、前台查询”，实际上读写已经重叠：

var prices = make(map[string]int)

func readPrice(sku string) int {
    // 查询 goroutine 读取共享 map，但没有同步边界。
    return prices[sku]
}

func refreshPrice(sku string, price int) {
    // 刷新 goroutine 写入时，读路径不能继续直接访问普通 map。
    prices[sku] = price
}

这不是“偶尔读到旧值”这么简单。Go 的内存模型把未排序的读写视为 data race，运行时还可能报告并发 map 误用。因此，不能用一次测试没有崩溃来证明它安全。

只读配置直接使用不可变快照

如果 map 是启动配置、路由表或字典，推荐先在单 goroutine 中构造完成，再把它作为只读快照交给查询方。关键不是把变量命名成 readonly，而是约定发布后不再执行赋值、删除和清空。

func buildLabels() map[string]string {
    // 构造阶段只有当前 goroutine 修改 map。
    return map[string]string{"paid": "已支付", "cancelled": "已取消"}
}

func main() {
    labels := buildLabels()
    // 发布后只读取；不要把 labels 交给会修改它的协程。
    go func() { _ = labels["paid"] }()
}

这种方式读路径最短，类型也最清楚。若配置需要热更新，就不能继续复用旧 map 直接改；应当先构造一份新 map，再用同步手段一次性发布新快照。

普通共享状态优先用 sync.RWMutex

既有读取又有写入时，最容易维护的是把 map 和锁封装起来：读方法使用 RLock，写方法使用 Lock。这样调用方不会忘记某一条访问路径，也能在同一把锁下维护计数、版本号等相关字段。

type PriceBook struct {
    mu     sync.RWMutex
    prices map[string]int
}

func (p *PriceBook) Get(sku string) (int, bool) {
    p.mu.RLock()
    defer p.mu.RUnlock() // 确保所有返回路径都释放读锁。
    price, ok := p.prices[sku]
    return price, ok
}

func (p *PriceBook) Set(sku string, price int) {
    p.mu.Lock()
    defer p.mu.Unlock() // 写入和相关状态更新处在同一临界区。
    p.prices[sku] = price
}

RWMutex 不是“读越多越快”的保证；写者到来时会影响后续读者，锁竞争仍要结合实际访问模式判断。不要在持锁期间做网络请求、磁盘 I/O 或调用可能再次访问同一对象的回调。

四种写法怎么选

sync.Map 的“并发安全”不等于它适合替代所有 map。标准库文档把它定位在“某个键只写一次后大量读取”，或不同 goroutine 操作互不相同的键这类场景；如果还要保持强类型、组合多个字段的一致性，普通 map 加锁往往更直观。

读多写少的配置可以采用复制替换。每次更新都从当前快照复制出新 map，在新 map 上完成修改，最后通过 atomic.Value.Store 替换整份值；读者拿到的旧快照不会被写者原地改变。

type Labels map[string]string

var current atomic.Value // 只保存 Labels 这一种具体类型。

func lookup(key string) string {
    // Load 取得一个完整快照，读取期间不需要再加锁。
    return current.Load().(Labels)[key]
}

func replace(key, value string) {
    old := current.Load().(Labels)
    next := make(Labels, len(old)+1)
    for k, v := range old {
        next[k] = v // 复制旧快照，避免修改读者正在使用的对象。
    }
    next[key] = value
    current.Store(next) // 一次性发布新快照。
}

复制替换的代价是更新时要复制数据；如果 map 很大且更新频繁，就回到 RWMutex 或重新设计数据所有权。

用 race 检查遗漏的共享写入

最终检查应覆盖真实的访问路径，而不是只测一个顺序执行的例子。测试包可以运行：

# 用竞态检测器运行并发测试，发现未排序的读写访问。
go test -race ./...

# 调试一个直接启动 goroutine 的小程序。
go run -race ./cmd/demo

如果报告竞争，先找出哪一个 goroutine 在读、哪一个在写，再决定是补上锁、转为不可变快照，还是改成由单一 goroutine 持有 map。不要仅把 sync.Map 换上去就结束：跨多个键的业务不变量、Load 后再 Store 的复合逻辑，仍然需要专门的同步设计。

常见问题

多个 goroutine 同时 range 一个不变的 map 可以吗？

可以，前提是遍历期间没有任何 goroutine 修改该 map。若要排序输出，还要额外维护并排序 key 列表，因为 map 的遍历顺序本身不保证稳定。

只读 map 里的 value 是指针，还能算只读吗？

只能说明 map 的桶没有被修改。如果多个 goroutine 同时修改 value 指向的对象，那个对象仍然需要自己的锁或原子同步；map 的安全不会自动传递给 value 内部状态。

资料依据：https://go.dev/doc/faq#atomic_maps、https://go.dev/ref/mem、https://pkg.go.dev/sync、https://pkg.go.dev/sync/atomic