不能直接用 std::vector<Metadata*> 因其导致堆碎片、指针失效、悬垂风险；应改用 std::unique_ptr+自定义分配器或 std::pmr 内存池，配合缓存友好的索引结构与 cache line 对齐。
为什么不能直接用 std::vector<Metadata*> 存指针
缓存元数据时，很多人第一反应是把 Metadata 对象 new 出来，再用 std::vector<Metadata*> 管理——这在小规模下看似可行，但大规模时会触发两个硬伤：new 频繁调用导致堆碎片加剧，vector 扩容时指针批量失效（原内存块被移动，而指针仍指向旧地址）。更隐蔽的问题是：元数据生命周期和缓存策略（如 LRU）脱钩，容易出现悬垂指针或提前释放。
用 std::unique_ptr + 自定义分配器控制内存布局
核心是把“分配”和“管理”解耦：用一块连续大内存（如 mmap 或 std::aligned_alloc）承载所有 Metadata 实例，再用 std::unique_ptr<Metadata, Deleter> 封装访问逻辑，让智能指针的析构只做逻辑标记，不真正 free。示例关键点：
-
Deleter是个空操作函数对象，或仅将该 slot 标记为“可回收” -
std::vector<std::unique_ptr<Metadata>>存的是智能指针，但底层对象都在预分配池中 - 避免
std::shared_ptr—— 引用计数原子操作在高并发缓存淘汰路径上是明显瓶颈
用 std::pmr::polymorphic_allocator 统一管理元数据池
C++17 的 std::pmr 是更干净的解法：先用 std::pmr::monotonic_buffer_resource 或 std::pmr::synchronized_pool_resource 构建专用内存池，再让所有 Metadata 对象通过 std::pmr::vector<Metadata> 或 std::pmr::unordered_map 分配。好处是：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 内存池可复用（比如每轮缓存重建时
pool.release()一次性归还全部内存） - 无需手动写
Deleter，pmr::vector析构时自动调用池的 deallocate - 注意：若元数据需跨线程共享，优先选
synchronized_pool_resource，但它的锁开销比monotonic_buffer_resource高
缓存索引结构必须与元数据物理位置对齐
如果用哈希表做 key→metadata 查找，但 Metadata 实例分散在堆各处，CPU cache line 命中率会暴跌。真实高性能场景下，应让索引结构本身也驻留在同一内存池，并采用开放寻址哈希（如 robin_hood::unordered_flat_map），确保 key 和对应 Metadata 在内存中相邻。否则即使用了池分配，L1 cache miss 仍可能吃掉 30%+ 性能。
立即学习“C++免费学习笔记（深入）”；
最容易被忽略的一点：元数据结构体自身要手动对齐（alignas(64)）并填充到 cache line 边界，否则多个元数据挤在同一个 cache line 里，伪共享（false sharing）会让多核更新性能断崖下跌。
