必须在std::thread销毁前调用join()或detach()，否则程序静默终止；传参需注意值拷贝、引用包装和lambda捕获安全；并发写须用atomic或mutex同步。
std::thread 启动后不等待就退出主线程？
主线程结束时，所有 std::thread 对象若仍处于可连接（joinable）状态，程序会直接调用 std::terminate()——这不是崩溃日志，而是静默终止，调试时容易误判为“没跑起来”。
- 必须在
std::thread对象销毁前调用join()或detach()；join()是最安全的默认选择 - 别把线程对象放在局部作用域末尾才处理，容易遗漏；推荐 RAII 封装（比如用
std::jthread（C++20），但若只能用 C++11/14，就手动加~检查） - 常见错误写法：
std::thread t(func); t.detach();—— 之后无法控制生命周期，且可能访问已销毁的栈变量
传参到线程函数时值被意外修改或失效？
std::thread 构造时会对参数做**拷贝**，但如果你传的是指针、引用或 lambda 捕获了局部变量，实际行为取决于你传的是什么，不是“自动安全”。
- 传值没问题：
std::thread t(func, 42, std::string("hello"))→ 安全 - 传引用需显式包装：
std::thread t(func, std::ref(x))，否则编译失败（防止隐式引用陷阱） - lambda 捕获局部变量用
[&]是危险的：主线程栈帧一退，线程里访问的就是野内存；改用[=]或显式捕获值（[x]）更稳妥 - 传
std::vector迭代器？不行——迭代器本身不保底，得传容器副本或确保容器生命周期长于线程
多个线程同时写同一块内存导致结果错乱？
没有同步机制的并发写（哪怕只是 counter++）是未定义行为。CPU 重排、缓存不一致、非原子读-改-写都会让结果不可预测。
- 简单计数优先用
std::atomic<int></int>，比std::mutex开销小、写法简洁：counter.fetch_add(1, std::memory_order_relaxed) - 需要保护一段逻辑（比如更新两个相关变量），才上
std::mutex；记得用std::lock_guard自动管理，别手写lock()/unlock() - 避免锁粒度过大：比如整个循环体加一把锁，等于变相串行；应只锁真正共享的临界区
- 别在线程函数里抛异常却不捕获——未捕获异常会直接调用
std::terminate()，和 joinable 问题一样静默失败
想等所有线程完成再继续，但手写 join 太啰嗦？
手动管理一堆 std::thread 的 join() 容易漏、顺序难控、异常路径下更难保证全部 join。
立即学习“C++免费学习笔记（深入）”；
- 把线程存进
std::vector<:thread></:thread>，启动完统一遍历调用join()；但注意：一旦某个join()抛异常（比如线程已 detach），后续就断了 - 更健壮的做法：用范围 for + try/catch 包裹每个
join()，或封装一个辅助函数，在析构时强制 join 所有存活线程 - C++20 的
std::jthread在析构时自动join()，但要注意它不能 move-only 类型的可调用对象（比如某些 lambda），编译期可能报错 - 别用
sleep或轮询代替join()——既浪费 CPU，又不精确，还掩盖资源管理问题
多线程真正麻烦的从来不是“怎么开”，而是“谁在什么时候访问什么内存”。哪怕只加一个 std::atomic，也得确认它的 memory order 是否符合你的同步意图；而 std::thread 对象本身，就是个随时可能咬人的生命周期守门员。
