weak_ptr通过不增加引用计数并提供lock()原子操作来破除shared_ptr循环引用，需将循环中一端改为weak_ptr并在访问前lock()获取临时shared_ptr。
weak_ptr 怎么破掉 shared_ptr 的循环引用
shared_ptr 之间互相持有对方，引用计数永远不归零，对象就永远不会析构——这是最典型的循环引用死局。weak_ptr 不增加引用计数，只“观察” shared_ptr 管理的对象是否还活着，从而打破强持有链条。
关键不在“用不用”，而在“在哪用”：必须把循环中至少一端的 shared_ptr 换成 weak_ptr，且该端在访问对象前必须先调用 lock() 转成临时 shared_ptr。
- 错误写法：
weak_ptr直接解引用（*wp或wp->）会崩溃，因为没检查对象是否已销毁 - 正确流程：
auto sp = wp.lock(); if (sp) { /* 安全使用 sp */ } - 典型场景：父类持子类
shared_ptr，子类反过来只存父类的weak_ptr；观察者模式里被观察对象不反向强持有观察者
为什么 lock() 返回 shared_ptr 而不是 bool
lock() 返回 shared_ptr 是为了原子性保障：它一次性完成“检查是否存活 + 增加引用计数”两件事。如果只返回 bool，你得先判断再手动构造 shared_ptr，中间可能被其他线程析构，导致 shared_ptr 构造失败或悬垂指针。
- 安全写法：
if (auto p = wp.lock()) { use(*p); }——p非空即有效，且生命周期由其自身管理 - 危险写法：
if (wp.expired()) return; auto p = shared_ptr<t>(wp);</t>——expired()和后续构造之间存在竞态窗口 -
expired()仅适合做快速预检（比如日志、统计），不能替代lock()用于实际访问
weak_ptr 本身也有生命周期问题
weak_ptr 不延长对象寿命，但它自己是个对象，需要被正确管理。常见误区是把它存在栈上却长期依赖，或者复制后忘记它也会失效。
立即学习“C++免费学习笔记（深入）”；
-
weak_ptr可以拷贝、赋值、作为容器元素，但每次拷贝都只是对同一“观察状态”的复刻，不改变原对象生命周期 - 不要长期缓存
weak_ptr并反复调用lock()——如果原始shared_ptr已释放，所有副本都会lock()失败 - 调试时注意：
wp.use_count()永远返回 0（它不参与计数），要看关联的shared_ptr的use_count()才知道对象是否还活
和 raw pointer 比，weak_ptr 多做了什么
裸指针也能“不增加引用计数”，但无法自动感知对象销毁。weak_ptr 的核心价值是提供了一种可验证的、线程安全的“弱观察”机制。
- 裸指针：对象析构后指针变悬垂，访问必未定义行为，无任何防护
-
weak_ptr：析构后lock()返回空shared_ptr，程序可主动处理（跳过、重试、报错） - 性能开销：每个
weak_ptr需额外一个控制块字段（通常 1~2 个指针大小），比裸指针重，但远低于shared_ptr的两次内存分配成本
真正容易被忽略的是：weak_ptr 必须由 shared_ptr 构造，不能从裸指针直接创建——这意味着你得先有合理的 shared_ptr 生命周期设计，否则 weak_ptr 就成了空中楼阁。
