Go 1.21 内置 clear 怎么清空 map：旧写法、并发边界与复用建议

服务端有一个按请求复用的 map[string][]byte，每次处理完都要清空。以前常见的写法是循环 delete，或者直接重新 make 一个 map。Go 1.21 之后，内置函数 clear 把这个动作写得更直接，但它只负责移除元素，不负责并发保护，也不保证下一次分配一定更省。

Go 1.21 内置的clear可以直接清空map所有元素，不用手动遍历挨个删除键，空map、nil map调用都不会panic，想复用现有map的底层存储空间优先选clear，并发访问的场景下还是要自己做好同步，不要误以为清空操作自带并发安全属性。

请求缓存为什么不该每次都重新 make

先看一个很常见的场景：批量接口把中间结果放到 scratch 临时 map 里，一次请求处理完之后继续复用这个 map。旧代码一般分两种写法。

for key := range scratch {
    delete(scratch, key)
}

// 或者直接换一张表
scratch = make(map[string][]byte)

第一种写法保留了map变量和内部的桶结构，下一轮写入的时候有机会直接复用已经分配好的空间；第二种写法让旧map变成待回收对象，变量直接指向新生成的空map，语义上更接近“换一个全新容器”。两种写法最后都能得到空map，但旧对象的释放时机和后续的分配行为完全不一样。

Go 1.21 的 clear 到底改变了什么

clear 是标准内置函数，不需要导入任何包。对map执行clear操作，结果就是map里不存在任何键值对，哪怕直接对nil map调用也不会触发panic。

package main

import "fmt"

func main() {
    scores := map[string]int{"alice": 90, "bob": 86}
    clear(scores)
    fmt.Println(len(scores), scores == nil) // 0 false

    var empty map[string]int
    clear(empty)
    fmt.Println(len(empty), empty == nil) // 0 true
}

这里有两个很多人容易搞混的点：普通非nil map清空后仍然是非nil状态，可以正常往里面写入新键值；nil map调用clear之后依然是nil，读取操作没问题但直接写入还是会panic。clear 不会自动把nil map变成可以直接写入的非nil map。

和 delete 循环相比，代码更短但语义没有变

clear(m) 刚好很直白地表达了“我要把这张map里所有元素全部移除”的意图。它不会把map变成nil，本身也不是什么并发原语。如果只是要删掉某一个指定键，还是直接用 delete 就好，没必要为了统一写法，把只删一个键的场景改成重建整个map。

clear、重新 make 和置 nil，怎么选才不误导

如果map是结构体字段或者对象池里的复用对象的一部分，清空之后马上还要写入规模差不多的数据，用 clear 来写最符合“复用这张表”的意图。但如果这个map里之前存过很大的临时对象，或者旧map还被其他代码引用，重新 make 生成新map，能更清晰地切断当前变量和旧容器的关联。

要注意，清空map只是移除了所有键值对的关联。如果值本身包含大对象的指针，运行时会正常处理元素的槽位，但业务代码依然要判断是保留整个容器，还是把它交回对象池。别直接把“len(m) == 0”等同于“这部分内存马上就归还给操作系统”。

切片上的 clear 不是缩容操作

对切片调用 clear(s)，会把当前长度范围内的所有元素设为对应类型的零值，len 和 cap 的值都不会变。

buf := []string{"a", "b", "c"}
clear(buf)
fmt.Println(buf, len(buf), cap(buf)) // [  ] 3 3

buf = buf[:0] // 只改长度，不清除底层数组中的旧值

如果清空之后切片马上就会被完全覆盖，用 buf = buf[:0] 通常已经完全够用；如果切片会长时间存活，又不希望旧元素继续被底层数组持有引用，这时候才需要用到 clear(buf)。想要主动释放多余的容量，就得重新分配或者让切片彻底不再被引用。

为什么 clear 解决不了并发读写

下面这段代码就算把原来的循环删除全部换成 clear，依然是完全不安全的：

go func() {
    clear(shared)
}()

go func() {
    _ = shared["request-id"]
}()

同一个map被一个goroutine写，另一个goroutine同时读，很容易触发Go运行时自带的并发map读写报错。常见的解决办法是把清空和访问操作都放到同一把锁的保护范围内，或者把map的所有权收拢到单个goroutine里，通过channel传递读写请求。

mu.Lock()
clear(shared)
mu.Unlock()

锁的覆盖范围要完整包住整个读写流程。只单独给 clear 加锁，其他写入操作绕开同一把锁，保护逻辑依然是不完整的。

升级到 Go 1.21+ 前后的检查清单

• 确认 go.mod 里的语言版本和CI环境用的Go工具链，都能支持内置 clear 函数。
• 把“删除全部元素”和“生成新空表”两种场景分开审查，不要直接全量机械替换成clear。
• 检查map有没有跨goroutine、回调函数或者缓存层共享，有必要的话补上同步逻辑或者调整所有权分配。
• 对池化复用的对象补充基准测试，对比真实业务数据规模下 clear 和重新 make 的分配情况和延迟表现。

相关问答

nil map 可以调用 clear 吗

可以，不会触发panic；调用之后它依然是nil map。读取操作依然安全，要写入之前必须先做make初始化。

clear 会把 map 变量变成 nil 吗

不会。对非nil map调用clear之后，map依然可以正常写入；如果需要变量处于nil状态，直接显式赋值为nil就好。

clear 能替代并发保护吗

不能。它只是一个普通的清空操作，没法替代互斥锁、读写锁或者单goroutine所有权这类同步方案。

切片清空后容量会减少吗

不会。clear(s) 不会改变切片的长度和容量；想要缩容得重新分配一个容量更小的新切片。

最后的采用建议

把 clear 当成一个表意更准确的“清空容器”语法就好：map接下来还要复用就直接清空，想彻底切断旧容器的关联就重新make，想要彻底放弃当前引用就赋值nil；并发访问的场景单独设计好同步边界。这样升级之后代码更简洁，判断逻辑也不会被一个新内置函数的名字带偏。