std::jthread 析构时自动 join() 并内置 stop_token 支持协作式中断；要求线程函数首参为 std::stop_token 才能自动注入，否则退化为自动 join，C++20 起可用且仅支持移动。

析构时自动调用 join()，不用再怕 std::terminate()

用 std::thread 时，只要对象析构前没调 join() 或 detach()，程序立刻调 std::terminate() —— 这不是报错，是直接崩，而且常发生在异常路径或提前 return 时，极难复现。

std::jthread 把这事包圆了：析构时自动 join()，等线程跑完才销毁自己。你写 std::jthread t(task);，哪怕中间抛异常、函数提前返回、或者就忘了写 t.join()，它都安全收尾。

• 不用手动加 try/catch 去保 join()
• RAII 真正落地：构造即启动，析构即等待
• 和 std::thread 接口几乎一致，迁移成本极低

带内置 std::stop_token，支持协作式中断

std::thread 没有标准中断机制，常见做法是自己搞个 std::atomic 标志位轮询，但无法通知线程“立刻停在某个安全点”，更没法注册清理回调。

std::jthread 构造时自带一个 std::stop_source，你可以用 t.get_stop_token() 获取对应 std::stop_token，还能通过 t.request_stop() 外部触发停止请求。

• 线程函数若接受 std::stop_token 为首个参数，jthread 会自动传入（无需手动提取）
• 必须在线程内部主动检查 stoken.stop_requested()，不能只靠外部调用 request_stop()
• 可注册 std::stop_callback 做资源清理，比如关闭文件、释放锁、取消 pending I/O

#include 
#include 
void worker(std::stop_token stoken) {
while (!stoken.stop_requested()) {
std::cout << "working...\n";
std::this_thread::sleep_for(100ms);
}
std::cout << "cleaning up and exit\n";
}
int main() {
std::jthread t(worker);
std::this_thread::sleep_for(300ms);
t.request_stop(); // 发出停止请求
// 析构时自动 join，无需再等
}

参数签名差异：能自动传递 stop_token，但必须显式声明

std::jthread 不会“偷偷”把 stop_token 塞进任意函数；它只在可调用对象**第一个参数类型是 std::stop_token** 时，才自动注入。其他参数照常传递。

• 写 [](std::stop_token stoken, int x) { ... } ✅ 可以
• 写 [](int x, std::stop_token stoken) { ... } ❌ 不会自动传，stoken 会是默认构造的空 token
• 不带 std::stop_token 参数？没问题，退化为普通自动 join 行为，和 std::thread + RAII 封装效果类似

兼容性与性能开销：C++20 起可用，轻量但不可忽略

std::jthread 是 C++20 新增类型，编译器需开启 -std=c++20（GCC/Clang）或 /std:c++20（MSVC）。它内部多持有一个 std::stop_source，内存开销约十几个字节，无锁设计，运行时检查 stop_requested() 是原子读，开销极小。

• 旧项目升级：只需替换 std::thread 为 std::jthread，并按需加 stop_token 参数
• 不能复制，只能移动 —— 和 std::thread 保持一致
• 没有 detach() 方法：设计上就不鼓励分离线程，强制你面对生命周期问题

真正容易被忽略的，是协作中断的“协作”二字：它不终止线程，只发信号；线程不检查 stop_token，就永远收不到——这不像信号处理，而是靠你写进循环条件、I/O 等待点、甚至 std::condition_variable::wait 的 predicate 里。漏掉一次检查，就可能卡住整个退出流程。