std::thread 构造后必须 detach 或 join，否则析构时调用 std::terminate() 导致程序崩溃；正确做法仅两种：join() 等待完成，或 detach() 后台运行，且需注意传参语义、生命周期及 thread_local 初始化时机。
std::thread 构造后必须 detach 或 join
不处理的 std::thread 对象在析构时会调用 std::terminate()，程序直接崩溃——这不是警告，是硬性约束。常见错误是局部创建线程后忘了管它，比如写成：
void bad_example() {
std::thread t([]{ /* do work */ });
// t 离开作用域，自动析构 → terminate()
}正确做法只有两种：join()（等待完成）或 detach()（后台运行，不再关联）。选哪个取决于场景：
-
join()：适合需要结果、或必须等子任务结束再继续的逻辑（如初始化阶段） -
detach()：适合“发出去就不管”的异步日志、心跳上报等，但要注意：被 detach 的线程不能访问栈上变量，否则极易野指针 - 如果线程可能提前退出，又不确定是否已
join过，用t.joinable()判断再操作，避免重复join报错
传参到 std::thread 会默认 move 或 copy，不是引用
写 std::thread(f, x) 时，x 会被拷贝进线程私有栈；写 std::thread(f, std::ref(x)) 才真正传引用。很多人误以为加了 & 就行，但这样写是错的：
int val = 42;
std::thread t([](int& v) { v = 100; }, &val); // ❌ 编译失败：&val 是右值指针，不能绑定到 int&必须显式用 std::ref 包装：
立即学习“C++免费学习笔记（深入）”；
std::thread t([](int& v) { v = 100; }, std::ref(val)); // ✅容易踩的坑：
- lambda 捕获
[&]不等于线程参数传引用——捕获的是创建 lambda 时的上下文，而线程启动是之后的事，栈变量可能已销毁 - 移动语义生效时（比如传
std::unique_ptr），原变量立刻失效，别在线程外再访问 - 传 raw pointer 要格外小心生命周期，推荐优先用
std::shared_ptr管理共享资源
thread_local 变量不是“每个线程一份”那么简单
thread_local 确实为每个线程提供独立副本，但它只在**首次访问时构造**，且**在线程结束时自动析构**。这带来两个隐含行为：
- 如果某线程从没访问过该变量，就不会构造，也不会析构——不能靠它做“线程启动即初始化”的副作用
- 静态存储期的
thread_local（如全局或 namespace 作用域）支持动态初始化，但不同编译器对初始化顺序的保证程度不一，跨 DLL 或 shared object 时尤其危险 - 和
static一起用要警惕：比如static thread_local std::vector<int> cache;</int>，每个线程第一次调用函数时才构造，且无法手动控制构造时机
更稳妥的做法是配合 std::call_once + std::once_flag 做延迟初始化，而不是依赖 thread_local 的隐式构造。
不要用裸 thread 管理复杂生命周期
直接用 std::thread 适合简单、短生命周期任务。一旦涉及线程池、任务队列、取消机制、异常传播，裸 thread 很快失控。典型问题包括：
- 线程意外退出时，没有统一错误处理路径，异常直接终止进程
- 无法优雅停止：没有标准方式通知线程“请尽快退出”，只能轮询 flag 或用条件变量，但 flag 本身需同步
- 资源泄漏风险高：比如线程里 new 了内存，但没 catch 异常，析构函数不会执行
这时候应该换方案：
- 用
std::jthread（C++20）：自带自动join和可协作中断（request_stop()） - 封装自己的 task runner，用
std::promise/std::future传递结果和异常 - 第三方库如
folly::Executor或boost::asio::thread_pool更适合生产级调度
多线程最难的从来不是“怎么启一个线程”，而是“怎么让它安全地开始、通信、出错、结束”。std::thread 只解决第一个字。
