并发 Map

可以，但要把问题拆开看：sync.Map.Range 的回调函数可以对同一个 Map 调用 Store、Delete 等方法，标准库并没有把这些调用判定为非法；不过，Range 不承诺遍历的是一个一致快照。并发修改时，某个键被回调看到的值可能来自遍历过程中的不同时间点。

结论：回调里修改同一个 sync.Map 是允许的，但不要把这次 Range 当成“开始时的完整副本”，也不要依赖固定顺序或“读取到的一定是最新值”。

先分清“能修改”和“能得到稳定结果”

很多并发 Map 的问题，根源不是 Range 会不会直接崩溃，而是把两个不同问题混在了一起：

• 方法调用是否允许：回调 f 可以调用同一个 Map 的方法，其他 goroutine 也可以同时调用它的方法。
• 遍历结果是否稳定：Range 不提供一致快照。某个键在遍历期间被存储或删除时，回调可能看到该键在这段时间内任意时点的映射。

因此，“程序可以安全地调用 Store”不等于“回调收到的键值集合就是某一刻完整、准确的集合”。如果后续逻辑要据此生成报表、计算总量或做一次性决策，就必须额外设计稳定视图。

回调里调用 Store 或 Delete 为什么不会直接冲突

Range 会依次把键和值交给回调。回调内可以按照业务条件更新当前键，也可以删除已经处理的键。下面的示例只展示 API 语义，注释说明了每个动作的边界：

package main

import (
    "fmt"
    "sync"
)

func main() {
    var m sync.Map
    m.Store("ready", true)
    m.Store("retry", 2)

    m.Range(func(key, value any) bool {
        name := key.(string)

        switch name {
        case "ready":
            // 回调内修改同一个 Map 是允许的，但不会把 Range 变成快照。
            m.Store("ready", false)
        case "retry":
            // 删除当前键不会让回调失去调用 Map 方法的资格。
            m.Delete(name)
        }

        fmt.Printf("处理 %s=%v\n", name, value)
        // 返回 true 继续遍历；它只控制本次 Range 是否继续。
        return true
    })
}

这里的安全性只表示 sync.Map 的方法调用遵守它自己的并发使用约定。它不表示 ready 一定只被访问到一次特定值，也不表示新写入的键一定会在本次遍历中被访问。

并发修改时到底能保证什么

官方对 Map.Range 的描述可以压缩成三条实用规则：

1. 回调按顺序被调用：同一次 Range 中，回调本身不是并行执行的。
2. 同一个键不会被访问超过一次：这是遍历调用次数的限制，不是对键值生命周期的快照承诺。
3. 修改期间的映射不固定：如果某个键在遍历期间被 Store 或 Delete，回调看到的映射可能来自这次 Range 的任意时间点。

第三条最容易被忽略。比如回调处理到 quota 时，另一个 goroutine 刚把它从 10 改为 20，回调看到哪个值不能用“Range 开始时的值”来推断。相反，回调已经读到的旧变量也不会因为 Map 后续更新而自动改变。

package main

import (
    "fmt"
    "sync"
)

func printAndUpdate(m *sync.Map) {
    m.Range(func(key, value any) bool {
        // value 是本次回调收到的值，不是对 Map 中未来值的引用。
        current := value.(int)
        fmt.Printf("key=%v value=%d\n", key, current)

        // 更新同一个键不会要求 Range 回到开头重新读取它。
        m.Store(key, current+1)
        return true
    })
}

因此，下面这些说法都不应该从一次 Range 中推出：

哪些写法适合放在 Range 回调里

回调内修改通常适合“逐项处理”的任务：例如标记已经处理的条目、删除已过期的键、把每个值转换后写入另一个结构。判断标准不是“有没有写操作”，而是业务是否允许每个条目在一个动态视图里被处理。

func removeExpired(m *sync.Map, expired func(any) bool) {
    m.Range(func(key, value any) bool {
        // 只依据当前回调拿到的值判断，不假设整个 Map 同时静止。
        if expired(value) {
            // 删除是并发安全的，但不改变已经发生的回调次数。
            m.Delete(key)
        }
        return true
    })
}

这类代码仍然要注意两个细节：

• 如果删除动作会触发外部副作用，不能把“回调执行一次”当成严格的业务幂等保证；必要时要用版本号、状态字段或独立的去重机制。
• 如果值本身是指针或可变对象，Map 的并发安全不自动保护对象内部字段。对象内部仍需要自己的同步方案。

需要稳定快照时，先收集再处理

如果业务要求“本轮处理的输入集合固定”，可以在 Range 阶段只把看到的内容复制到一个本地切片，后续处理切片，而不是边遍历边依赖 Map 的动态状态。这个切片是一次遍历结果的记录，不是对并发世界的绝对时刻快照；如果业务要求更强的一致性，还需要让写入方配合版本或锁。

type entry struct {
    key   any
    value any
}

func snapshotForOnePass(m *sync.Map) []entry {
    items := make([]entry, 0)
    m.Range(func(key, value any) bool {
        // 先复制本次看到的键值，避免后续处理继续依赖动态 Map。
        items = append(items, entry{key: key, value: value})
        return true
    })
    return items
}

func processSnapshot(items []entry) {
    for _, item := range items {
        // 这里处理的是切片记录，不再把 Map 的后续变化当成本轮输入。
        _ = item.key
        _ = item.value
    }
}

如果要保证“读取、判断、写回”之间的整体不变量，例如余额不能被并发扣成负数，单独使用 Range 通常不够。此时更适合用普通 map 配合 sync.Mutex 或 sync.RWMutex，把相关读取和更新放进同一个临界区。

最后用一张表判断是否该改方案

常见追问

Range 回调里删除当前键会导致死循环吗？

不会因为删除当前键就自动重新遍历它。一次 Range 对同一个键最多调用一次回调，但不要把这个保证扩展成对所有动态新增键的遍历保证。

Range 能保证回调按插入顺序执行吗？

不能。sync.Map 的 Range 没有业务排序语义，需要顺序时应把键复制出来后自行排序。

把 Range 放进 goroutine 就能得到快照吗？

不能。goroutine 只改变执行位置，不会改变 Range 的语义。快照要求应由收集策略、锁或版本协议明确提供。

记住一句话即可：sync.Map.Range 允许回调继续操作同一个 Map，但它只解决并发访问的安全边界，不替业务提供稳定快照。能接受动态视图，就在回调内做幂等的逐项处理；需要固定输入或跨键一致性，就先收集、加锁或改用更明确的数据协议。