Go map delete 不缩容，空桶残留致内存碎片；值类型优化使GC不扫描值引用，仅map整体不可达才回收；重建map或显式置nil是唯一有效清理方式。
delete 后 map 底层 bucket 不缩容，空洞残留导致碎片化
Go 的 delete 只清空桶（bucket）内对应槽位，不释放 bucket 内存，也不重排哈希结构。即使 len(m) == 0，原分配的主桶数组和溢出桶链仍完整驻留在堆上。这些“空但已分配”的桶构成内存碎片：它们占着地址空间、阻碍 GC 回收，且后续插入时仍需遍历稀疏桶链，加剧哈希冲突。
典型表现是：runtime.ReadMemStats().Alloc 在大量 delete 后几乎不变；pprof heap profile 显示 runtime.mallocgc 分配的 bucket 内存块持续存在。
值类型影响 GC 对碎片的识别能力
Go 1.5+ 对纯值类型（int、string、小数组等）的 map 元素做了 GC 优化：运行时不扫描这些值是否被引用，直接跳过回收判断。这意味着：
- 即使你删光了所有键，底层 bucket 内存也不会因“值已无引用”而被提前标记为可回收
- GC 只能等整个 map 对象本身变成不可达（比如变量作用域结束或被置为
nil）才一并回收 buckets - 若 map 是 struct 字段或全局变量，这种“不可达”可能永远不发生
重建 map 是唯一能真正清理碎片的操作
想让 map 回到紧凑、低冲突、低内存占用的状态，必须放弃复用旧 map。不是 clear(m)，也不是循环 delete，而是新建：
- 知道下次插入量 ≈ N：用
make(map[K]V, N)预分配，避免扩容抖动 - N 波动但有上限（如 ≤ 5000）：按上限初始化，比复用一个曾装过 10 万条的 map 快 15%～40%
- 并发读写场景下，重建还能配合原子指针切换（
atomic.StorePointer），规避concurrent map read and map writepanic
注意：m = make(map[K]V) 后立刻 clear(m) 是反模式——等于白分配一次内存。
全局/长生命周期 map 必须显式置 nil 才能触发回收
局部变量 map 函数返回后 GC 通常较快回收；但全局变量、struct 字段、闭包捕获的 map，只要变量还活着，buckets 就不会被 GC 判定为可回收。此时仅靠 delete 或 clear 毫无意义。
正确做法是：确认不再需要该 map 后，立即赋值为 nil。这向 GC 明确传达“整个对象可回收”，包括其 buckets 数组和所有溢出桶。但要注意：nil 后再写入会 panic，确保无后续访问，或改用重建逻辑。
碎片问题最隐蔽的地方在于：它不报错、不 panic，只悄悄拖慢插入/查找，并让 pprof 看起来像内存泄漏——而根源只是你一直没放手那个旧 map。
