weak_ptr.lock()是唯一安全的提升方式，返回shared_ptr：对象存活则增加引用计数并返回有效指针，否则返回空；它是原子操作，线程安全，但必须检查返回值是否为空以避免解引用崩溃。
weak_ptr.lock() 是唯一安全的提升方式
直接用 shared_ptr 构造函数或赋值把 weak_ptr 转成 shared_ptr 会编译失败——weak_ptr 不提供隐式转换，也不接受裸指针构造。唯一合法、线程安全的提升方法就是调用 lock()。
它返回一个 shared_ptr：如果原 weak_ptr 指向的对象还活着，就增加引用计数并返回有效指针；如果对象已被释放，就返回空的 shared_ptr（ptr.get() == nullptr）。
lock()是原子操作，多线程下调用安全- 返回的
shared_ptr和原shared_ptr共享同一控制块，引用计数正确同步 - 不要对
lock()结果做“先判空再用”的假设性解引用——必须检查返回值
不检查 lock() 返回值会导致崩溃
常见错误是忽略 lock() 可能返回空指针，直接解引用：
std::weak_ptr<int> wp = std::make_shared<int>(42); // ... 期间原始 shared_ptr 被销毁 auto sp = wp.lock(); // 此时 sp 为空 std::cout << *sp; // 未定义行为：解引用空 shared_ptr → 崩溃或随机值
正确做法始终检查：
- 用
if (auto sp = wp.lock()) { /* 安全使用 sp */ } - 或显式判断：
if (sp) { ... }，sp.get() != nullptr等价但更啰嗦 - 不能只靠
wp.expired()提前判断——它和lock()之间存在竞态窗口（尤其多线程）
lock() 和 expired() 的行为差异与适用场景
expired() 只读取引用计数是否为 0，开销极小；lock() 尝试原子地增加计数，有轻微开销但带回了所有权。
- 仅需知道“对象是否还存在”（比如日志、统计、跳过处理）→ 用
expired() - 需要访问对象内容或延长其生命周期 → 必须用
lock()并检查结果 - 二者不是等价替代：即使
!wp.expired()为 true，wp.lock()仍可能返回空（极端竞态下控制块被销毁的瞬间）
循环引用中 weak_ptr.lock() 的典型误用
在父-子双向持有场景里，子用 weak_ptr 持父是标准解法。但容易在回调中写错：
struct Parent {
std::shared_ptr<Child> child;
};
struct Child {
std::weak_ptr<Parent> parent;
void onEvent() {
auto p = parent.lock(); // ✅ 正确：每次需要时都 lock
if (p) p->doSomething();
}
};- 错误：把
lock()结果缓存为成员变量（如std::shared_ptr<Parent> cached_parent）——这又引入了强引用，可能复活已销毁对象或干扰析构顺序 - 错误：在构造函数里提前
lock()并保存——此时父对象可能尚未完全构造完毕，引发未定义行为 - 原则：
lock()应该按需、就近、一次一用
真正容易被忽略的是：lock() 成功不代表对象处于可用状态——比如对象内部已进入析构中途（如虚函数表被清空），此时调用成员函数仍可能崩溃。所以业务逻辑层还需配合状态标记或 RAII 守卫。
