Go map 读取为什么不能在 range 中删除后再写入

可以先把结论说清楚：在同一个 goroutine 里，Go 允许你在遍历 map 时删除键；但这不是一个稳定快照。遍历开始后删除尚未读到的键，它不会再产生；遍历中新增的键是否被读到则没有保证。若另一个 goroutine 同时写入，问题就从“结果不确定”升级为并发读写故障。

因此，range 期间“删除后再写入”并非语法上绝对禁止，真正的判断标准是访问是否并发，以及业务是否要求固定的处理集合。

单 goroutine 过滤可以原地删除；需要确定性结果就先确定键集合；跨 goroutine 访问必须用锁或其他同步边界保护整个操作。

先区分：同一 goroutine 还是并发读写

很多报错现场把两件事混在了一起。下面的代码只有一个执行流，删除当前键是合法的，最终 map 会保留分数不低于 60 的记录：

package main

import "fmt"

func main() {
	results := map[string]int{"go": 90, "mysql": 55, "redis": 80}
	for name, score := range results {
		// 过滤动作只发生在当前 goroutine；删除不会让后续访问变成并发访问。
		if score 

这里不要根据输出顺序判断逻辑，因为 map 的迭代顺序不承诺稳定。若代码在另一个 goroutine 中持续写入，常见故障信息会指向 concurrent map iteration and map write；这时需要查调用关系，而不是把 delete 当成唯一原因。

为什么删除后再写入不能当成稳定遍历

Go 规范对 map 的 range 只给出有限保证：尚未到达的条目如果被删除，就不会产生；遍历期间创建的条目可能被产生，也可能被跳过。这个规则允许运行时安全地完成一次遍历，但没有承诺“本轮新增值一定再处理一次”。

例如下面的代码可以运行，却不适合表达“把所有命中项移动到新键并且新键也必须继续处理”这样的需求：

func rewrite(m map[string]int) {
	for key, value := range m {
		if value 

如果目标只是过滤，原地 delete 足够；如果目标是迁移且要求每个输入只处理一次，先收集键再执行变更更清楚。若还需要让新增项继续处理，应显式开启下一轮，而不是依赖当前 range 的实现细节。

需要确定结果时的两种处理方案

第一种是两阶段更新：第一遍只读取并保存要改动的键，第二遍统一删除或写入。这样业务集合在代码层面是显式的，后续维护也不会误把新键当作当前遍历输入。

func removeExpired(m map[string]int, limit int) {
	var expired []string
	for key, deadline := range m {
		// 第一阶段只收集决策，不改变正在读取的 map。
		if deadline 

第二种是重建新 map：当过滤逻辑较复杂、还要同步转换值时，新旧对象分离更容易验证。若 map 会被多个 goroutine 访问，则无论使用哪种方案，都要用互斥锁覆盖“读取决策到写入完成”的完整临界区，不能只给单条赋值加锁。

排查清单：看到异常时按这个顺序确认

• 是否有 goroutine、定时任务或回调在同一时间写入这张 map？先画出访问者，而不是只看当前函数。
• 业务需要的是“过滤现有键”，还是“新增键也必须继续处理”？前者可原地删除，后者应拆成明确的多轮或两阶段流程。
• 代码是否依赖遍历顺序或把 map 当快照？如果依赖，先复制键集合并排序，或改用有序数据结构。
• 锁是否覆盖整个 range 和后续修改？只保护写入语句，仍可能在遍历期间发生竞争。

简要记忆：单 goroutine 中删除是允许的，新增键的继续遍历不保证；并发访问必须同步；稳定业务结果要把“读取集合”和“修改集合”拆开。

常见追问

range 中 delete 当前键会漏删吗？不会因为删除当前键而产生语言层面的漏删；但不要把 map 顺序当作可预测顺序，复杂筛选仍建议两阶段处理。

给 map 赋值为什么有时直接崩溃？重点检查是否存在并发读写。单 goroutine 内的赋值通常不会触发并发读写故障，但它仍可能改变本轮遍历集合，结果不能按快照理解。

本文依据 Go 语言规范中 for range 对 map 删除和新增条目的语义说明组织示例，官方资料地址：https://go.dev/ref/spec#For_statements。