必须在std::thread销毁前调用join()或detach()，否则触发std::terminate()崩溃；因joinable()为true时析构会强制终止程序，需用if(t.joinable())t.join()防护，join()阻塞等待线程结束并清理资源，detach()使线程后台运行但须确保其访问资源生命周期足够长。
必须在 std::thread 对象销毁前调用 join() 或 detach()，否则程序直接崩溃（std::terminate()）——这不是警告，是 C++ 标准强制行为。
为什么不调用 join() 或 detach() 就会崩溃
每个 std::thread 对象内部持有一个“可联结”（joinable()）状态。只要这个状态为 true，就表示底层线程仍在运行，且该 std::thread 对象仍对其负有管理责任。
当对象超出作用域或被显式销毁时，如果此时 joinable() 仍返回 true，C++ 运行时会无条件调用 std::terminate() —— 不抛异常、不打印堆栈、不给你修复机会。
- 常见触发场景：
std::thread是局部变量，函数末尾没处理就 return；或放在容器里但忘了遍历调用join() - 调试线索：崩溃时堆栈顶部常出现
std::thread::~thread()→std::terminate() - 安全检查习惯：在析构前加一句
if (t.joinable()) t.join();（或t.detach()），比靠记忆更可靠
join() 的阻塞等待本质
join() 不是“把子线程拉回主线程执行”，而是让调用者线程（不一定是主线程）停在原地，直到目标线程函数返回。
- 调用后，
t.joinable()立即变为false；之后再调用t.join()会触发未定义行为（不是报错，是 UB） - 资源回收发生在
join()返回时：线程栈、内核句柄等由join()同步清理 - 适合场景：需要子线程结果（如计算值、文件写入完成）、任务有明确依赖关系、测试中需确定执行顺序
- 性能注意：若子线程卡死或无限循环，
join()会让调用者永久阻塞——生产环境应配合超时机制（需自行封装，标准std::thread不支持）
detach() 的资源生命周期陷阱
detach() 把线程和 std::thread 对象解绑，之后该对象不能再用于任何操作（joinable() 变 false），而分离的线程继续在后台运行，由系统负责最终回收。
- 最大风险：分离线程访问的局部变量、栈内存、临时对象可能早已被销毁（比如主线程函数已 return）
- 典型错误：在 lambda 中捕获局部变量（
[x]() { /* use x */ }），然后detach()——x的生命周期无法保证 - 安全做法：只在分离线程中使用全局/静态变量、堆分配对象（
new或std::shared_ptr管理），或确保其生存期长于线程本身 - 兼容性注意：Windows 和 POSIX 下，主线程退出时，进程终止，所有分离线程会被强制结束 —— 不是优雅退出，而是立即杀掉
选 join() 还是 detach()？看控制权归属
这不是性能选择题，而是责任划分问题。
- 选
join()：你愿意等、能等、且需要同步点（例如批量任务完成后统一汇总） - 选
detach()：你明确接受“失控”——不关心它何时结束、不依赖它的结果、且已确保它用的所有资源不会提前失效 - 反模式：用
detach()逃避等待，却不检查资源生命周期；或在循环中反复创建std::thread却只join()最后一个 - 复杂点往往不在语法，而在分离线程里那一行
std::cout value;——data是谁 new 的？谁 delete 的？什么时候 delete 的？
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
