std::thread析构时若joinable()为真会直接调用std::terminate()导致程序崩溃；必须在析构前显式join()或detach()，并确保detached线程不访问已销毁的局部资源。
std::thread 析构时未 join 或 detach 会直接 terminate
这是最致命的坑：只要 std::thread 对象离开作用域，且 joinable() 返回 true，其析构函数就会调用 std::terminate() —— 程序瞬间崩溃，不抛异常、不打印堆栈。不是“可能出错”，是“必然 crash”。
常见错误现象：
- 局部
std::thread变量没写join()或detach()就 return - 异常路径绕过了
join()（比如线程启动后、join()前抛了异常） - 误以为
detach()后可以不管——其实 detached 线程仍需确保它访问的资源（如局部变量、this 指针）在它结束前不被销毁
join 和 detach 的语义区别必须分清
join() 是同步等待，主线程阻塞直到目标线程执行完；detach() 是彻底分离，线程后台运行，与原 std::thread 对象再无关联。选哪个不看“方便”，而看控制流需求。
使用场景：
立即学习“C++免费学习笔记（深入）”；
- 需要等结果或确保某段逻辑执行完毕（比如初始化完成、文件写完）→ 必须
join() - 纯后台任务，生命周期独立于主线程，且能保证所有依赖资源长期有效（如全局缓冲区、静态对象）→ 才考虑
detach() - 绝不能对同一个
std::thread对象反复join()或先join()再detach()—— 行为未定义
示例：t.join() 后再调用 t.joinable() 返回 false；t.detach() 后同理，且不能再调 join()。
安全写法：RAII 封装 + 显式检查
靠人脑记“一定记得 join()”不可靠。推荐两种实操方案：
- 用 RAII 类（如
scoped_thread）自动在析构时join()：构造时接管std::thread，析构时若joinable()则强制join() - 手动管理时，每创建线程后立刻检查并处理：
if (t.joinable()) t.join();—— 放在函数末尾、catch 块、甚至每个 return 前 - 永远在调用
join()或detach()前加assert(t.joinable())或日志，避免对已 move 走或已操作过的线程重复操作
注意：std::thread 不可拷贝，只能 move。传参给线程函数时，用 std::ref(x) 传引用，否则默认按值拷贝 —— 这常导致意外的生命周期错位。
detached 线程访问局部变量 = 悬垂指针
这是最容易被忽略的隐性崩溃源。detach() 不等于“线程安全”。如果 detached 线程捕获了局部变量地址、this 指针，或引用了栈上对象，而主线程早已退出该作用域，线程继续运行时访问的就是野内存。
典型错误：
-
std::thread t{[x](){ use(x); }}; t.detach();→x是局部变量，lambda 按值捕获没问题；但若写成[&x](){ use(x); }，就是悬垂引用 -
std::thread t{&MyClass::run, this}; t.detach();→ 若this对象在 detached 线程运行完前被 delete，就崩 - 解决方案：只让 detached 线程访问全局/静态对象、堆上对象（且确保其生命周期长于线程），或用
std::shared_ptr管理对象生命周期
真正麻烦的从来不是“怎么调用 join()”，而是线程间数据所有权和生命周期是否对齐。哪怕语法全对，一个悬垂引用就能让程序在随机时间点崩掉。
