Go clear 怎么用：map 和 slice 清空后的容量、引用与复用边界

做批处理服务的时候，每轮都要清空临时 map 和复用缓冲区，很多人会直接写一串 delete，或是把 slice 重新切成 [:0]。Go 1.21 的 clear 把“清空”这个动作写得更直白，但它对 map 和 slice 的处理语义完全不同：map 会删掉所有键值，slice 只会把现有元素设为对应类型的零值，长度和容量都完全保留。

先看 clear 的最小可用写法

clear 是 Go 1.21 加入的内置函数，参数必须是 map、slice，或者泛型实例化后底层类型为这两者的类型。它没有返回值，调用后直接观察原对象状态即可。

package main

import "fmt"

func main() {
	counts := map[string]int{"ok": 3, "fail": 1}
	clear(counts)
	counts["retry"] = 2

	buf := []string{"a", "b"}
	clear(buf)

	fmt.Println(counts) // map[retry:2]
	fmt.Printf("len=%d cap=%d values=%q\n", len(buf), cap(buf), buf)
}

这里的两个结果很容易被混在一起：counts 变成空 map 后仍然可写；buf 的长度仍是 2，只是两个字符串被置成空字符串。若希望 slice 变成“没有元素”的状态，清空后还要写 buf = buf[:0]。

map 清空后仍可写，重新 make 不是同一件事

map 场景更接近“保留容器、删除内容”。这适合按租户或按批次复用统计表：下一轮可以沿用同一个 map 变量，不必在每个循环里重新声明。

func rebuildSummary(summary map[string]int, rows []string) {
	clear(summary)
	for _, key := range rows {
		summary[key]++
	}
}

对外仍持有同一个 map 引用的代码会看到清空结果。这个特性既方便，也可能造成误判：如果另一个 goroutine 在没有同步的情况下读写 summary，问题不是 clear 特有的，而是 map 并发访问本身不安全。

clear(map) 与重新 make 的边界

clear(summary) 保留 map 对象；summary = make(map[string]int) 则让当前变量指向新对象。下面这个差异在函数参数和共享状态里很关键：

func clearInPlace(m map[string]int) {
	clear(m)
}

func replaceMap(m map[string]int) {
	m = make(map[string]int)
}

调用 clearInPlace 后，调用方持有的 map 会变空；调用 replaceMap 后，调用方原来的 map 仍然保留旧键值，因为函数参数只是 map 头部的副本。需要切断旧对象的共享关系时，明确返回新 map 往往更易读。

slice 清空有两种意图：归零，还是只回收长度

slice 的底层结构包含指针、长度和容量。clear(buf) 处理的是当前 len(buf) 范围，把每个元素写成元素类型的零值；它不会调整长度，也不会改变容量。

func reuseBuffer() {
	buf := make([]*Job, 0, 1024)
	buf = append(buf, &Job{ID: 7})

	clear(buf) // 清掉当前元素引用
	buf = buf[:0]
	// 此时 len(buf)==0，cap(buf)==1024，可继续 append
}

type Job struct{ ID int }

如果元素是指针、字符串或含指针字段的结构体，归零可以让底层数组不再继续持有旧对象引用。只写 buf = buf[:0] 时，逻辑长度虽然为零，但数组中原来的指针仍可能存在，直到后续 append 覆盖它们。

什么时候不要把 clear 当成释放内存

对于 slice，clear 只是改写元素；对于 map，它删除键值但不承诺底层存储马上缩回。长时间持有、容量已经明显超出后续需求的容器，建议在批次边界按阈值换新对象。

func resetJobs(buf []*Job, maxCap int) []*Job {
	if cap(buf) > maxCap {
		return make([]*Job, 0, maxCap)
	}
	clear(buf)
	return buf[:0]
}

阈值不要凭感觉写。可以先用 cap、批次耗时和堆内存曲线观察真实峰值，再决定是保留容量，还是在大批次之后缩容。清空操作本身不是内存治理方案。

用一个小实验核对引用和容量

遇到“清空后对象还在不在”的争议，先写一个能打印状态的小实验。不要只看 len，同时记录容量、元素值和共享 slice 的观察结果。

package main

import "fmt"

func main() {
	items := []*int{new(int), new(int)}
	items[0] = new(int)
	alias := items

	fmt.Println(len(items), cap(items), alias[0] != nil)
	clear(items)
	fmt.Println(len(items), cap(items), alias[0] == nil)

	items = items[:0]
	fmt.Println(len(items), cap(items), len(alias))
}

最后一行仍能看到 alias 的长度，因为两个 slice 变量共享同一个底层数组，但 clear(items) 已经把数组中当前元素置零。这个实验也提醒我们：slice 的“长度视图”和“数组内容”是两层概念。

常见误区与检查清单

• 把 clear(buf) 当成 buf[:0]：前者归零元素，后者只改变长度。
• 清空后继续读取旧下标：slice 长度不变不代表元素仍有业务意义，map 则必须重新按 key 查询。
• 把 clear 当成并发保护：共享 map 仍需要互斥锁、读写锁或单线程所有权。
• 只凭一次内存快照决定缩容：先观察批量大小分布，再设容量阈值并做基准对比。

相关问题

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

不会。它只是删除键值，map 仍可写；只有显式赋值为 nil，才会变成 nil map。

clear(slice) 会把 len 变成 0 吗？

不会。它保留原来的长度和容量；要让长度归零，需要再赋值为 slice[:0]。

只想复用 slice 时该选哪个写法？

元素不含需要尽快释放的引用时，通常用 slice[:0]；元素含指针或大对象引用时，先 clear(slice) 再切到零长度。

收尾：把“清空”拆成状态和资源两个问题

Go 的 clear 解决的是内容归零或删除键值，不替你决定对象是否复用、容量是否保留以及共享引用何时断开。map 复用看键值生命周期，slice 复用同时看元素引用和容量峰值。把这几个问题拆开，再用一个小实验和一条内存指标验证，代码会比“每次都重新 make”更容易解释。