Go map删除后内存不释放是因为仅标记槽位为空且不缩容B值，底层buckets数组保留；真正释放内存需重建map。
Go map 大规模删除后不会自动收缩哈希桶容量，所谓“缩容”只是清理溢出桶，B 值不变，底层内存几乎不释放。
为什么 delete 后 map 占用内存没变？
调用 delete(m, key) 仅把对应 bucket 槽位标记为空，不触碰底层 buckets 数组，也不降低 hmap.B。你看到 len(m) == 0，但 runtime.ReadMemStats().Alloc 几乎不变——这不是 bug，是 Go 的明确设计。
- 普通桶（
2^B个）全部保留，哪怕一个元素都没了 - 溢出桶（overflow buckets）只在数量 ≥ 32768 或 ≥ 普通桶数（若
2^B ≤ 32768）时才被批量清理 - GC 只能回收键值对本身占用的堆内存，无法回收已分配的 bucket 内存
map 的“缩容”其实是等量重排
触发条件满足时，Go 调用 hashGrow，但传入 bigger = 0，即 sameSizeGrow：新旧 bucket 数量相同，B 值完全不变。
- 目的不是减内存，而是把散落在旧桶 + 溢出桶里的元素，重新 hash 到一组紧凑的新桶中
- 过程渐进式：每次
mapassign或mapaccess1顺带迁移 1–2 个旧 bucket，避免卡顿 - 迁移完成后，旧 bucket 和冗余溢出桶才被 GC 回收——但新 bucket 占用的内存和原来一样多
真正想释放内存，只能重建 map
如果你刚删掉 99% 的数据，且后续写入量小、键分布稳定，继续用原 map 会因残留溢出桶和稀疏主桶导致哈希冲突上升，插入/查找变慢 10%～30%。
- 正确做法：
m = make(map[K]V, estimatedCap)，其中estimatedCap是预估的后续峰值大小 - 别用
clear(m)：它和循环delete效果一致，不释放底层内存 - 如果键是大结构体或指针类型（如
*HeavyStruct），残留桶还会拖慢 GC 扫描速度
怎么判断是否该重建？
关键看两个指标，而非 len(m)：
- 观察
runtime.ReadMemStats().Mallocs和Alloc是否长期高位滞留 - 用
pprof看runtime.mapassign耗时是否明显高于基准（比如 p99 > 50μs） - 检查
go tool trace中是否存在大量 “oldbucket lookup” 分支跳转（说明还在渐进迁移期）
实际场景里，反复增删的 map 很容易变成“内存黑洞”——表面空了，底层却扛着百万级桶阵列。重建不是权宜之计，而是必要操作。
