std::Thread析构时若处于joinable状态会直接调用std::terminate()终止程序；必须在析构前显式调用join()或detach()，推荐使用std::jthread或raii封装确保安全。
std::thread 析构时未 join/detach 会直接终止程序
会，而且不是“崩溃”这种可捕获的错误，是调用 std::terminate() 强制中止——进程退出码通常是 3 或 134（SIGABRT），没堆栈、没异常、没日志，只有一行 terminate called without an active exception 或类似提示。
这是 c++ 标准强制要求的行为：只要 std::thread 对象处于 joinable 状态（即既没调用过 join()，也没调用过 detach()），其析构函数就必须调用 std::terminate()。
-
joinable()判断的是线程是否“正在运行且未被分离/等待”，不是“有没有启动过”——比如std::thread t{func}; t.detach();之后t.joinable()就是false - 局部变量、RAII 成员、临时对象，只要生命周期结束时仍
joinable()，就触发终止 - 即使线程函数早已执行完，只要没显式
join()或detach()，对象仍为joinable()（因为系统资源尚未回收）
什么时候必须用 join()，什么时候用 detach()？
选哪个不取决于“要不要等结果”，而取决于“谁负责清理线程资源”。join() 是同步等待+清理；detach() 是放生+由系统后台回收。
- 用
join()：主线程需要确保子线程完成后再继续（比如初始化、批量处理、测试断言）；或需捕获子线程异常（注意：std::thread不传播异常，得靠共享状态或std::promise） - 用
detach()：后台任务（如日志刷盘、心跳上报），且能保证线程函数里不访问已销毁的对象（尤其不能捕获局部变量的引用/指针） - 别以为
detach()更“轻量”就乱用——一旦线程访问了main()退出后已被释放的全局/静态对象，行为未定义（常见于单例析构后又被回调）
容易被忽略的隐式 joinable 场景
很多问题不是写错了 join()，而是根本没意识到对象还活着。
立即学习“C++免费学习笔记（深入）”；
- 函数返回
std::thread临时对象：比如return std::thread{f};，若接收端没赋值（如直接丢弃或仅用于条件判断），临时对象析构即终止程序 - 类成员是
std::thread，但构造函数里只创建没join()/detach()，而析构函数又忘了处理——这是最典型的 RAII 失败案例 - 移动后误判状态：
std::thread t1{f}; auto t2 = std::move(t1);后t1.joinable()是false，但有人会误以为t2也需要手动管理，其实只需管t2 - 异常路径遗漏：
try { t = std::thread{f}; do_something(); t.join(); } catch(...) { /* 忘了 t.join() */ }—— 此时t仍joinable()
如何安全地避免 terminate？
核心原则：让 std::thread 的生命周期和资源管理变得“不可绕过”。
- 封装成 RAII 类：在构造时接受可调用对象，在析构时自动
join()（如果joinable()）；或提供明确的detach_on_destroy(bool)接口 - 用
std::jthread（C++20）：自带析构时join()行为，且支持协作式中断（request_stop()），比裸std::thread安全得多 - 编译期检查：Clang/GCC 的
-Wthread-safety-analysis（需加注解）或静态分析工具（如 clang-tidy 的concurrency-unnecessary-copy-initialization）能抓部分漏掉的join() - 调试时加断点：在
std::thread::~thread()下断，看是谁在析构一个joinable()对象——比猜快得多
真正麻烦的从来不是“不知道要 join”，而是“以为已经 join 了”。线程对象的状态容易被移动、异常、作用域遮蔽悄悄改写，盯住 joinable() 的真假比记住语法更重要。