热路径缓存淘汰必须懒检查+批量驱逐+成本感知，因sync.Map无序不淘汰、lru.Cache锁瓶颈、ristretto成本定义易失真；三者均需避免阻塞读写、精准识别真实热点与资源成本。
热路径下缓存淘汰不能靠“查完再删”或“遍历全量 map”，必须让淘汰动作在常数时间内触发、批量执行、不阻塞读写——否则高并发一来，sync.Map 会内存暴涨，lru.Cache 会锁住链表头，ristretto 会因热度采样失真漏掉真实热点。
为什么热路径下 sync.Map 淘汰完全失效
sync.Map 不维护访问顺序，Range 返回 key 是伪随机的；你无法知道哪个 key 是“最久未用”或“访问频次最低”。热路径下大量 LoadOrStore 调用只会不断插入新 entry，旧项永远不被触达，len() 看似可控，实际内存只增不减。实测 QPS > 2k 时，几小时就 OOM。
- 它适合存开关、白名单这类写一次、读万次、从不淘汰的数据
- 只要涉及“滑动窗口”“最近 N 分钟”“按频次降序”，就必须换底座
- 别试图用
sync.Map+ 后台 goroutine 定期Range+Delete——Range过程中不允许Delete，否则 panic 或漏删
lru.Cache 在热路径下的锁瓶颈与绕过方式
lru.Cache 的 Get 和 Put 都要调 list.MoveToFront，而 list 是非线程安全的，所以官方实现用 sync.Mutex 包裹整个操作。热路径下多个 goroutine 同时 Get("config:global")，会排队争同一把锁，延迟毛刺明显。
- 不要迷信
RWMutex：哪怕只是MoveToFront，也是写操作，读锁不够用 - 分片是唯一可行解：比如按
key哈希到 16 个独立*lru.Cache实例，每实例配独立sync.Mutex - Set 时别传裸
[]byte：高频 key 下若 value 来自json.Marshal()，底层数组可能被复用，导致缓存内容错乱；优先用SetString(key, string(value))或显式拷贝append([]byte(nil), value...)
热路径真正需要的淘汰机制：懒检查 + 批量驱逐 + 成本感知
热路径不是“越快删越好”，而是“删得准、不卡主流程、不误伤热点”。关键不在淘汰逻辑多炫，而在三件事对齐：过期判断不进 hot path、驱逐不持有锁超过 100μs、淘汰依据不只是时间或频次，还得看真实成本（文件大小 / 内存占用 / 磁盘水位）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
Get里只做轻量判断：entry.expireAt.Before(time.Now())，过期立刻返回未命中，**不删 key，不碰链表** -
Put开头加水位检查：调unix.Statfs(cacheDir, &stat)算可用磁盘空间，低于阈值（如 512MB）则触发evictByLRU(30%)，且必须支持批量Remove，避免循环Back()+Remove持锁太久 - value 必须带成本字段：比如
type cacheItem { data []byte; size int64; modTime time.Time; accessCount uint64 }，淘汰时按size * (1.0 / max(1, accessCount))算“冷度”，比纯 LRU 更抗大文件霸占
ristretto 在热路径下的真实表现与陷阱
ristretto 的无锁读和 cost-aware 驱逐确实适合热路径，但它默认的 Cost 是 value 字节数，这对 JSON 响应体合理，对文件路径缓存却灾难性——一个 fileEntry{path:"/tmp/log.gz", size:100_000_000} 结构体本身才 64B，但真实成本是 100MB 磁盘空间。你设 MaxCost: 100 * 1024 * 1024，它根本不会驱逐这个 entry。
- 必须重写
Cost函数：返回item.size而非int64(unsafe.Sizeof(item)) -
OnEvict回调里拿不到原始 key：只能拿到value interface{}，若 value 不含路径字段，你就没法os.Remove文件 - 别开
Policy: ristretto.TinyLFU就以为万事大吉——它基于采样估算热度，冷启动期或突发流量下，真实热点可能还没被采样到，就被误判为冷数据
热路径缓存淘汰最难的不是算法，而是把“淘汰触发时机”“驱逐粒度”“成本定义”这三件事压进同一个原子操作里。任何一环脱节，比如在 Get 中删 key、用 sync.Map 存文件元信息、或把磁盘成本当成内存成本算，都会让系统在高负载下突然抖动甚至崩溃。
