std::stop_callback仅触发回调而不取消任务或中断线程，其生效前提是回调对象生命周期覆盖整个取消窗口且任务主动轮询stop_requested()。
std::stop_callback 本身不取消任务，也不中断线程执行——它只是在 request_stop() 被调用时，触发一次你指定的回调函数。真正决定“是否停、停在哪、怎么收尾”的，永远是你自己写的轮询逻辑和资源清理代码。
为什么注册了 std::stop_callback 却没反应？
最常见原因是：回调对象生命周期太短，注册后就析构了。
- 典型错误写法：
std::jthread t([](std::stop_token token) { std::stop_callback cb(token, []{ cleanup(); }); /* cb 是局部变量，lambda 返回即销毁 */ }); -
std::stop_callback必须存活到request_stop()实际发生之后；否则请求来了，回调早已注销，什么都不会执行 - 如果你在回调里只设了个
std::atomic<bool> cancelled{false}</bool>，但任务主体压根不检查它，那这个标志形同虚设 - 回调函数不抛异常、不阻塞、不重入，也不会自动让线程退出循环——它只是“通知一声”，仅此而已
std::stop_callback 应该放在哪？生命周期怎么管？
关键原则：它的生存期必须覆盖整个可能的取消窗口，从线程启动到明确结束（或被 request_stop）。
- ✅ 推荐做法：作为类成员变量，绑定到任务持有者生命周期（如
class TaskManager { std::stop_callback cb_; ... };） - ✅ 或定义在线程作用域外的局部变量（比如在
main()或启动函数中先构造cb，再传给std::jthread） - ❌ 避免在 lambda 内部、循环体内、或任何可能提前返回的作用域里声明
std::stop_callback - ⚠️ 注意捕获方式：若在回调中用到外部对象（如文件句柄），确保是值捕获或共享指针，而非悬垂引用
任务函数里不轮询 stop_requested() 就等于没取消机制
std::stop_callback 是“通知器”，token.stop_requested() 才是“执行开关”。两者必须配合使用。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 长循环必须拆解：不要写
for (int i = 0; i ，而要插检查点：<code>if (token.stop_requested()) return; - 阻塞调用前加判断：比如
if (token.stop_requested()) break;再调用read()或sleep_for() -
std::jthread自动处理sleep_for中的取消，但你自己写的忙等（while(!done);）不会响应 - 避免在回调里做耗时操作（如日志刷盘、网络请求），否则会拖慢整个取消流程，甚至导致
request_stop()后迟迟无法返回
什么时候干脆别用 std::stop_callback？
它不是必需品。多数简单场景下，直接轮询更清晰、更可控、更少出错。
- 如果你只需要做资源释放（如 close fd、delete buffer），直接在任务函数末尾统一处理即可，无需额外回调
- 若任务已封装为协程或 future-based 流程，
std::stop_callback很难自然嵌入其挂起/恢复时机，反而增加竞态风险 - 当需要“首胜恢复”（first-to-resume）或与
final_suspend协作时，std::stop_callback必须作为 awaiter 成员存在，否则容易引发双重 resume —— 这种复杂度，往往意味着该用原子状态机而不是裸回调
最容易被忽略的一点：std::stop_callback 的触发时机不可控——它可能在任意线程中执行（取决于谁调了 request_stop()），所以回调体必须是无锁、无竞争、无阻塞的。一旦它开始做锁操作或等待 I/O，整个取消链路就可能卡住。这不是设计缺陷，而是协作式取消的底层契约：通知要快，响应要由你定。
