多级缓存不能直接用裸指针链式管理，因其不携带所有权信息，易导致悬空指针、重复释放和生命周期错位；应使用shared_ptr明确所有权（如L1→L2），weak_ptr打破循环引用（如L2→L1），并配合自定义删除器适配非堆内存。
多级缓存为什么不能直接用裸指针链式管理
裸指针（CacheLevel*）串联多级缓存看似直观，但实际极易引发悬空、重复释放和生命周期错位。比如 L1 缓存析构时，若未显式通知 L2 释放对它的引用，L2 中残留的 next_level 指针就变成野指针；又或者多个缓存层共用同一块内存但各自调用 delete，触发 double-free。
真正可行的做法是：用智能指针明确所有权归属，并配合弱引用打破循环依赖。
- L1 → L2 用
std::shared_ptr<cachelevel></cachelevel>：表示“我需要你活着” - L2 → L1 用
std::weak_ptr<cachelevel></cachelevel>：仅用于临时访问，不延长生命周期 - 所有缓存层对象由上层统一 new，下层只持弱引用或观察者语义
如何设计支持指针跳转的缓存层级结构
关键不是“怎么存指针”，而是“谁负责创建、谁负责释放、谁允许访问”。一个典型结构如下：
struct CacheLevel {
std::string name;
size_t capacity;
std::shared_ptr<CacheLevel> next; // 下一级（如 L1 → L2）
std::weak_ptr<CacheLevel> prev; // 上一级（如 L2 → L1），避免循环引用
std::unordered_map<std::string, std::any> data;
<pre class='brush:php;toolbar:false;'>bool get(const std::string& key, std::any& out) {
auto it = data.find(key);
if (it != data.end()) {
out = it->second;
return true;
}
// 未命中：委托给下一级，但先检查 next 是否还有效
if (auto next_ptr = next.lock()) {
return next_ptr->get(key, out);
}
return false;
}};
立即学习“C++免费学习笔记（深入）”；
注意：next.lock() 是安全访问 shared_ptr 的必要步骤；prev 不参与 get 流程，仅用于某些管理场景（如 L2 主动刷新 L1）。
使用 raw pointer 触发崩溃的典型场景
以下代码在多线程或提前析构时大概率 crash：
struct BadCache {
CacheLevel* next; // 裸指针
~BadCache() { delete next; } // 错误：不知道 next 是否由自己 new 出来
};
// 多处赋值：
BadCache l1, l2;
l1.next = &l2; // 取地址 → l2 析构后 l1.next 悬空
l2.next = new CacheLevel; // new 出来 → l2 析构时 delete，但 l1 可能还在用
错误根源在于：裸指针不携带所有权信息，编译器无法判断该不该 delete，运行时也无法验证有效性。
- 禁止用
&obj赋值给跨层指针，除非 obj 生命周期严格长于所有使用者 - 禁止混合使用
new和栈对象地址赋值到同一指针字段 -
delete前必须确认该指针是本层new出来的，且无其他层持有副本
std::shared_ptr + 自定义删除器适配非堆内存
如果某级缓存数据区是 mmap 映射或静态 buffer（比如嵌入式场景），不能用默认 delete，需定制删除逻辑：
auto deleter = [](char* p) {
if (p && is_mmaped(p)) {
munmap(p, SIZE);
} else if (p) {
delete[] p;
}
};
std::shared_ptr<char> cache_buf{static_cast<char*>(mmap(...)), deleter};
这样 cache_buf 在超出作用域时会自动调用 munmap，而不是崩溃在 delete[] 上。
多级缓存中最容易被忽略的是：每级的内存来源是否一致、释放方式是否可组合。混用 malloc/mmap/new 不加封装，哪怕指针跳转逻辑再完美，也会在某个析构时刻突然失败。
