time.AfterFunc 不适合海量 key 过期清理，因其为每个 key 单独启动 goroutine 和定时器，10 万+ key 时内存与调度开销陡增，且无法统一取消或批量刷新；50 万 key 下 GC 压力翻倍，goroutine 数长期超 10 万。
为什么 time.AfterFunc 不适合海量 key 过期清理
它为每个 key 单独起一个 goroutine + 定时器，key 量级到 10 万+ 时，内存和调度开销会陡增，且无法统一取消或批量刷新。实际压测中，time.AfterFunc 在 50 万 key 场景下 GC 压力翻倍，goroutine 数长期卡在 10w+。
- 只适用于 key 总数
- 一旦 key 需要提前续期（如用户活跃重置过期时间），
time.AfterFunc无法安全 stop，只能 leak 原定时器 - 替代方案不是“不用定时器”，而是“共享定时器 + 分片延迟队列”
用 container/heap 实现最小堆驱动的延迟过期队列
核心思路：所有 key 按过期时间入堆，只启动一个 goroutine 持续 pop 已到期项并清理。避免 per-key 开销，且天然支持 O(log n) 插入/O(1) 查看最早过期时间。
- 堆元素必须包含
key、expireAt（Unix 时间戳）、version（防重复清理） - 每次
Set(key, value, ttl)时，先标记旧 key 为失效（写入map[key] = struct{valid bool; version uint64}），再 push 新节点 - 清理 goroutine 中需加锁读写共享 map，但仅对已过期的 key 做 delete，热点低
type Item struct {
key string
expireAt int64
version uint64
}
// Push/Pop 方法需实现 heap.Interface —— 注意：比较只看 expireAt
分片 sync.Map + 时间轮（Timing Wheel）降低锁争用
当单个 map 成为瓶颈（如高并发 Set/Get + 清理混杂），直接上 sync.RWMutex 会卡住读操作。分片 + 时间轮是更落地的选择：把 1 小时 TTL 拆成 60 个 bucket，每秒 tick 移动指针，只清理当前 bucket 的 key。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 时间轮大小建议设为 TTL 秒数的约数（如最大 TTL=3600s，轮子大小取 60 或 360），避免单 bucket 过载
- 每个 bucket 内部用
sync.Map存key → expireAt，清理时遍历 bucket 内所有 key 判断是否真过期（因可能被续期） - 注意：时间轮不保证精确到毫秒，适合 TTL ≥ 1s 的场景；若需 sub-second 精度，退回最小堆方案
runtime.SetFinalizer 不能用于过期控制
这是常见误解。Finalizer 触发时机不确定，GC 可能几小时不运行，且无法保证执行顺序，更无法主动触发。线上曾有服务误用它做 session 清理，导致内存泄漏数日不释放。
立即学习“go语言免费学习笔记（深入）”；
- Finalizer 只适合释放非内存资源（如文件句柄、socket），且必须配合显式 Close
- 任何依赖 Finalizer 实现业务逻辑（尤其是时效性逻辑）的代码，上线前应被拒
- Go 官方文档明确标注：
Finalizers are not guaranteed to run
真正难的不是选堆还是时间轮，而是如何让过期时间可观察、可调试——比如暴露 /debug/expired_keys?limit=100 接口查最近过期项，或者在清理时打点记录 expired_count 和 clean_duration_ms。没监控的过期逻辑，等于没逻辑。
