Go 遍历 map 时删除元素是否一定安全

在同一个 goroutine 里用 for range 遍历 map 时调用 delete，通常是安全的：删除已经拿到的键不会影响当前语句继续执行；如果删除的是尚未到达的键，这个键本轮不会再产生迭代值。真正不能忽略的是，map 的遍历顺序没有保证，而且这条规则不等于允许多个 goroutine 同时读写同一个 map。

结论：单 goroutine 的“遍历并删除”是 Go 语言明确允许的用法；需要稳定顺序时先收集并排序键，需要并发访问时给整个读写区间加锁或交给单独的 goroutine 管理。

下面按值班排障的方式，把安全范围、异常信号和可回退写法拆开。

单 goroutine 删除为什么不会漏出脏数据

最小清理写法可以直接放在循环体里。delete 删除不存在的键也是无操作，因此条件判断可以保持简单。

pending := map[string]bool{
    "job-a": true,
    "job-b": false,
    "job-c": false,
}

for name, ready := range pending {
    if !ready {
        delete(pending, name) // 删除当前键或后续键，不会让 range 失效
    }
}

这段代码结束后，pending 只保留值为 true 的条目。语言规范规定：遍历期间删除尚未到达的 map 条目时，对应的迭代值不会产生。因此，删除动作不会把已经删除的键“补发”给循环，也不需要复制一份 map 才能完成这种原地清理。

这里的安全指“语言语义允许且不会因为这次 delete 本身崩溃”，不是指循环有固定顺序，也不是指所有业务副作用都天然安全。若循环体还会写数据库、发消息或调用外部服务，仍要单独处理幂等和失败回滚。

遍历顺序和新增元素不能当作业务规则

map 的迭代顺序没有指定，每次遍历都可能不同。删除已经访问过的键不会让它再次出现；删除尚未访问的键则让它跳过。反过来，如果循环中创建新键，新键可能被本轮访问，也可能被跳过，具体选择不应写进业务判断。

因此，以下做法风险很高：依赖第一个遍历到的键作为优先任务、假设删除后下一个键固定不变、在循环里新增键并期待它一定被处理。nil map 则更简单，遍历次数为零，删除 nil map 的键也是无操作。

如果结果需要可复现，例如生成审计清单或按优先级处理任务，先把键复制出来，再排序和处理：

keys := make([]string, 0, len(pending))
for name := range pending {
    keys = append(keys, name) // 先保存键，避免把 map 顺序当成顺序依据
}
slices.Sort(keys)

for _, name := range keys {
    if !pending[name] {
        delete(pending, name) // 按已确定的键集合执行清理
    }
}

示例使用 Go 1.21 及以后可用的 slices 包；如果项目版本更早，可换成 sort.Strings(keys)。排序解决的是输出稳定性，不是并发保护。

出现并发 map 报错时要先查访问边界

如果一个 goroutine 正在 range，另一个 goroutine 同时写入或删除同一个 map，问题已经超出“遍历中 delete 是否安全”的范围。常见信号是运行时报告 concurrent map iteration and map write，或者在竞态检测中发现 map 读写冲突。

处理时要把锁覆盖整个遍历与删除区间，而不是只给某一次 delete 加锁：

type Queue struct {
    mu      sync.Mutex
    pending map[string]bool
}

func (q *Queue) RemoveNotReady() {
    q.mu.Lock()
    defer q.mu.Unlock() // 确保异常返回时也释放锁

    for name, ready := range q.pending {
        if !ready {
            delete(q.pending, name) // 遍历和删除处于同一临界区
        }
    }
}

实际编译时记得导入 sync。若读操作很多，也可以重新设计快照：加读锁复制一份，再在独占锁下提交删除；不要在释放锁后继续使用可能已被其他 goroutine 改变的迭代假设。

需要回滚或审计时选择可复查的清理方式

临时缓存通常适合直接 range-delete；审计、批处理和需要回滚的任务，更适合把“发现”和“修改”分成两阶段。第一阶段记录待删键及原因，确认数量和排序后再执行删除。这样即使后续动作失败，也能根据待删清单重建或补偿，而不是依赖一次不可重复的 map 遍历顺序。

上线前可以按这张清单复核：

• 只在一个 goroutine 内操作 map 时，range 中 delete 是否符合预期。
• 代码是否错误依赖 map 顺序或新增键必然被访问。
• 是否存在其他 goroutine 同时写入；若有，锁或所有权边界是否覆盖整个循环。
• 删除前是否需要记录原因、数量和可恢复信息。

相关问题

遍历 map 时删除当前键会不会跳过下一个键？不会按数组下标那样产生可推断的“下一个键”；map 顺序本来就不保证，规范只保证被删除且尚未到达的键不会产生迭代值。

能不能在 range map 里新增键？语法和语言规则允许，但新键本轮可能出现，也可能不出现。需要完整处理新增任务时，应放到下一轮或使用显式队列。

事实依据：Go 语言规范的 range map 条款和内置函数 delete 说明，均来自 Go 官方文档。