std::thread析构前必须调用join()或detach()，否则触发std::terminate()崩溃；默认参数按值拷贝，传引用需std::ref()；join()同步等待，detach()后台运行但需确保数据生命周期。
std::thread 创建后必须显式处理生命周期
不调用 join() 或 detach() 就让 std::thread 对象析构，会触发 std::terminate() —— 程序直接崩溃，且不抛异常。这是最常踩的坑，没有之一。
原因在于 std::thread 的析构函数会检查 joinable() 状态；只要线程还在运行（或已启动但未分离），就认为是可连接的，此时析构即终止进程。
- 用
join()：主线程等待该线程结束，适合需要结果或同步完成的场景 - 用
detach()：线程后台运行，与主线程解耦，但无法再控制或获取其状态 - 务必在析构前判断：
if (t.joinable()) t.join();
或
if (t.joinable()) t.detach();
传递参数时注意值拷贝与引用陷阱
std::thread 构造时对可调用对象及其参数**默认按值拷贝**。若想传引用，必须用 std::ref() 包装；否则你在线程里操作的只是副本。
常见错误：传局部变量地址给线程，却没意识到原变量可能在子线程执行前就销毁了。
立即学习“C++免费学习笔记（深入）”；
- 正确传引用：
int x = 42; std::thread t(func, std::ref(x));
- 传 lambda 捕获引用需谨慎：
std::thread t([&x]{ x++; }); // 若 x 是局部变量，风险极高 - 推荐方式：用值传递 + 移动语义（如
std::move(str)）避免冗余拷贝
join() 和 detach() 的行为差异直接影响资源管理
join() 是同步阻塞操作，调用后当前线程暂停，直到目标线程退出；detach() 则把线程转为“守护线程”，由系统接管其资源回收。
-
join()后不能再调用join()或detach()，否则抛std::system_error（错误码resource_deadlock_would_occur） -
detach()后线程 ID 变为std::thread::id()（空 ID），且无法再join() - 一旦
detach()，线程内访问的栈变量、临时对象很可能已失效 —— 必须确保所有数据生命周期长于线程执行时间
简单多线程示例：一个安全可运行的模板
下面是最小可行结构，包含异常安全处理和 joinable 检查：
#include#include void worker(int id) { std::cout << "Thread " << id << " running/n"; } int main() { std::thread t(worker, 1); // 模拟可能提前返回的逻辑 if (t.joinable()) { t.join(); // 或 t.detach()，根据需求选 } return 0; }
如果线程函数可能抛异常，建议用 RAII 封装（比如自定义 scoped_thread 类），否则异常路径下容易漏掉 joinable() 检查。
真正难的不是写多线程，而是确定「谁负责等它结束」「哪些数据还活着」「失败时怎么清理」——这些比 std::thread 语法本身更关键。