不会。sync.Map 的 key 用指针不会导致内存无法回收，删除仅移除对 key 的引用，不影响其指向对象生命周期；内存未释放主因是 value 持有堆对象强引用或 read 层旧 entry 长期驻留。
sync.Map 的 key 用指针会导致内存无法回收？
不会。key 本身是值类型（哪怕是指针），sync.map 删除时只移除对它的引用，不控制其指向对象的生命周期；真正影响内存释放的是 value 是否持有对堆对象的强引用。问题常被误判为 “key 是指针所以删不掉”，实际是 value 里存了未释放的 slice/map/struct 字段，或 key 指针所指向的对象被其他地方长期持有。
为什么 Delete() 后 pprof 还看到大量内存？
因为 sync.Map 的底层设计分 read 和 dirty 两层：
-
read是原子读取的只读快照，删除操作只是把对应*entry的p字段置为nil，但该entry本身仍保留在read.map中，直到下次写入触发升级（misses 累积）才会被替换 -
dirty是可写的 map，Delete()会真实从dirty中移除键值对，这部分内存可被 GC 回收（前提是 value 不逃逸） - 如果你只读不写，
read层的旧entry会长期驻留，pprof显示的“存活对象”往往就来自这里
如何验证 key 指针是否真造成泄漏？
用最小可复现代码 + runtime.ReadMemStats 对比关键指标，重点看 HeapAlloc 而非 Sys：
- 构造一个全局
sync.Map，key 为*int，value 为[]byte（易观察） - 插入 10w 个项后调用
runtime.GC()，记录HeapAlloc - 遍历调用
Delete()，再调用runtime.GC()，对比HeapAlloc是否回落 - 若
HeapAlloc基本不变，说明 value 的[]byte已释放，残留的是read层的entry结构体和 key 指针本身（极小，几十 KB）；若没回落，问题在 value 或外部引用
示例关键片段：
var m sync.Map keys := make([]*int, 0, 100000) for i := 0; i <h3>真正该检查的三个地方</h3> <p>别盯着 key 类型，先确认以下三点：</p>
- value 是否包含未释放的
map、slice、chan或大 struct —— 它们内部持有的底层数组/哈希桶才是内存大户 - key 指针指向的对象是否被其他 map/slice/全局变量长期引用（比如缓存了指针但忘了清理原结构体）
- 是否误把
sync.Map当作长期存储容器，却没做 TTL 或 size 限制，导致dirty层持续膨胀，而read层又迟迟不刷新
最常被忽略的是：你删了 sync.Map 里的 key，但那个 key 指向的 struct 里有个 sync.Map 字段，它自己还在涨 —— 这种嵌套引用链必须手动断开。
