Go map 遍历时删除键为什么安全：同一轮 range 的可见性与边界

清理过期会话时，很多 Go 代码会直接在 range 里调用 delete。对同一个 map、同一个 goroutine 来说，这种写法是语言允许的；但“允许删除”不等于“遍历有固定顺序”。删除还没走到的键，本轮不会再产出它；循环里新加的键，则可能被看到，也可能被跳过。

先看最常见的清空写法

如果目标只是清空一个不再复用的 map，直接重新赋值通常更简单；如果还需要沿途统计、记录或按条件删除，才会在遍历体里调用 delete：

func removeExpired(sessions map[string]int, now int) int {
    removed := 0
    for id, expiresAt := range sessions {
        if expiresAt 

这段代码不会因为删除当前键而触发迭代器失效。Go 语言规范明确规定：如果一个尚未到达的 map 元素在迭代中被删除，对应的迭代值不会被产生。于是，已经判断过的键不会在本轮再次出现，尚未判断的过期键可能直接被删掉。

Go 中在同一次 range 遍历 map 的过程里删除正在访问的键，不会触发报错也不会出现遍历异常，这是 Go 运行时对 map 迭代器做的特殊可见性约定，不是语言层面的巧合特性。

删除当前键和删除其他键，区别在哪里

“删除当前键安全”容易被误读成“遍历过程有一个固定快照”。实际上，规范只保证删除行为的结果边界，没有承诺键的顺序，也没有承诺本轮会访问删除前的全部键。

因此，下面这种代码可以用于清理，但不能用来计算一个稳定的“原始条目总数”：循环过程本身可能改变后续可见集合。

for key := range items {
    if shouldDrop(key) {
        delete(items, key)
    }
}

为什么不能把 map range 当成快照

map 的迭代顺序没有规范保证，同一个程序两次运行也不应该拿顺序作断言。测试里如果把键收集到切片后直接比较顺序，偶发失败并不说明 delete 破坏了 map；更可能是测试把未定义的顺序当成了接口。

keys := make([]string, 0, len(items))
for key := range items {
    keys = append(keys, key)
}
// 如果需要稳定结果：先 sort.Strings(keys)，再按 keys 读取 items。

如果业务要求“先处理优先级高的键”，请先建立独立的键切片并排序，或者维护一个明确的队列。不要尝试通过多次 range 猜测 map 的内部顺序。

新增键的边界：可能出现，也可能跳过

同一轮迭代里写入新键也不会得到稳定的遍历协议。新键是否出现在当前循环，规范允许实现选择。下面的代码可以运行，但不应该用输出数量证明新键一定会被处理：

for key := range items {
    if needFollowUp(key) {
        items[key+"-retry"] = true
    }
}

如果新增任务必须在本轮完成，使用显式队列：先把待处理键放入切片，循环切片时把新任务追加到切片尾部；如果要求批次边界清楚，则把新任务留到下一批。这样，处理范围由数据结构表达，而不是交给 map range 的实现细节。

并发读写时，合法删除也救不了普通 map

前面的结论只针对同一 goroutine 内的操作。一个 goroutine 在 range，另一个 goroutine 同时写入或删除普通 map，程序可能直接触发运行时错误，也可能产生数据竞争。需要并发访问时，根据读写比例选择互斥锁保护的 map，或评估 sync.Map 的语义；不要把“遍历中可以 delete”理解成并发安全。

type SessionStore struct {
    mu       sync.RWMutex
    sessions map[string]int
}

func (s *SessionStore) RemoveExpired(now int) int {
    s.mu.Lock()
    defer s.mu.Unlock()
    removed := 0
    for id, deadline := range s.sessions {
        if deadline 

把锁覆盖整个遍历和删除过程，读写边界才是可检查的。若锁粒度太大影响延迟，可以先在锁内复制键或待删项，再缩短后续工作，但复制过程本身仍需受保护。

写测试时应该断言什么

针对清理函数，测试应断言最终 map 内容、删除数量和保留条件，而不是断言 range 的访问顺序。并发代码再加上 go test -race ./...，把数据竞争交给工具发现。

• 清理后的 map 不再包含满足过期条件的键。
• 未过期键仍然存在，且对应值没有被意外覆盖。
• 删除数量等于最终被移除的条目数，而不是某种假定的遍历顺序。
• 新增键的处理批次有明确约定，不能依赖本轮是否碰巧看到。

相关问题

delete 删除不存在的 map 键会报错吗？

不会。删除不存在的键没有效果，因此清理代码通常不需要先写一次存在性判断。

range map 的顺序能不能在测试中固定？

不能把它当作稳定协议。需要可重复结果时，把键复制到切片并显式排序。

clear 和逐个 delete 应该怎么选？

只想清空整个 map 时可以考虑 clear 或重新创建 map；需要条件判断、统计和审计信息时，逐个 delete 更容易表达意图。

把边界写进代码约定

Go 允许在 map range 中删除，是为了让条件清理不必额外维护一份待删除列表；它并没有把 map 变成有序容器或快照容器。把“最终内容”作为断言，把“访问顺序”和“新增键是否当轮处理”留给明确的数据结构，代码就不会被运行时的偶然输出带偏。