std::stop_callback 不能撤回正在运行的任务，因为它仅在 request_stop() 被调用时触发一次回调，不中断执行、不改变线程状态、不抛异常；真正响应停止需任务代码主动轮询 stop_requested() 或检查共享标志。
std::stop_callback 为什么不能“撤回”正在运行的任务
它根本不是用来中断执行中的函数的，而是通知“有人想停了”，具体怎么停、停不停、停到哪一步，全靠你自己在回调里写逻辑。常见错误是以为注册了 std::stop_callback 就能自动终止线程或取消 std::jthread 的函数体——其实它连线程都不碰，只负责在 request_stop() 被调用时触发一次回调。
典型误用场景：在回调里设个 bool cancelled 标志，但任务主体压根不检查这个标志，结果“撤回”完全没反应。
- 回调本身不阻塞、不等待、不重入，注册后最多执行一次
- 它不改变线程状态，也不抛异常，更不会暂停当前指令流
- 真正起作用的前提是：任务代码主动轮询
std::stop_token::stop_requested()或响应你设的共享标志
怎么让异步任务“立即响应” stop 请求
关键不在 std::stop_callback，而在任务函数内部的协作式检查点。所谓“立即”，其实是把检查频率拉高、把阻塞点变短、把长循环拆成可中断的小段。
比如你在做文件分块上传，别写一个 for (int i = 0; i 干到底；改成每传 10 块就查一次 <code>token.stop_requested()。
立即学习“C++免费学习笔记（深入）”；
- 在可能耗时的操作前插入
if (token.stop_requested()) return; - 用
std::this_thread::sleep_for()替代死等，睡眠期间也能响应 stop（std::jthread自动处理） - 避免在回调里做耗时操作（如 I/O、锁竞争），否则会拖慢整个 stop 流程
- 如果任务封装在 lambda 里，确保捕获的
std::stop_token是有效的（别捕获已析构对象的引用）
std::stop_callback 的典型误配：和 std::jthread 构造顺序搞反
很多人这样写：
std::jthread t([](std::stop_token token) {
std::stop_callback cb(token, []{ /* ... */ }); // ❌ 危险！
while (!token.stop_requested()) { /* work */ }
});
问题在于：cb 是局部变量，函数返回时就析构了，而 std::stop_callback 的生命周期必须覆盖到 stop 请求发生之后。一旦 t 还没结束你就调 t.request_stop()，回调可能早已失效。
- 正确做法是把
std::stop_callback定义在和线程同生命周期的作用域，比如作为类成员或std::jthread外部的局部变量 - 或者干脆不用它——多数情况直接在任务函数里轮询
token.stop_requested()更直白、更可控 -
std::stop_callback真正适合的场景是：需要在任意线程（包括非工作线程）中响应停止信号，比如清理全局资源、发日志、关 socket
std::stop_token::stop_requested() 的性能和线程安全
它是无锁、轻量、线程安全的，每次调用开销极小，可以放心高频检查。但要注意：它只反映“是否被请求过停止”，不保证后续是否还会被再次请求（不过 std::stop_source 只能 request 一次，所以实际就是布尔值）。
- 不要缓存它的返回值长期使用，尤其在循环中——必须每次重新调用
- 它和
std::atomic<bool></bool>性能接近，但语义更清晰，且与std::jthread生态原生对齐 - 跨线程读写没问题，但别把它当成通用通信机制；它专为“协作式取消”设计，不是消息队列
最常被忽略的一点：即使你把所有检查点都加好了，如果任务正在系统调用里（比如 read() 阻塞在管道上），stop_requested() 仍会返回 false，直到系统调用返回。这时候得配合 signalfd、超时参数或 eventfd 等机制来破除阻塞——C++20 的停止机制管不到内核态。
