不会。sync.Map 的 key 用指针不会导致内存无法回收；内存未释放主因是 value 持有堆对象强引用或 read 层旧 entry 长期驻留。
sync.Map 不会自动防止内存无限增长，长期运行必须主动干预——它不清理、不驱逐、不设 TTL，只负责并发安全。
sync.Map 的“僵尸 entry”到底有多顽固
Go 1.24 虽然加了惰性清理，但仅限于 Delete 后标记为删除的 entry 在读写间隙被顺手回收；而那些从未被 Delete、但 value 已无业务意义的键值对（比如过期 session、临时 trace ID），会永远卡在 dirty 或 read map 里。pprof 中表现为 runtime.mapassign 持续分配 + HeapInuse 单向上涨，且 Range 遍历越久越慢（因为要跳过大量已删 entry）。
- 旧版本（
- Go 1.24+：后台清理只触发在读写操作中，空闲时不会扫；Range 会跳过已删 entry，但遍历本身仍需遍历整个 shard 底层 map
- 所有版本共性：没有 GC 友好机制 —— value 是 interface{}，若存了大 struct 或闭包，引用链锁死整块内存
不靠定时器，怎么低成本清理过期数据
别用 time.Ticker 驱动全局清理（额外 goroutine + 锁竞争），改用「写时顺带清理」+ 「读时懒驱逐」组合策略：
- 每次
Store前，检查 key 是否应淘汰（比如解析时间戳，if time.Since(ts) > 10*time.Minute { m.Delete(key) }） - 在
Load返回后立即判断 value 是否过期，过期则LoadAndDelete并返回 nil（避免后续重复加载） - 每 N 次写操作（如 1000 次）触发一次
Range扫描，只处理 timestamp 类型 key，delete掉超时项 —— 注意：Range 回调内绝不能调Store或Delete，要用切片暂存待删 key，回调外批量删
为什么不用 sync.RWMutex + map 替代
不是不能，而是权衡：如果你的 key 空间稳定（比如固定配置项、用户白名单）、写极少、读极多，sync.RWMutex + 预分配 map[string]*User 更可控、内存更干净、GC 更及时。但一旦 key 动态生成（HTTP 请求 ID、traceID、临时 token），就容易踩两个坑：
- 预分配容量失效：你无法预估 key 总数，
make(map[string]V, 65536)很快被撑爆，触发 runtime 扩容（此时全 map 锁住，阻塞所有读） - 手动清理成本高：每次删 key 都要
mu.Lock()，高频删除直接拖垮吞吐；而sync.Map.Delete是分 shard 加锁，粒度更细 - 真正该换方案的信号：pprof 显示
sync.(*Map).Store和sync.(*Map).Range占 CPU Top 3，且heap_allocs每分钟涨 50MB+ —— 这说明你不是在用缓存，是在堆内存里建了个垃圾场
Go 1.24 的 Swiss Tables 对 sync.Map 完全没影响
Swiss Tables 只改了原生 map 的底层哈希实现（control byte + 二次探测），sync.Map 的分片 + 只读快照 + dirty map 三层结构完全没动。它既不提升 sync.Map 的查找速度，也不解决其内存滞留问题。网上所谓「1.24 后 sync.Map 自动变快/自动 GC」全是误读。
真正关键的控制点始终只有一个：你是否清楚每个 key 的生命周期，并在它该消失的时候亲手调用 Delete —— sync.Map 不会替你做决定，也不会替你善后。
