std::jthread析构自动join()，但手动join()后析构会二次join导致崩溃；stop_token必须为函数首参才能生效；移动后原对象不可用且无operator==。
直接用 std::jthread 替代 std::thread，就能免去手动 join() 或 detach() 的所有麻烦——但前提是别在析构前又手动调用 join()，也别忽略 stop_token 的协作语义。
std::jthread 析构时自动 join()，但二次调用会崩溃
这是最常踩的坑：有人以为“自动 join 就是更安全的 thread”，结果写成：
std::jthread t{[] { std::this_thread::sleep_for(1s); }};
t.join(); // ❌ 错误！t 已经可 join，但调用后状态变为 not joinable
// 然后函数结束，t 析构 → 再次尝试 join → std::terminate()
正确做法是完全不碰 join()，除非你明确想提前等待：
- 默认行为：离开作用域时自动
join()，线程未结束就阻塞主线程 - 若需分离：显式调用
t.detach()（之后不能再join()，也不能再request_stop()） - 若需提前等：调用
t.join()一次，之后t.joinable()返回false，析构不再做任何事 - 异常安全：即使
do_work()抛异常，t析构仍会自动join()，不会泄漏线程
带 std::stop_token 的线程函数必须把 stop_token 放第一个参数
编译器靠参数位置自动绑定 stop_token，写错顺序或漏掉参数，request_stop() 就完全失效：
立即学习“C++免费学习笔记（深入）”；
// ✅ 正确：token 是第一个参数
std::jthread t([](std::stop_token token) {
while (!token.stop_requested()) {
do_work();
std::this_thread::sleep_for(10ms);
}
});
<p>// ❌ 错误：token 不是第一个，token 始终为 default-constructed，stop_requested() 永远 false
std::jthread t([](int i, std::stop_token token) { ... });</p><p>// ❌ 错误：没声明 token 参数，request_stop() 不起作用
std::jthread t([]{ /<em> no token </em>/ });
关键点：
-
stop_token是轻量、无锁、线程安全的，但不是同步原语——它不保护共享数据，也不唤醒阻塞调用 - 如果线程卡在
read()、wait()或无休止循环里，stop_requested()检查不到，join()就永远等下去 - 对可能阻塞的操作，优先用带超时的版本（如
cv.wait_until(lock, timeout, []{...})），并在超时分支里检查token.stop_requested()
std::jthread 移动后原对象不可再用，且不能比较相等
和 std::thread 一样，std::jthread 只能移动，不能复制。但移动后原对象的状态容易被误判：
std::jthread t1{[]{}};
std::jthread t2 = std::move(t1); // ✅ 合法
// 此时 t1.joinable() == false，t1.get_stop_token() 返回空 token
if (t1.joinable()) { /* 这个 if 永远不进 */ }
注意：
- 移动后
t1处于有效但“不关联线程”状态，可再次赋值，但不能join()或request_stop() -
operator==未定义，不能写t1 == t2；也不能放进std::vector<:jthread></:jthread>后用std::find查找 - 不要把
std::jthread成员变量设计成“可重置”的逻辑，比如在类里反复std::move新线程进来——容易遗漏request_stop()导致旧线程失控
真正难处理的从来不是语法，而是线程函数内部是否真能响应 stop_requested()；一个没检查 token 的死循环，会让 std::jthread 和 std::thread 一样卡死在 join() 上。
