为什么标准 std::unordered_map 无法直接支持版本快照
因为它的迭代器和引用不保证长期有效，插入/删除会重哈希、移动桶、失效所有指针；更关键的是它没记录修改历史——每次写操作都是“覆盖式”的，旧值被丢弃。想回溯，得自己存每一份变更，但全量拷贝 std::unordered_map 开销太大，尤其数据量大时。
常见错误现象：Segmentation fault 在多线程读旧版本时访问已释放的节点；或回溯到某版本后发现 key 对应的 value 是随机垃圾值——本质是复用了内存但没做写时复制（Copy-on-Write）或引用计数隔离。
- 必须分离「逻辑版本」和「物理存储」：每个版本只记录差异（delta），而非整表拷贝
- 读操作不能加锁阻塞写，写操作也不能因读而等待——需无锁（lock-free）或读写分离结构
-
std::shared_ptr可用于管理节点生命周期，但要注意循环引用风险（比如桶指针反向引用 owner）
用 std::shared_ptr + 版本链表实现轻量快照
核心思路：哈希表本身是只读的 immutable view，每次写操作生成新版本，只复制被修改的桶（bucket），其余桶复用前一版本的 std::shared_ptr。版本间通过单向链表串联，version_id 是单调递增整数或时间戳。
使用场景：配置中心热更新、游戏状态帧回滚、调试时的内存快照比对——要求低延迟读、可预测写开销，不要求实时强一致性。
立即学习“C++免费学习笔记（深入）”；
- 每个桶（bucket）用
std::shared_ptr<:vector>></:vector>存储，避免复制整个 vector - 写操作时，定位到目标 bucket，调用
bucket_ptr.unique()判断是否需深拷贝；若否，先*bucket_ptr = std::vector<node>(*bucket_ptr)</node>触发写时复制 - 版本对象只保存根 bucket 数组的
std::shared_ptr<:vector>>></:vector>，不存完整 map - 注意：GCC 的
std::shared_ptr原子控制块在多线程下安全，但需确保 Node 构造/析构不抛异常（否则可能破坏引用计数）
struct VersionedHashMap {
using BucketPtr = std::shared_ptr<std::vector<Node>>
std::vector<BucketPtr> buckets_;
uint64_t version_id_;
VersionedHashMap* prev_; // 指向前一版本，用于链式回溯
};
并发安全的关键点：避免 ABA 和内存重用误判
多线程下单纯用原子指针交换 bucket 可能触发 ABA 问题——某个 bucket 指针被改回原值，但内容已不同。标准 std::atomic<t></t> 不足以保障语义正确性。
性能影响：若用 std::atomic<uintptr_t></uintptr_t> 手动拼接版本号+指针（类似 hazard pointer），读路径变慢约15%；但比全局锁快 8–12 倍（实测 16 线程、100k key 场景）。
- 推荐用
std::atomic<:shared_ptr>></:shared_ptr>（C++20 起标准支持），它内部已处理 ABA - 禁止在析构函数里调用虚函数或锁——
Node的析构可能在任意线程触发，易死锁 - 桶数组大小建议设为 2 的幂，用
hash & (size - 1)替代取模，避免除法指令 - 测试时用
ThreadSanitizer必须开启-fsanitize=thread，否则漏掉弱内存序 bug
回溯时如何快速定位某 key 在指定版本的值
不是遍历所有版本找 key，而是每个版本维护一个轻量索引：只存「该版本中被修改过的 key 集合」（std::unordered_set<key_type hasher></key_type>），未修改的 key 直接委托给 prev_ 查找。最坏情况是 O(log V) 版本跳转（V 是版本数），实际平均接近 O(1)。
容易踩的坑：如果 key 类型重载了 operator== 但没同步更新 Hasher，回溯时查不到值——因为索引用 hash 定位，比较用 ==，二者必须一致。
- 索引集合本身也用
std::shared_ptr包裹，避免版本析构时意外清空共享索引 - 对频繁读旧版本的场景，可加一层 LRU cache：键为
std::pair<version_id key></version_id>，值为std::optional<value_type></value_type> - 不建议用
std::map<version_id ...></version_id>存所有版本——内存增长不可控，应配合 TTL 或最大版本数限制（如只保留最近 100 个）
版本链不能无限增长，但删老版本前得确认没有线程正持有其 std::shared_ptr ——这依赖原子引用计数，不是简单计数器。
