std::jthread 更适合可中断场景，因其内置协作式取消机制：构造时自动关联 std::stop_source，析构时自动 request_stop()；join()/detach() 也隐式触发停止，且强制线程函数首参为 std::stop_token，提升安全性与易用性。
std::jthread 为什么比 std::thread 更适合可中断场景
因为 std::jthread 内置了协作式取消机制，构造时自动关联 std::stop_source，析构时自动调用 request_stop() —— 这意味着你不用手动管理停止令牌的生命周期，也不会因忘记调用而卡住线程。
而裸用 std::thread + std::stop_token 需要自己创建 std::stop_source、传递 stop_token、显式检查和响应，出错概率高得多。
- 使用
std::jthread后，线程函数第一个参数必须是std::stop_token（否则编译失败） -
std::jthread的join()和detach()都会隐式调用request_stop()，确保资源清理 - 若线程函数中未使用该 token，编译器不会报错，但取消将完全失效 —— 这是常见盲点
如何在循环中正确响应 stop_token
不能只靠 token.stop_requested() 轮询判断，必须配合 token.stop_callback() 或主动调用 token.wait() 来实现低开销等待；否则空转消耗 CPU，且无法及时响应。
尤其在等待 I/O 或 sleep 场景下，应优先用支持 std::stop_token 的阻塞函数（如 std::this_thread::sleep_for 的重载版本），而非自己写 while 循环。
立即学习“C++免费学习笔记（深入）”；
-
std::this_thread::sleep_for(100ms, token)：带 token 的重载，被请求停止时立即返回false -
token.stop_callback([]{ /* 清理逻辑 */ });：注册回调，但仅触发一次，且不保证在目标线程上下文执行 - 避免
while (!token.stop_requested()) { /* work */ }：无休眠轮询，浪费资源
std::stop_token 不支持强制终止，这是设计使然
std::stop_token 是纯协作式机制 —— 它只通知“请尽快退出”，不提供挂起、抢占或 kill 接口。C++ 标准明确禁止强制终止线程（如 POSIX pthread_cancel），因为会破坏对象析构、锁状态和内存一致性。
这意味着：如果你的线程卡在系统调用（如 read()、accept()）或第三方库阻塞函数中，且该函数不接受 std::stop_token，你就必须改用非阻塞 I/O、超时接口，或借助平台特定机制（如向 socket 发送 dummy 数据唤醒）。
- 标准库中只有少数函数支持
std::stop_token：如std::this_thread::sleep_for、std::condition_variable::wait等 -
std::mutex::lock()、std::future::wait()等仍不支持，需自行封装超时+轮询逻辑 - 不要试图用
std::atomic<bool></bool>替代std::stop_token：它无法与std::jthread生命周期联动，也无法触发回调或 wait 语义
一个最小但完整的可中断线程示例
下面是一个带日志、支持提前退出、自动清理的 std::jthread 示例。注意其对 stop_token 的使用位置和返回逻辑：
#include <thread>
#include <chrono>
#include <iostream>
<p>void worker(std::stop_token token) {
int i = 0;
while (!token.stop_requested()) {
std::cout << "Working... " << i++ << "\n";
if (std::this_thread::sleep_for(500ms, token) == std::cv_status::no_timeout) {
// 正常休眠完成
} else {
// 被 stop 请求中断，立刻退出
std::cout << "Stop requested, exiting.\n";
return;
}
}
}</p><p>int main() {
std::jthread t{worker};
std::this_thread::sleep_for(1200ms);
// t 析构时自动 request_stop() 并 join()
}</p>关键点：sleep_for 的返回值判断决定了是否继续循环；没有手动调用 request_stop()，靠析构触发；所有资源由 std::jthread 自动管理。
真正难的不是写这个例子，而是把 stop_token 深度嵌入到真实业务逻辑里——比如网络请求重试、文件解析分块、图形渲染帧循环。这些地方一旦漏掉检查，整个取消链就断了。
