调用 join() 前必须检查 t.joinable()，否则会触发未定义行为；join() 阻塞当前线程直至目标线程结束；推荐使用 c++20 std::jthread 替代 std::thread，其析构自动 join 并支持协作式取消。
调用 join() 前必须确保线程处于可连接状态
直接对一个已 join() 过、已 detach() 或尚未启动的 std::thread 对象调用 join()，会触发未定义行为（通常程序崩溃并抛出 std::system_error，错误码为 invalid_argument 或 no_thread）。
常见误操作包括：重复调用 join()；在构造后没检查就直接 join()（比如线程对象被 move 走了）；或在线程已 detach 的情况下仍试图 join。
- 安全做法是每次
join()前先用t.joinable()判断 —— 只有返回true才能调用join() - 不要依赖析构函数自动处理：如果 thread 对象离开作用域时仍
joinable()，其析构会调用std::terminate() - 避免裸写
t.join()，推荐封装成 RAII 类型（如scoped_thread），或至少用if (t.joinable()) t.join();
join() 会阻塞当前线程，直到目标线程执行完毕
这是同步等待的核心语义 —— 调用线程会挂起，不消耗 CPU，直到被等待线程自然结束（函数返回）或因异常退出。它不是轮询，也不支持超时。
如果你需要带超时的等待（比如防止卡死），std::thread 本身不提供该能力，得换方案：
- 用
std::condition_variable+std::mutex+ 状态标志手动实现可超时等待 - 改用
std::jthread（C++20），它内置join()和可中断的request_stop()，且析构时自动join() - 避免在 GUI 主线程或实时性敏感场景中无条件
join()，可能造成界面冻结或响应延迟
多线程批量等待：别手写循环 join()，注意顺序和异常安全
管理多个线程时，常见模式是把它们存进 std::vector<:thread></:thread>，然后遍历调用 join()。但这里有两个隐形陷阱：
- 如果某次
join()抛异常（比如线程内部 throw），后续线程将不会被等待，导致资源泄漏甚至程序终止 - 调用顺序影响逻辑：线程 A 是否必须等 B 结束后才开始工作？
join()的顺序不等于启动顺序，也不隐含依赖关系 - 正确做法是用
try-catch包裹整个等待循环，或更稳妥地用范围 for +joinable()检查：
for (auto& t : threads) {
if (t.joinable()) t.join();
}
C++20 推荐优先用 std::jthread 替代 std::thread
std::jthread 是 std::thread 的安全增强版，它在析构时自动调用 join()（只要可连接），彻底规避“忘记 join 导致 terminate”问题；还内置协作式取消机制。
迁移成本极低 —— 构造方式几乎一致，只是多了 stop_token 支持：
- 旧写法：
std::thread t([]{ /* work */ }); ... t.join(); - 新写法：
std::jthread t([](std::stop_token st){ while (!st.stop_requested()) { /* work */ } });—— 不用显式join()，离开作用域自动清理 - 注意：
jthread不能复制，只能移动；若需传递给其他函数，传右值引用或std::move(t)
真正容易被忽略的是：即使用了 jthread，你仍需确保线程函数内部定期检查 stop_requested()，否则取消请求永远不会生效 —— 它不是抢占式中断。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
