真正难防的内存泄漏是对象该销毁却因shared_ptr持有、回调未注销或线程未退出而“假存活”；应优先用unique_ptr管理独占资源，weak_ptr打破循环引用，容器存值或unique_ptr而非裸指针，并确保回调注册后显式解注册。
真正难防的内存泄漏，不是 new 后漏掉 delete，而是对象明明该死了却一直活着——比如被某个 shared_ptr 悄悄拽着、被回调列表长期持有、或卡在没退出的线程里。
用 unique_ptr 替代裸指针管理单个对象
绝大多数局部动态对象，根本不需要共享所有权。用 unique_ptr 能让释放时机完全确定：离开作用域就自动调用 delete，连异常路径都覆盖了。
常见错误：
- 手写
new+delete配对，但函数有多个return或可能抛异常 - 误用
shared_ptr管理本该独占的对象，增加引用计数开销且掩盖生命周期问题
正确做法：
立即学习“C++免费学习笔记（深入）”；
void process() {
auto ptr = std::make_unique<MyClass>(); // 构造即接管
if (some_error) return; // 不用手动 delete，安全
ptr->do_work();
} // 自动析构，自动 delete
用 weak_ptr 打断 shared_ptr 循环引用
shared_ptr 本身不导致泄漏，但两个对象互相用 shared_ptr 持有对方时，引用计数永远不为 0，析构函数永远不会执行——这是工程中最隐蔽的“假存活”泄漏。
典型场景：
- 树/图结构中父子双向引用（如
Node::parent和Node::children） - 观察者模式里，被观察对象持有了观察者的
shared_ptr
关键动作：
- 把“非拥有关系”的那一端（通常是反向引用）换成
weak_ptr - 使用前必须调用
lock()获取临时shared_ptr，检查是否还有效
示例：
struct Node {
std::shared_ptr<Node> next;
std::weak_ptr<Node> prev; // 不再增加引用计数
};
auto a = std::make_shared<Node>();
auto b = std::make_shared<Node>();
a->next = b;
b->prev = a; // a 不会因 b 持有而延长生命周期
容器里别存裸指针，改用智能指针或值语义
std::vector<MyClass*> 是高危模式：调用 clear() 只清指针，不删对象；迭代器失效、异常中断、忘记遍历 delete 都会直接泄漏。
更安全的选择：
- 存值：
std::vector<MyClass>—— 对象随容器构造/析构，零手动管理 - 存
unique_ptr：std::vector<std::unique_ptr<MyClass>>—— 明确所有权，clear()即释放全部 - 避免
std::vector<std::shared_ptr<MyClass>>，除非真需要共享所有权
特别注意：vector::clear() 不等于释放堆内存——它只销毁元素，对裸指针无效；对 unique_ptr 元素才触发实际 delete。
注册回调后必须提供显式解注册机制
很多泄漏源于“注册容易，注销难”：对象 A 向全局事件中心注册了成员函数回调，但 A 销毁时忘了告诉中心“别再调我了”。结果中心一直持有 A 的 shared_ptr 或 this 指针，A 永远无法析构。
实操要点：
- 所有注册接口必须配套提供
unregister()或返回可销毁的handle - 在对象析构函数里强制解注册（哪怕只是加个日志确认）
- 避免在 lambda 中无脑捕获
shared_from_this()，尤其在异步任务里——任务未完成前对象就被销毁，会导致崩溃或悬挂
容易被忽略的一点：单例、全局缓存、线程局部存储（TLS）这些地方持有的对象，退出时若没有明确的 shutdown() 流程，也会变成“僵尸内存”。它们不会报错，但 RSS 会持续上涨。
