Go map调用delete()后不缩容buckets数组，仅逻辑删除键值对，底层桶数组仍驻留堆内存且不被GC回收。
delete() 不会缩容底层 buckets 数组
go 的 map 底层是哈希表，由 hmap 结构管理一组 buckets（桶），每个桶固定大小、可存多个键值对。调用 delete(m, key) 时，仅把对应槽位标记为“空”，但整个 buckets 数组仍保留在堆上——它不会自动收缩，也不会被 gc 回收，因为 hmap 本身还持有对该数组的引用。
这和 slice 不同：slice 置为 nil 后底层数组若无其他引用，GC 可立即回收；而 map 即使清空所有键，只要变量还活着，buckets 就一直占着内存。
值类型 vs 引用类型：删除后子元素内存是否释放？
注意区分两层内存：
-
delete()操作本身不释放buckets内存（无论 value 是什么类型） - 但 value 是引用类型（如
*T、[]byte、map[K]V）时，该 value 所指向的堆内存，会在delete()后引用计数减一；若计数归零，下次 GC 会回收那部分内存 - value 是值类型（如
int、[128]byte、struct{}）时，其数据直接存于 bucket 内，delete()后只清空 slot，不触发任何子内存回收
所以你看到 runtime.MemStats().Alloc 下降一点，往往只是 value 本身是引用类型带来的间接释放，不是 map 结构体在“瘦身”。
为什么 runtime.GC() 之后内存还是很高？
手动调用 runtime.GC() 只能回收「已不可达」的对象，而 map 变量本身仍存活（比如是局部变量但还没出作用域，或是全局变量），它的 buckets 就不算“不可达”。常见误区包括：
- 误以为
delete()+runtime.GC()就等于“彻底清空” - 用
pprof看heap.sys或 RSS 判断泄漏——其实应盯heap.alloc；如果它稳定在低位，说明没泄漏，只是 runtime 暂未把空闲页还给 OS - 在循环中反复
delete后不重置 map，导致buckets越积越多（尤其高负载缓存场景）
真正释放 buckets 的唯一可靠方式：让 map 变量本身失去引用，例如赋值为 nil，或让它自然离开作用域。
高频增删场景下怎么避免内存持续增长
如果你的业务需要频繁清空/重建 map（比如请求级缓存、批处理中间状态），别依赖 delete() 清场。更稳妥的做法：
- 每次新请求都用
m := make(map[K]V)创建新 map，旧 map 自动成为 GC 候选 - 若必须复用，清空后显式赋
m = nil（注意：不是delete()后立刻nil，而是确认不再使用该变量） - 避免长期持有大 map 的全局变量；如需缓存，加 TTL + 定期重建，或改用
sync.Map（但注意它也不缩容） - 极端情况可考虑用指针包装：声明
var m *map[K]V，需要时*m = make(map[K]V)，清空即m = nil，加速 GC
底层 buckets 不缩容是 Go 的明确设计选择——换来的是一致的 O(1) 均摊插入性能。你要做的不是对抗它，而是适配它：把 map 当成“一次性的”资源来管理，而不是反复擦写的黑板。
