delete 不释放 map 底层内存，仅标记槽位为空；删光所有 key 后 Alloc 不变属正常，因 buckets 数组仍驻留堆上；只有置 nil 才能让 GC 回收整个 map 对象。
delete 不会释放 map 底层内存，这是设计使然，不是 bug。
delete 后 Alloc 几乎不变？正常
调用 delete(m, key) 仅将对应 bucket 中的槽位标记为“空”，不缩容底层 buckets 数组，也不归还内存给操作系统。你用 runtime.ReadMemStats 观察到 Alloc 基本不变，是预期行为。
- 底层哈希表结构（包括桶数组、溢出链）仍完整保留在堆上
- GC 不扫描纯值类型（如
int、string）的 map 元素 —— Go 1.5+ 的优化，意味着它连“是否还在用”都不检查 - 即使删光所有 key，只要变量本身还活着，GC 就无法安全回收整个 map 对象
什么时候该手动置 nil？
当你明确知道某个 map 不再需要，且它是长生命周期变量时，必须立刻赋值为 nil。
- 典型场景：缓存淘汰、配置重载、连接关闭后清理状态、struct 字段、全局变量、闭包捕获的 map
-
nil让 GC 明确知道“这个 map 对象整体可回收”，包括它的 buckets 内存 - 仅
delete所有 key ≠nil：map 容量不变，底层数组仍在，GC 无法回收 -
nil后再写入会 panic，确保后续无访问；若需复用，应重建make(map[K]V)
局部变量 vs 全局变量的 GC 行为差异
局部变量 map 在函数返回后可能被 GC 快速回收；全局或长生命周期 map 即使删光所有 key，buckets 仍驻留堆上。
- 局部变量：作用域结束即失去引用，GC 可在下一轮快速回收整块 map 结构
- 全局变量：变量本身一直可达，GC 很难判定其底层 buckets “可回收”，哪怕里面全是空槽
- 间接引用也会阻断回收：比如 map 被某个未关闭的 goroutine、channel、或闭包持有，GC 会跳过它
- 手动调用
runtime.GC()只是建议运行时“现在做一次 GC”，不保证立即执行，也不保证回收全部目标内存
真正决定 map 内存能否释放的，从来不是 delete 调用次数，而是“还有没有变量能访问到这个 map 对象”。别依赖 delete 清内存，该 nil 就 nil，该重建就重建。高频增删场景下，原生 map 容易因碎片化和 GC 滞后导致内存虚高，比反复 delete 更干净的做法是直接重建新 map。
