Go maps 包批量清空 map 保留容器的使用边界

在缓存一轮计算结果、复用工作区 map 时，我更倾向于把“清空条目”和“更换容器”分开处理。Go 1.23 起，标准库 maps 包提供了 DeleteFunc：让删除条件返回 true，就能一次移除所有键值对，同时保留原 map 变量和已有别名。需要注意的是，它只改变 map 的内容，不负责并发保护，也不承诺把运行时占用的容量立刻归还给操作系统。

先把“清空”与“重建”分成两件事

maps.DeleteFunc 的签名接收一张 map 和一个删除谓词。谓词对每个键值返回 true 时，条目会被删除；因此“全部清空”并不是特殊 API，而是一个恒真的条件。它适合工作区、复用缓存和需要保持别名可见的场景。

package main

import "maps"

func clearAll[K comparable, V any](m map[K]V) {
	// 恒真谓词表示删除当前 map 中的全部键值对。
	maps.DeleteFunc(m, func(K, V) bool {
		return true
	})
}

这里没有给 m 重新赋值，所以调用者手里的 map 引用仍然有效。len(m) 会变成 0，之后仍可以直接写入。

恒真谓词的边界：nil、别名与共享数据

对 nil map 调用删除操作不会触发写入，因此可以安全执行；但清空后若要继续写入，必须先确保 map 已初始化。更容易忽略的是别名：

func reuse[K comparable, V any](m map[K]V) map[K]V {
	// 删除共享 map 的内容，所有仍持有该 map 的变量都会看到空结果。
	maps.DeleteFunc(m, func(K, V) bool { return true })
	return m
}

func replace[K comparable, V any](m map[K]V) map[K]V {
	// 重新分配会换掉容器身份，旧别名不会自动指向新 map。
	return make(map[K]V)
}

如果结构体、缓存对象或回调里保存了同一张 map，优先用前者；如果目标是尽快丢弃一个很大的临时容器、并且确认没有别名，才考虑重建。不能把两种语义混成“都叫清空”。

把性能与并发问题单独判断

批量删除会遍历当前条目，复杂度应按 map 中的元素数量理解；它不会把后续插入成本变成零，也不能保证底层容量立即缩小。若 map 会持续高频复用，保留容器可以减少反复分配；若数据规模偶发暴涨，重建可能更符合内存生命周期，但要先解决别名问题。

maps.DeleteFunc 也不是并发容器。清空期间如果另一个 goroutine 同时读写同一张普通 map，仍可能触发数据竞争或运行时错误。用互斥锁保护整个清空与访问区间，或改用明确的消息传递边界。

常见问题

maps 包的清空函数会把 map 设为 nil 吗？

不会。它删除键值对，map 变量本身仍指向原容器；只有显式赋值为 nil 才会改变变量状态。

清空后可以马上继续写入吗？

可以，前提是 map 非 nil 且没有并发访问冲突。nil map 删除安全，但写入会 panic。

要释放大 map 的内存应该选哪种方案？

先确认没有别名，再用新 map 替换旧变量；不要把“len 为 0”当成已经归还全部运行时内存。

实际使用时，我会先问一个问题：调用方需要的是“所有观察者看到空内容”，还是“旧容器彻底退出生命周期”。前者用 maps.DeleteFunc，后者才考虑重建，边界清楚后代码通常就不会再绕。