std::jthread析构时自动调用join()是C++20标准强制行为，若线程joinable则必须隐式join，不可跳过；与std::thread析构时terminate形成根本对比，且detach()是唯一可关闭该机制的显式操作。
std::jthread析构时自动调用join()是标准强制行为
因为C++20标准明确规定：std::jthread的析构函数必须检查线程是否joinable()，若是，则隐式调用join()——这个动作不可跳过，也不依赖用户代码。它不是“建议”或“默认选项”，而是和std::vector析构时自动释放内存同等层级的语言保证。
对比std::thread：它的析构函数在joinable()为true时**必须**调用std::terminate()；而std::jthread的析构函数在相同条件下**必须**调用join()。这是设计上的根本翻转，不是语法糖。
手动调用join()反而会导致std::thread::join() on non-joinable错误
常见误操作是把std::jthread当std::thread用，在析构前又显式调用join()：
std::jthread t([]{ std::this_thread::sleep_for(1s); });
t.join(); // ⚠️ 错误！第一次join后t.joinable()变为false
// 此时t析构，再尝试隐式join → 报错：std::thread::join() on a thread that is not joinable
容易踩的坑包括：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 在异常路径中重复调用
join()（比如try/catch里写了t.join()，又忘了析构时还会再触发一次） - 把
std::jthread封装进类，又在析构函数里手动join()，造成双重join - 误以为“调用一次更保险”，结果破坏了自动管理契约
detach()会绕过自动join，但必须显式调用才生效
std::jthread的自动join只在未被detach()的前提下成立。一旦你调用了t.detach()，后续析构就不再join()，也不会std::terminate()——它变成“不负责等待”的状态，和std::thread::detach()语义一致。
关键点在于：detach()是唯一能关闭自动join机制的操作，且必须由你主动触发。没有“隐式detach”，也没有“析构时自动detach”。所以：
- 不调用
detach()→ 安全等待完成 - 调用了
detach()→ 你已接管生命周期责任，析构不干预 - 调用
request_stop()后仍不退出？那join()会阻塞，直到线程真正结束——这不是bug，是协作取消未被正确轮询的表现
stop_token参数位置错误会让协作取消失效
std::jthread内置std::stop_source，但线程函数**必须把std::stop_token作为第一个参数**，否则request_stop()发出去也没人接收：
std::jthread t([](std::stop_token st) { // ✅ 正确：首参是stop_token
while (!st.stop_requested()) {
do_work();
std::this_thread::sleep_for(10ms);
}
});
如果写成[](){...}或[](int x, std::stop_token st){...}，std::jthread构造时会忽略该token，request_stop()调用后线程继续运行，最终join()卡死。
这容易被忽略，因为编译不报错，运行也看似正常——直到你需要提前终止线程时才发现它根本不响应。
