Go clear 内置函数清空 map 后容量和底层存储怎么理解

如果你把一个装过很多数据的 map 传给 clear，最可靠的结论只有一个：所有键值条目被删除，len(m) 变成 0，map 仍然可以继续写入。它不等同于“拿到了一个可查询的 map 容量”，因为 Go 语言没有提供 cap(map)；也不能据此断言底层桶会立刻归还给操作系统。

先看清 clear(map) 保证了什么

clear 从 Go 1.21 开始成为内置函数。对 map，它的语义是删除所有条目；对 nil map 则是 no-op。因此下面的 m["new"] = 2 仍然合法，不能把清空误认为把 map 变成了 nil。

package main

import "fmt"

func main() {
	m := map[string]int{"old": 1}
	clear(m) // 中文说明：只删除现有键值，保留 map 的可写状态。
	m["new"] = 2 // 中文说明：清空后仍能写入新条目。
	fmt.Println(len(m), m["new"]) // 中文说明：输出 1 2，验证条目数和新值。

	var nilMap map[string]int
	clear(nilMap) // 中文说明：nil map 上 clear 是空操作，不会触发 panic。
}

与逐个 delete 相比，clear 更直接地表达“整个容器进入空状态”。如果调用方仍持有这个 map，清空结果会立即反映到它看到的内容。

区分容量问题与底层存储问题

这里最容易混淆“元素数量”“预估容量”和“运行时内部存储”。规范只定义 len(m) 是当前已定义键的数量；make(map[K]V, hint) 的 hint 是容量提示，不是固定上限，也没有对应的 cap(m) 查询。

当前 Go 运行时源码可以看到清理逻辑会把使用计数置零，并保留内部表相关结构；源码还把目录收缩标为实现层 TODO。这个观察解释了为什么清空后再次填充可能复用已有空间，但它不是应用代码可以依赖的跨版本容量契约。生产代码不要用一次 clear 后的 RSS 变化来判断“已经释放”。

用别名和重新 make 处理生命周期

map 赋值复制的是对同一底层 map 的引用关系，而不是把全部键值复制一份。所以 alias := m 后执行 clear(m)，alias 也会看到 len(alias) == 0。这适合缓存、临时索引等“所有持有者都应看到新一轮空状态”的场景。

如果目标是让当前变量改用一个全新的容器，写成 m = make(map[string]int)。这会切断当前变量与旧 map 的关系，但不会神奇地让仍在别处保存的 alias 失效；只有旧 map 没有其他引用后，垃圾回收才可能回收它，回收时间也不由这条赋值同步决定。

把清空策略放进可复用代码

可以用下面的判断表选方案：

尤其注意最后一行：普通 map 在没有同步时并不能因为换成 clear 就允许并发读写。若多个 goroutine 共享它，使用互斥锁、所有权转移或合适的并发容器，把“谁负责清空、谁还能访问”定义清楚，通常比追逐内部内存数字更重要。

延伸问答

clear(map) 后还能继续 append 吗？

map 没有 append 操作；清空后可以继续用索引赋值添加键值。若你说的是 slice，clear 会把已有长度范围置零，slice 的长度和容量语义另行处理。

clear(map) 会把 map 变成 nil 吗？

不会。nil map 与空 map 都可能有 len==0，但 nil map 不能直接写入；clear 一个已初始化 map 后仍可写。

怎样证明 clear 释放了多少内存？

不能用语言级 cap 证明，因为 map 没有这个接口。若确实要降低旧容器的生命周期，替换为新的 make 并解除旧引用，再结合运行时指标观察趋势，而不要把某一次 GC 或 RSS 读数当作契约。