构造函数中调用std::thread易崩溃，因this指针未完全初始化、虚表未就绪，且未join/detach会导致析构时std::terminate()。安全做法是延迟到start()方法启动线程，或用shared_ptr/weak_ptr管理生命周期。
构造函数里调用 std::thread 为什么一跑就崩
崩溃通常发生在对象还没构造完，线程就开始执行成员函数——此时 this 指针所指内存可能未初始化完毕，或虚表尚未就绪。更危险的是，std::thread 构造后若没 join() 或 detach()，对象析构时会直接调用 std::terminate()，而默认行为就是 abort()。
- 构造函数中启动的线程，可能在
return前就已开始运行，但此时基类、成员变量、虚函数表都未必就位 -
std::thread对象是可移动不可拷贝的，若在构造函数里用std::move赋值给成员变量，必须确保移动后原对象不再被访问 - 常见错误写法：
th_ = std::thread(&A::work, this)—— 若A构造中途崩溃，this是半成品，work()访问任何成员都可能越界或解引用野指针 - 别在构造函数末尾才
th_.detach()：万一前面某步抛异常，th_析构时仍会 terminate
std::thread 成员变量未正确管理的典型崩溃链
一旦 std::thread 成员变量在析构时既没 join() 也没 detach()，C++ 标准强制调用 std::terminate()。这个调用不经过任何异常处理路径，直接终止进程，gdb 里看到的堆栈常停在 ~thread() 或 std::terminate()，而不是你写的业务代码。
- 崩溃信号通常是
SIGABRT，不是SIGSEGV，说明问题出在资源生命周期，而非内存访问 - 如果对象是栈上分配（如局部变量），且构造函数抛异常，成员
std::thread的析构函数仍会被调用——此时它大概率处于“可 joinable” 状态，触发 terminate - 即使你写了
th_.join()在构造函数末尾，也要加try/catch包裹整个构造逻辑，否则异常发生时join()根本不会执行 - 不要依赖
std::thread的移动赋值“自动安全”：移动后原对象进入 valid-but-unjoined 状态，若忘记检查th_.joinable()就析构，照样崩
安全启动线程的三个硬性条件
想让构造函数启动线程不出事，必须同时满足：对象完全构造完成、线程不访问未就绪成员、线程资源有明确归属。没有折中方案，少一个条件就大概率崩溃。
- 把线程启动逻辑抽到独立的
start()方法里，构造函数只做数据初始化，不碰线程 - 若必须在构造时启动，用
std::shared_ptr+std::weak_ptr配合std::enable_from_this，确保线程内能安全判断对象是否还活着 - 所有跨线程访问的成员变量，必须用
std::atomic或加锁保护；禁止裸指针、裸引用跨线程传递，尤其是捕获[this]时 - 构造函数里绝不调用虚函数——子类虚函数可能访问到未初始化的子类成员，而父类构造函数中调用的虚函数会绑定到当前类，行为不可控
调试时最容易忽略的细节
崩溃点往往不在构造函数里，而在几毫秒后的线程函数第一行。这时候看 backtrace 容易误判为“线程函数写错了”，其实根因是构造没做完就跑了线程。
- 用
gdb启动后，在std::thread构造处下断点，然后stepi单指令跟踪，确认线程是否真的在构造返回前就 sched_out - 在构造函数开头打日志（
std::cout ），在线程函数第一行也打日志，观察输出顺序——如果线程日志先于构造完成日志，就是典型未完成构造就执行 - 编译时加
-fsanitize=thread，TSan 会在构造函数内启动线程且该线程访问非静态成员时直接报 data race，比等崩溃更早暴露问题 - 注意
std::thread构造本身不抛异常，但传入的可调用对象（比如 lambda）若在捕获时引发异常（如shared_ptr构造失败），也会导致构造函数中途退出，进而触发后续析构问题
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
