不能只用一把 std::mutex 锁住整个 get() 和 put()，否则吞吐量断崖式下降；应使用 std::shared_mutex 区分读写：get() 用 shared_lock 并发，put() 用 unique_lock 排他，并注意 splice() 参数顺序、淘汰顺序、智能指针优化及迭代器有效性。
为什么不能只用一把 std::mutex 锁住整个 get() 和 put()
吞吐量会断崖式下降——所有读请求（get()）和写请求（put()）串行排队，哪怕并发读多于写，也完全无法利用多核。真实业务中，读占比常超 90%，锁粒度太粗直接让缓存变成瓶颈。
正确做法是区分读写场景：get() 只需查 map + 移动链表节点，全程可并发；put() 涉及插入、淘汰、更新，必须排他。C++17 的 std::shared_mutex 正为此设计：
-
std::shared_lock<:shared_mutex></:shared_mutex>用于get()：多个线程可同时持有共享锁 -
std::unique_lock<:shared_mutex></:shared_mutex>用于put()：写操作独占，自动阻塞其他读写
注意：不要在 get() 中提前释放锁再调用 splice() —— splice() 需要访问链表和 map，必须在锁内完成，否则竞态下迭代器可能已被其他线程 erase。
std::list::splice() 参数顺序为什么总写错
常见错误是写成 cache_list_.splice(cache_list_.begin(), it->second)，这会触发编译失败或运行时崩溃。因为 splice() 的三参数重载签名是：splice(pos, list, it)，含义是「把 it 指向的节点，插入到 pos 之前」，不是「插入到 pos 位置」。
立即学习“C++免费学习笔记（深入）”；
所以要把节点移到头部，必须写成：
cache_list_.splice(cache_list_.begin(), cache_list_, it->second);
漏掉第二个参数 cache_list_，编译器会匹配到单链表版本（forward_list），而 std::list 不支持；写成 cache_list_.splice(cache_list_.begin(), it->second) 则匹配错误重载，行为未定义。
另外：it->second 是 std::list::iterator，不是指针，不能解引用后传 —— splice() 要的就是迭代器本身。
淘汰尾部节点时，为什么必须先删 unordered_map 再删 list
顺序反了就会留下悬空迭代器：如果先 cache_list_.pop_back()，被删节点的迭代器立即失效，但 cache_map_[key] 还指着它；下次 get(key) 解引用这个迭代器，就是未定义行为（UB），轻则返回垃圾值，重则段错误。
标准做法是：
- 取尾部节点：
auto last = cache_list_.back() - 从 map 中擦除：
cache_map_.erase(last.first) - 再从 list 中移除：
cache_list_.pop_back()
这个顺序保证 map 里永远不存指向已销毁节点的迭代器。同理，在 put() 更新已有 key 时，也不能直接赋值 cache_map_[key] = cache_list_.begin() —— 这会触发 unordered_map::operator[] 默认构造旧值再赋值，异常风险高；应改用 cache_map_.insert_or_assign(key, cache_list_.begin())（C++17）。
Value 类型大时，怎么避免拷贝放大开销
如果 V 是 std::string 或自定义大对象，emplace_front(key, value) 会触发一次拷贝（或移动），而 splice() 移动节点时又涉及一次移动 —— 累计开销不可忽视。
更优解是存储智能指针：
- 用
std::list<:pair std::unique_ptr>>></:pair>替代std::list<:pair v>></:pair> - map 存迭代器仍不变：
std::unordered_map<k std::list>::iterator></k> -
put()时直接构造std::make_unique<v>(std::move(value))</v>，零拷贝入链表
注意：别用 std::shared_ptr —— 引用计数原子操作有额外开销，且破坏 splice() 的 O(1) 保证（需更新控制块）；std::unique_ptr 移动无开销，且与 list 完全兼容。
最易被忽略的是迭代器有效性边界：只要没调用 erase() 或 clear()，std::list 迭代器就一直有效；但一旦发生淘汰或清空，所有对应 map 中的迭代器必须同步清除——这点没有编译器检查，全靠逻辑严谨性兜底。
