LRU缓存应采用std::list+std::unordered_map组合，支持O(1)查找与更新、迭代器稳定；需按字节限制容量、校验文件修改时间、线程安全用shared_mutex保护。
LRU缓存的核心结构选 std::list + std::unordered_map
直接用 std::list 存文件路径和内容（或元数据），再用 std::unordered_map 映射路径到 std::list 的迭代器，是 C++ 里最可控、最易维护的 LRU 实现方式。不用第三方库，不依赖 std::map 的排序开销，也不用自己手写双向链表。
关键点在于：每次 get() 或 put() 都要把对应节点移到链表头部（最新访问），而淘汰时只删尾部节点。迭代器在 std::list 中不会因插入/删除失效，这正是它比 std::vector 或 std::deque 更适合此处的原因。
-
std::list<std::pair<std::string, std::string>>存{"path", "content"}，头部为最新访问 -
std::unordered_map<std::string, std::list<...>::iterator>提供 O(1) 查找 - 避免用
std::shared_ptr包裹值——除非你真需要跨线程共享内容，否则堆分配+引用计数反而拖慢 IO 密集场景
文件读取与缓存更新必须区分“存在但过期”和“根本不存在”
LRU 缓存不能只看路径是否在 map 里，还要检查对应文件是否被外部修改过。否则会出现“缓存击穿+脏读”：程序以为自己有最新内容，实际磁盘上文件早已更新。
推荐在缓存项中额外存一个 std::filesystem::file_time_type（C++17 起支持），每次 get() 前用 std::filesystem::last_write_time(path) 对比。不一致就丢弃旧缓存、重新读取并更新时间戳。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 不要把
stat结果全缓存——只要last_write_time就够判断新鲜度 - 若目标文件可能被硬链接或符号链接绕过，需统一用
std::filesystem::canonical(path)归一化路径再进缓存 - Windows 上注意
last_write_time精度是 100ns，Linux ext4 默认是秒级，跨平台部署时别依赖毫秒级变更检测
缓存大小限制要按字节算，不是按文件个数
文件大小差异极大：一个配置文件几 KB，一个日志切片可能上百 MB。只限制条目数（如 “最多 100 个文件”）会导致内存失控。必须跟踪总占用字节数，并在 put() 时动态驱逐。
做法是在每个缓存项中加一个 size_t size_bytes 字段，在插入前先加，插入后检查总量；超限时从尾部逐个删除，直到满足阈值。注意：删除动作本身也要减去对应 size_bytes，否则下次判断会失准。
- 用
std::filesystem::file_size(path)获取原始大小，别用缓存中字符串长度——文本文件换行符在不同平台长度不同，且二进制文件根本不适用 - 如果缓存的是压缩后的内容（如 gzip），则应记压缩后体积，而不是源文件大小
- 避免在每次
get()时都调用file_size()——它可能触发系统调用，只在put()和驱逐逻辑里用
多线程访问必须保护整个 LRU 操作原子性
单个 std::unordered_map 或 std::list 都不支持并发读写。哪怕只是“查 map → 取迭代器 → 移动 list 节点”，中间任何一步被其他线程打断，都可能造成迭代器失效或链表断裂。
最稳妥的方式是用一个 mutable std::shared_mutex（C++17）：读操作用 shared_lock，写操作（get 命中后的提升、put、驱逐）用 unique_lock。不要拆成多个锁——比如给 map 和 list 各一把锁，会引入死锁和状态不一致风险。
- 别用
std::mutex全局锁——它会让所有get()串行，严重拖慢高并发读场景 - 如果确定只有单线程使用（如 CLI 工具内部），可以完全去掉锁，但要在类注释里明确写
// Not thread-safe -
std::shared_mutex在 macOS 上部分老版本 libc++ 不支持，若需兼容，降级为std::mutex并接受性能损失
真正难的不是实现 LRU 结构，而是决定什么时候该跳过缓存——比如正在被另一个进程写入的文件，last_write_time 还没更新，但内容已半截。这种 case 得靠应用层约定（如临时文件加 .tmp 后缀）或 flock 检测，LRU 本身无能为力。
