不能用FIFO实现带过期淘汰的本地内存缓存，因其不感知时间，强行加入TTL会破坏语义、引发并发错乱，且Go生态缺乏成熟封装；应改用ristretto（容量驱动FIFO-like）或lru.Cache（懒检查过期）。
不能用 FIFO 实现带过期淘汰的本地内存缓存 —— FIFO 本身不感知时间，强行塞入 TTL 逻辑会破坏 FIFO 语义、引发并发错乱，且 Go 生态没有成熟封装。
为什么 FIFO 缓存 + 过期 = 自找麻烦
FIFO 的核心是“先进先出”，它只依赖插入顺序，不记录访问时间、不支持按时间筛选。你想在 FIFO 里加过期，就得额外维护一套时间索引（比如 map[key]time.Time），再让清理逻辑去交叉比对；但 FIFO 的驱逐触发点是容量满，不是时间到，这就导致：过期项可能永远不被删（哪怕已过期 1 小时），而未过期的新项却因容量满被误删。实测中，这种混合方案在 QPS > 500 时就出现漏删、重复删、panic: concurrent map read and map write。
-
container/list+map手写 FIFO 时，list.Remove()和map.delete()非原子，必须加锁；但锁粒度稍大就会卡住读请求 - 过期检查若放在 Get 路径，FIFO 结构无法快速定位“哪个节点过期了”，只能遍历整个 list，O(n) 开销不可接受
- 后台 goroutine 定时扫描，又得同步 list 和 map 状态，极易因
list.Next()返回 nil 或迭代中途被Remove()中断而 panic
真要 FIFO 语义，就别碰过期 —— 改用 ristretto + 自定义 Cost
如果你业务确实需要“按写入顺序淘汰”，比如日志缓冲、消息队列本地暂存、固定窗口聚合，那就放弃“过期”这个概念，改用容量驱动的 FIFO-like 行为：用 ristretto 设置极低的 MaxCost，并让每个 item 的 cost = 1（即按数量计数），再关闭 TTL：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 初始化时设
ristretto.Config{MaxCost: 1000, NumCounters: 1e6, Policy: false}——Policy: false关闭后台清理，驱逐完全由 cost 触发 -
Set时不传ristretto.TTL，避免引入时间判断开销 - 每个 key 的 value 封装为结构体，
cost回调返回 1：func(interface{}, interface{}) int64 { return 1 } - 这样当缓存超 1000 项时，ristretto 按采样+cost 淘汰，效果近似 FIFO（因新项总在采样窗口末端），且无时间字段、无 GC 压力
真要过期 + 淘汰，直接换 lru.Cache + 懒检查
99% 的所谓“FIFO + 过期”需求，实际只是想控制缓存生命周期 + 防止内存无限增长。这时 lru.Cache 是更稳的选择 —— 它天然支持并发读写、无全局锁、可配大小，配合懒检查过期，代码少、行为可预测：
立即学习“go语言免费学习笔记（深入）”；
- 定义 value 类型：
type cacheItem struct { value interface{}; expireAt time.Time } -
Set时存完整cacheItem，不触发任何清理 -
Get时先取值，立刻if !item.expireAt.After(time.Now()) { c.Delete(key); return nil, false } - 绝不自动在
Get里删完再 return，防止并发 Get 同时触发 Delete 导致日志刷屏 - 启动一个单独 goroutine，每 30 秒调一次
c.Purge()清空全量（仅当缓存项极少更新时才需）
真正容易被忽略的是：FIFO 和过期在语义上根本冲突。你要的是“时间可控”，那就接受 LRU 的访问局部性假设；你要的是“顺序确定”，那就接受无过期。硬拧在一起，最后 debug 的时间远超选库成本。
