weak_ptr不参与对象生命周期管理，仅作为shared_ptr的弱引用观察者；必须通过lock()获取临时shared_ptr才能安全访问对象，否则可能失效。
weak_ptr 不参与对象生命周期管理，只用于安全观察 shared_ptr 管理的对象；它本身不能解引用，必须通过 lock() 临时获取 shared_ptr 才能访问目标——这是它和 shared_ptr 最本质的区别。
什么时候必须用 weak_ptr 而不是 shared_ptr？
核心判断标准：你是否希望“持有该对象”这件事影响它的销毁时机。
- 如果希望影响（比如你是唯一使用者、需确保对象存活），用
shared_ptr - 如果只是临时查看、监听、缓存或建立非强制依赖关系，且对象销毁后你能接受“访问失败”，就该用
weak_ptr - 父子结构中，子对象持有父对象的引用时，父必须用
shared_ptr，子必须用weak_ptr；反过来同理（如观察者持有被观察者）
典型反例：shared_ptr<parent> child::parent</parent> + shared_ptr<child> Parent::child</child> → 引用计数永远不归零，内存泄漏。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
lock() 和 expired() 到底该怎么选？
expired() 只是原子读取 shared_count == 0 的快照，它不加锁、不提升引用计数，也不能防止竞态——调用完立刻被销毁是完全可能的。所以它不适合做“if-then”分支依据。
- 正确做法：直接调用
lock()，检查返回值是否为空 - 错误写法：
if (!wp.expired()) { auto sp = wp.lock(); use(*sp); }—— 中间可能已被销毁 -
expired()唯一合理用途是日志、调试或资源统计等“不触发访问”的场景
weak_ptr 会延长内存占用吗？
会，但只延长控制块（control block）的生命周期，不影响对象本体。
- 对象在最后一个
shared_ptr析构时立即销毁（shared_count == 0） - 但只要还有
weak_ptr存活，控制块就得留着（因为要维护weak_count） - 这意味着：大量长期存活的
weak_ptr（比如注册在全局监听器里但没清理）会导致控制块堆积，虽不严重，但可测可优化 - 用完记得
reset()或让其自然析构，尤其在容器中长期持有时
真正容易被忽略的是控制块的隐式持有成本——它小但真实存在；而更隐蔽的问题是：很多人把 weak_ptr 当成“更安全的 shared_ptr”来用，结果在不需要观测语义的地方滥用，反而增加弱引用计数管理和逻辑复杂度。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
