Go range 遍历 map 时删除元素安全吗：遍历语义、随机顺序与测试边界

日常清理map里的元素时，很多Go开发者会直接在 range 循环里调用 delete 完成删除。这个操作本身是单线程下合法安全的，但安全边界很窄：删除尚未访问的键不会让迭代器失效，遍历顺序却仍然完全不稳定；如果同一轮遍历里还往map新增键，绝对不能默认新键一定会被遍历到。

单goroutine范围内用range遍历map时删除还没读到的键，不会触发迭代器失效也不会panic，完全符合Go语言规范，但遍历顺序无保证、新增键是否被扫到无约定，并发场景下仍然要做好同步。

先把“能删”和“会遍历到”分开

下面这段代码常用来移除过期会话：

func removeExpired(items map[string]time.Time, now time.Time) {
    for id, expiresAt := range items {
        if !expiresAt.After(now) {
            delete(items, id)
        }
    }
}

这里可以拆出两个互不干扰的结论。第一，delete(items, id) 不会把当前循环变成非法状态；第二，循环只会对本轮实际访问到的条目做判断。删除动作不会生成固定遍历顺序，也不会把 map 变成支持按插入顺序读取的容器。

所以这段代码适合“每个已遍历到的元素都独立做判断”的清理类任务，不能把遍历顺序当成业务逻辑的排序依据。

语言规则到底保证了什么

Go 的 for range 规则对 map 修改给出了明确边界：如果一个还没遍历到的键在迭代期间被删除，它不会出现在后续的迭代结果里；如果一个键在迭代期间刚被创建，它可能出现在本轮结果里，也可能被跳过。已经产出过的键自然不会因为删除操作重复出现。

这不是“边遍历边改都不会出问题”。它只说明单goroutine内删除当前map中的元素不会触发类似其他语言迭代器失效的运行时错误。如果多个 goroutine 同时读写同一个普通 map，还是要做好同步，不然直接触发并发访问panic。

新增元素为什么不能拿来做控制流

看一个很容易踩坑的例子：

func expand(m map[string]int) []string {
    var seen []string
    for key, value := range m {
        seen = append(seen, key)
        if value == 1 {
            m[key+"-copy"] = 2
        }
    }
    return seen
}

有些运行结果会把 -copy 键也放进 seen，有些运行结果就不会。两种情况都不属于bug，因为新增键是否在本轮遍历里出现没有任何稳定保证。如果业务要求“只处理进入循环前已经存在的键”，就不要在同一个循环里往原map新增内容，可以先复制一份键集合，或者把新增的结果写入另一个独立map。

需要稳定结果时，采用两阶段写法

比如接口要返回本次清理了哪些ID，直接在原map上遍历收集结果，很容易让测试断言和打印日志的顺序每次都不一样。可以先把符合删除条件的键复制出来，排序之后再批量删除：

func removeAndReport(items map[string]time.Time, now time.Time) []string {
    expired := make([]string, 0)
    for id, expiresAt := range items {
        if !expiresAt.After(now) {
            expired = append(expired, id)
        }
    }

    sort.Strings(expired)
    for _, id := range expired {
        delete(items, id)
    }
    return expired
}

第一阶段只做map的只读操作，第二阶段再统一执行删除，排序操作就能把不稳定的遍历顺序转成稳定的对外输出约定。这里的额外开销是存储键的切片，如果map的体量很大，可以结合清理批次和内存预算，判断是否需要分批处理。

测试不要只跑一次就下结论

验证这类逻辑时，重点不要放在断言map的遍历顺序上，而是要最终校验集合元素和map的最终状态是否符合预期：

func TestRemoveExpired(t *testing.T) {
    now := time.Unix(100, 0)
    items := map[string]time.Time{
        "a": now.Add(-time.Second),
        "b": now.Add(time.Minute),
    }

    got := removeAndReport(items, now)
    if !reflect.DeepEqual(got, []string{"a"}) {
        t.Fatalf("removed = %#v", got)
    }
    if _, ok := items["a"]; ok {
        t.Fatal("expired key still exists")
    }
    if _, ok := items["b"]; !ok {
        t.Fatal("live key was removed")
    }
}

如果测试要覆盖遍历期间新增键的场景，应该校验所有合法的结果集合，而不是强行要求新增键一定出现在遍历结果里。并发相关的逻辑要单独写测试，用锁或者单线程归属约束保护map；不要把普通map的单线程修改规则误当成它支持并发安全。

三个常见误区

• 把 map 当成有序容器：需要顺序的场景要显式维护切片自行排序。
• 把新增键当作必然会被访问：语言规范只保留了它“可能出现”的许可，没有做强制保证。
• 看到单线程下删除安全，就省掉并发同步逻辑：普通map的并发读写仍然需要明确的所有权约束或者加锁保护。

相关问题

range map 时删除当前键会 panic 吗？

不会。单 goroutine 内删除当前或者尚未访问的键都是允许的，但最终被访问到的集合要按语言规则理解，不能自行脑补成固定顺序的遍历逻辑。

为什么同一段代码每次打印顺序不同？

map 的遍历顺序没有稳定承诺。如果输出内容要用于接口返回、日志打印或者用在测试断言里，请先把键放进切片再自行排序。

遍历 map 时可以新增键吗？

可以正常写入，但新增的键本轮遍历可能被访问，也可能被跳过。需要确定性结果的场景，把新增内容写到另一个独立的容器里即可。

结语

在 range map 中删除元素，是 Go 为常见清理类任务留下的明确语法便利；它解决的只是迭代期间删除操作的合法性问题，不负责提供固定遍历顺序，也不负责协调并发读写。把“删除已遍历到的键”和“处理一组稳定输入”拆成两个阶段实现，代码、测试和线上运行日志的表现都会更容易预期和排查。