Go map delete 后槽位可重用但内存不缩容，clear 也不回收 bucket；历史扩容导致桶数组长期驻留，影响性能，应根据数据量级评估是否重建 map。
delete 后的 bucket 槽位会被重用，但底层内存不缩容
Go 的 map 删除一个 key 时，delete(m, k) 只是把对应 bucket 中该槽位的键和值清零，并标记为“空”，不释放 bucket 内存，也不调整哈希表大小。后续插入新 key 时，runtime 会优先尝试填入这些已清空的槽位——这是内存重用的核心机制。
- 重用只发生在**同一 bucket 内已有空槽**时；若哈希冲突严重、溢出桶堆积，新 key 可能被塞进溢出链，而非复用主桶空槽
- 即使
len(m) == 0，只要 map 对象还活着，所有已分配的 bucket（包括主桶和溢出桶）都保留在堆上 - 值类型（如
int、[32]byte）的元素被 delete 后，其占用的 slot 空间直接归零，但所在 bucket 不会被 GC 回收——因为 bucket 数组本身仍被 map header 引用
clear() 和循环 delete 在重用行为上没区别
clear(m)（Go 1.21+）本质是 runtime 层的批量清空：它重置 map 的计数器、迁移状态和溢出计数，但**不回收任何已分配的 bucket 内存**，也不改变哈希分布。它比手写 for range + delete 快，是因为避免了多次函数调用开销，但底层重用逻辑完全一致。
- 两者都不会让 map “回到刚 make 出来的紧凑状态”；残留的溢出桶仍存在，插入时仍需遍历指针链
- 如果你观察到
runtime.ReadMemStats().Mallocs没下降，说明 bucket 内存确实没还，这是预期行为 - 不要对全局或长生命周期 map 用
clear()后继续插入——性能可能比新建一个同容量 map 差 10%～30%
真正影响重用效率的是 key 分布和历史容量
map 的哈希桶结构一旦扩容，就不会自动缩容。一个曾装过 10 万条记录的 map，即使只剩 10 个 key，它的 bucket 数组大小仍维持在扩容后的级别。这导致：
- 哈希掩码变大，相同 key 计算出的 bucket index 更分散，主桶利用率下降
- 大量空主桶 + 零星溢出桶，查找时要跳转更多指针，缓存局部性变差
- GC 无法回收这些空桶，因为 map header 仍持有对整个 buckets 数组的引用
什么时候该放弃重用，直接重建 map
当你的使用模式是“删光 → 重新灌入一批新数据”，尤其是这批新数据量级稳定（比如每次约 5000 条），就别复用旧 map。重建是唯一能重置哈希结构、释放冗余 bucket 的方式。
- 用
make(map[K]V, N)预估容量初始化，避免后续扩容抖动 - 全局变量或 struct 字段中的 map，删除后必须显式赋
nil，否则 GC 无法判定整个 buckets 数组可回收 - 并发场景下重建更安全：可用
atomic.StorePointer原子替换指针，避免fatal error: concurrent map read and map write
最常被忽略的一点：map 的“历史容量”不是无成本的——它持续占用堆内存、增加 GC 扫描压力，且无法通过 delete 或 clear 逆转。重用的前提是确认它真比重建便宜；否则，宁可多一次 make。
