jthread不能直接替换std::thread，因其内置停止令牌机制需线程函数显式接收并检查std::stop_token，否则request_stop()无效且析构可能卡死。
为什么 jthread 不能直接替换 std::thread
因为 jthread 不只是“带自动 join 的 thread”，它还绑定了停止令牌（std::stop_token）和停止源（std::stop_source），默认构造时就自带可协作中断能力。直接把 std::thread 改成 jthread，但函数里完全不查 stop_token，那中断逻辑就形同虚设——看起来能编译，运行时却无法响应 request_stop()。
常见错误现象：jthread 对象析构时卡死，或调用 request_stop() 后线程毫无反应。
- 必须显式接收
std::stop_token参数（通常作为第一个参数） - 线程函数内部需定期检查
token.stop_requested()或用token.wait() - 不能在 lambda 捕获列表里隐式传入 token；必须通过函数签名传递
jthread 启动时怎么传参给线程函数
和 std::thread 一样支持可变参数转发，但要注意：如果线程函数需要 std::stop_token，它必须是第一个参数，且不能被移动走（比如被 std::move 进 lambda 捕获）。
使用场景：启动一个可安全取消的后台任务，比如轮询、超时等待、资源清理。
立即学习“C++免费学习笔记（深入）”；
- 正确写法：
jthread t{[](std::stop_token stoken) { while (!stoken.stop_requested()) { /* work */ } }}; - 错误写法：
jthread t{[stoken = std::stop_token{}]() { ... }};—— 捕获的 token 是空的，不是线程绑定的那个 - 传额外参数：用逗号分隔，
stop_token仍占首位，例如jthread t{[](std::stop_token s, int x, const std::string& y) { ... }, 42, "hello"};
什么时候该用 jthread::request_stop() 而不是 join()
request_stop() 是协作式中断信号，不强制终止线程；join() 是阻塞等待结束。两者目的不同，不能互相替代。
性能影响：request_stop() 几乎零开销，但只有线程函数主动配合才能生效；盲目 join() 可能导致死锁（比如线程在等某个条件，而条件永远不满足）。
- 必须调用
request_stop()再join()，否则析构时会隐式调用join()，可能卡住 - 如果线程函数里没检查 token，
request_stop()就只是设了个标志位，线程继续跑 - 对纯计算型无休眠循环，务必插入
stoken.stop_requested()检查点，否则无法及时退出
Windows / GCC / Clang 对 std::jthread 的支持现状
C++20 标准已定义 std::jthread，但实际可用性取决于标准库实现，不是编译器版本决定的。
兼容性影响：MSVC 19.30+（VS 2022 17.0）、libstdc++ 12+（GCC 12）、libc++ 15+（Clang 15）才提供完整实现。旧版本即使开了 -std=c++20 也会报错 ‘jthread’ is not a member of ‘std’。
- 检查方法：
#include <thread>后加static_assert(__cpp_lib_jthread >= 201911L); - GCC 11 及更早：没有
jthread，只能手写带stop_source的封装 - 别依赖 IDE 的语法高亮——它可能误判支持，实际编译失败
协作中断不是银弹，真正难的是设计线程函数的退出路径：sleep 怎么中断、IO 怎么取消、锁怎么释放。这些细节不处理好，jthread 就只是个更贵的 std::thread。
