std::list迭代器可用作缓存键，因其在splice等操作中不失效；线程安全需用shared_mutex分读写锁，splice参数易错在“插到pos前”而非“pos处”，不用shared_ptr因破坏splice且增开销。
为什么不能直接用 std::list 的迭代器做缓存键？
很多人一上来就想着把 std::pair 往 std::list 里塞，再用 unordered_map 做索引——这思路对，但有个致命陷阱：std::list 的迭代器在插入/擦除时**只有指向被操作节点的迭代器会失效**，其余有效。可一旦你调用 list::splice 把某个节点移到头部（LRU更新），它不改变节点本身，只改指针，所以 unordered_map 里存的 iterator 依然有效。这点很关键，别被网上某些过时资料误导说“list 迭代器容易失效就不能用”。
如何用 std::list + std::unordered_map 实现线程安全？
核心是保护两个数据结构的并发访问，但**不能粗暴地给整个 get/set 加一把大锁**，否则吞吐量崩盘。更合理的做法是：读写 unordered_map 和移动 list 节点都必须原子，且顺序不能乱。推荐用 std::shared_mutex（C++17）或 std::mutex 配合 std::lock_guard，具体看场景：
- 如果读远多于写（典型缓存场景），优先用
std::shared_mutex，get()用std::shared_lock，put()用std::unique_lock - 若需兼容 C++11，老实用
std::mutex，但注意：list::splice不分配内存，是常数时间，锁粒度可以控制得比较细 - 切忌在锁内做耗时操作，比如深拷贝 value、调用用户回调——这些必须在释放锁之后做
class ThreadSafeLRUCache {
using Key = std::string;
using Value = std::string;
struct Node {
Key key;
Value value;
Node(const Key& k, const Value& v) : key(k), value(v) {}
};
mutable std::shared_mutex mtx;
std::list items;
std::unordered_map::iterator> cache;
size_t capacity;
public:
ThreadSafeLRUCache(size_t cap) : capacity(cap) {}
Value get(const Key& key) {
std::shared_lock lock(mtx);
auto it = cache.find(key);
if (it == cache.end()) return {};
// 提升到头部：先 splice 到 begin()，再取值
items.splice(items.begin(), items, it->second);
return it->second->value;
}
void put(const Key& key, const Value& value) {
std::unique_lock lock(mtx);
auto it = cache.find(key);
if (it != cache.end()) {
// 已存在：更新 value 并提升
it->second->value = value;
items.splice(items.begin(), items, it->second);
} else {
// 新增：插入头部
items.emplace_front(key, value);
cache[key] = items.begin();
// 检查容量
if (cache.size() > capacity) {
auto last = std::prev(items.end());
cache.erase(last->key);
items.pop_back();
}
}
}
};
std::list::splice 的参数顺序为什么容易出错？
这是实际编码中最常翻车的地方：list::splice(iterator pos, list& other, iterator it) 表示“把 other 中 it 指向的节点，移动到本 list 的 pos 之前”。不是“插入到 pos 位置”，而是“插在 pos 前面”。所以想把节点提到最前面，必须写 items.splice(items.begin(), items, it)，而不是 items.splice(items.begin(), items, it, std::next(it))（后者是区间 splice，没必要还易错）。另外，it 必须来自同一个 list，跨 list 调用会 UB。
为什么不用 std::shared_ptr 替代裸节点？
有人想用智能指针避免拷贝，但会引入额外开销和复杂度：unordered_map 的 value 类型变成 std::shared_ptr 后，splice 就没法用了（它只支持移动节点，不支持移动指针对象）。而且 LRU 缓存中 value 通常不大，拷贝成本可控；若 value 确实很大（如 std::vector），应考虑 move 构造或 PIMPL，而不是盲目上 shared_ptr。真正该警惕的是：别在 get() 返回时隐式拷贝 value——函数返回类型要是 Value（值语义），不是 const Value&，否则锁一释放引用就悬空。
立即学习“C++免费学习笔记（深入）”；
实际用的时候，capacity 初始化后不可变、key 的 hash 和相等比较要稳定、value 类型得支持移动构造——这些细节漏掉一个，运行时就可能 crash 或行为异常。 
