直接用 std::thread 启动成员函数不加生命周期保护极易崩溃，因 this 指针在子线程执行时可能已失效；安全做法是类继承 enable_shared_from_this 并用 shared_ptr 管理对象，lambda 中捕获 self = shared_from_this()。
直接用 std::thread 启动成员函数，不加生命周期保护，90% 以上概率导致崩溃或未定义行为 —— 根本原因不是语法写错，而是 this 指针在子线程执行时早已失效。
为什么 std::bind(&MyClass::func, this, ...) 很危险
它只是把 this 当作普通指针传进去，不做任何生命周期检查。一旦对象在子线程真正运行前被析构（比如函数返回、局部对象销毁），this 就成悬空指针。
-
std::bind在 C++17 起已标记为“不鼓励用于新代码”，语法冗长且对移动语义支持差 - 无法区分哪些成员变量实际被用到，容易意外捕获大量无关状态
- 调试时错误堆栈常指向
std::thread::_State_impl，掩盖真实问题源头 - 若类未继承
std::enable_shared_from_this，后续想补救都无从下手
[this] 捕获 lambda 的真实含义和限制
[this] 不是“捕获对象”，只是按值复制一个指针副本 —— 和写 MyClass* p = this; 然后传给线程没本质区别。它不延长对象寿命，也不阻止析构。
- 适用于：线程生命周期明确短于当前对象（如在构造函数中启动、且保证对象长期存活）
- 不适用：异步回调、定时器、线程池任务、detach 后不管的场景
- 常见误判：以为
[=]更安全 —— 实际上它隐式包含this，风险完全一样 - 注意：若成员函数是
const，lambda 内部访问非 mutable 成员会编译失败
真正安全的方案：用 shared_ptr 替代裸 this
必须满足两个前提：类继承 std::enable_shared_from_this<myclass></myclass>，且对象本身由 std::shared_ptr<myclass></myclass> 管理（不能是栈对象或裸 new）。
立即学习“C++免费学习笔记（深入）”；
- 写法是
[self = shared_from_this()]() { self->do_work(); }，不是[this] -
self是std::shared_ptr，只要 lambda 存活，对象就不会析构 - 如果线程可能修改共享状态，仍需额外同步（如
std::mutex），shared_ptr只管内存安全，不解决数据竞争 - 避免循环引用：若类内持有
std::function并存 lambda，应改用weak_ptr检查再锁定
线程 detach 前必须确认资源归属
调用 t.detach() 后，线程与原始作用域彻底解耦 —— 此时连 shared_ptr 都救不了你，除非所有依赖资源（包括 self）都在线程内部完成拷贝或转移。
- 推荐优先用
t.join()或托管在线程池中，避免裸detach - 若必须
detach，确保 lambda 内只使用已拷贝的值（如[x = member_var, s = std::string{str}]），而非任何指针或引用 - 不要在 lambda 里调用
this->访问容器、文件句柄等易失效资源，它们可能已被主线程关闭 - 日志、计数器等简单 POD 类型可放心值捕获；复杂对象优先考虑 move 或 deep copy
最易被忽略的一点：即使用了 shared_from_this()，如果对象是栈上创建的（比如 MyClass obj;），调用 shared_from_this() 会直接抛 std::bad_weak_ptr 异常 —— 这个检查不会自动发生，必须在构造时就确保用 std::make_shared 创建实例。
