异步执行时this指针悬空是最危险陷阱：lambda捕获this后交由std::async或线程延迟执行，若对象先析构则访问成员触发未定义行为；应改用[self = shared_from_this()]或weak_from_this()配合lock()判空处理。
异步执行时 this 指针变成悬空指针
这是最常见也最危险的问题：lambda 捕获 this 后被交给 std::async、std::thread 或事件循环延迟执行，而原始对象在 lambda 执行前已被析构。此时 this 指向的内存已释放，访问成员变量或调用成员函数触发未定义行为（UB），轻则数据错乱，重则段错误崩溃。
典型表现是程序在特定负载下偶发崩溃，堆栈里能看到类似 Segmentation fault (core dumped)，且 crash 点总在 lambda 内部对成员的访问处。
- 不要依赖“对象应该还活着”的假设——线程调度、析构顺序、RAII 释放时机都不可控
- 若必须异步，优先改用
[self = shared_from_this()]，但前提是类继承std::enable_shared_from_this<T>且对象由std::shared_ptr管理 - 避免把捕获
this的 lambda 存入std::function成员变量中，除非你能 100% 保证该std::function的生命周期不长于宿主对象
weak_ptr 检查漏掉 lock() 成功判断
用 weak_from_this() 捕获再 lock() 是安全回调的推荐做法，但很多人只写了 if (auto ptr = self.lock()) 却忘了在 else 分支做兜底处理，或者误以为 lock() 失败只是“罕见情况”而忽略日志/告警。
实际中，对象可能在 lock() 前一刻被销毁，尤其在高并发或频繁创建销毁的场景（如 GUI 控件、网络连接句柄）下，失败概率并不低。
立即学习“C++免费学习笔记（深入）”；
-
self.lock()返回空shared_ptr是正常路径，不是异常，必须显式处理 - 不要在 lambda 中直接调用
self->member—— 必须先判空，再解引用 - 若业务逻辑不允许“跳过执行”，应设计 fallback 行为（如通知上层、记录警告），而不是静默失败或 assert
继承 enable_shared_from_this 但对象不是 shared_ptr 创建的
很多开发者照着示例加了 class X : public std::enable_shared_from_this<X>，却忘了关键前提：对象必须由 std::make_shared<X>() 或 std::shared_ptr<X>(new X) 构造，否则调用 shared_from_this() 会抛 std::bad_weak_ptr 异常。
这个错误通常在单元测试里不暴露，因为测试对象常被手动 new 出来；一到集成环境用 DI 容器或工厂模式创建，就立刻 crash。
- 编译期无法检查，运行期才爆炸 —— 建议在构造函数末尾加断言：
assert(shared_from_this().get() == this); - 如果类设计上不支持 shared_ptr 管理（比如需自定义内存布局或多重继承），就别硬套
enable_shared_from_this，改用值捕获必要字段或引入外部生命周期管理 -
shared_from_this()和weak_from_this()都要求对象已由shared_ptr拥有，否则无效
多线程中 this 捕获引发竞态而非单纯悬空
当多个线程同时访问同一对象，且其中一个线程正执行析构，另一个线程却在调用捕获了 this 的 lambda，问题就不仅是“悬空”，而是读-写竞态（data race）。即使对象还没完全析构完，其成员变量可能已处于中间状态（如部分成员被析构函数清零，部分仍有效）。
这种竞态比纯悬空更难复现和调试，ASan/TSan 可能报 ThreadSanitizer: data race，但堆栈指向 lambda 内部，容易误判为单线程问题。
- 仅靠智能指针不能解决竞态 ——
shared_from_this()只保活，不保互斥 - 若 lambda 需修改成员，必须配合锁（如
std::mutex）或原子操作，且锁的粒度要覆盖整个 lambda 执行过程 - 考虑是否真需要从 lambda 修改对象状态；很多时候更适合把结果通过回调参数传出，由主线程/拥有者决定如何更新
