直接用 std::unordered_map + 后台线程定时清理会导致迭代器失效、数据竞争、清理延迟不可控；ttl 需时间戳但 map 不存元信息，必须封装结构；读需实时判断过期，不能依赖后台扫描；std::chrono::steady_clock::now() 是唯一可靠时基。
用 std::unordered_map + 定时清理会出什么问题？
直接往 std::unordered_map 里塞键值对再配个后台线程遍历删过期项，看似简单，实际在高并发读写下极易出错：迭代器失效、数据竞争、清理延迟不可控。更麻烦的是，TTL 判断必须依赖写入时间戳，但 std::unordered_map 不存元信息，得自己包一层结构——这已经不是“加个 map”能解决的事了。
- 每次读都要检查
expire_time字段，不能靠后台单次扫描代替实时判断 - 写操作需原子更新时间戳，
std::chrono::steady_clock::now()是唯一可靠时基（不用system_clock，它可能被系统调时拖垮 TTL） - 后台清理线程若只做“尽力而为”的扫描，必须接受“过期项仍可能被读到”的事实——这是 TTL 缓存的正常行为，不是 bug
LRU + TTL 混合策略怎么避免双重开销？
纯 LRU 不管时间，纯 TTL 不管容量，两者叠加容易让每次 get() 都要查时间戳+挪链表位置，性能雪崩。关键在分离关注点：TTL 控制“是否可读”，LRU 控制“要不要淘汰”，且淘汰动作只发生在写入或显式清理时，不污染读路径。
- 读操作只做两件事：查
expire_time > now()，命中则把节点移到 LRU 表头（无锁前提下可用std::shared_mutex读锁保护） - 写操作才触发完整流程：插入/更新值 + 时间戳 + LRU 位置；若缓存满，按 LRU 链尾开始逐个检查 TTL，跳过未过期项，直到腾出空间
- 别用
std::list配unordered_map存迭代器——迭代器失效风险高；改用带索引的双向链表节点（如自定义CacheNode结构体，含前后指针和key副本）
多线程下 std::shared_mutex 和 std::mutex 怎么选？
读多写少是本地缓存典型场景，std::shared_mutex 能显著提升并发读吞吐，但它在部分旧版 libstdc++（如 GCC 8 之前）不支持，Windows 上 VS2015 起才有。一旦目标环境不确定，宁可统一用 std::mutex，别为理论性能引入兼容性雷。
- 用
std::shared_mutex时，get()用lock_shared()，set()和清理用lock()；注意它不支持递归，重复lock_shared()会导致死锁 - 如果选用
std::mutex，别在get()里做耗时操作（比如日志、网络回调），否则所有读被串行化 - 清理线程的锁粒度要细：不要整个缓存加锁再遍历，而是对每个待检查节点单独加锁（或用无锁队列暂存待删 key，由工作线程异步处理）
为什么 std::chrono::milliseconds 比 time_t 更适合 TTL 存储？
time_t 是秒级整数，精度不够，且依赖系统时钟；而 TTL 往往是毫秒甚至微秒级（比如 300ms 的 API 响应缓存），用 time_t 存会导致大量“刚过期就命中”或“提前失效”。std::chrono::steady_clock::time_point 是唯一正解——它不随系统时间调整跳变，差值计算稳定。
立即学习“C++免费学习笔记（深入）”；
- 存储时用
steady_clock::now() + std::chrono::milliseconds(ttl_ms)，不是system_clock::now() - 比较时直接用
if (expire_time ，别转成 long 再算，避免溢出和精度丢失 - 如果接口必须接收
int ttl_seconds，立刻转成std::chrono::seconds再累加，别在内部用time(nullptr)算绝对时间
真正难的从来不是“怎么存过期时间”，而是当多个线程同时触发写入、读取、后台清理时，如何让 expire_time 的更新、检查、删除三者不互相干扰。很多实现卡在“测试单线程全过，一压测就丢数据”——那大概率是时间戳更新没和主数据写入绑在同一个原子操作里。
