std::stop_callback在子线程中收不到主线程request_stop()，因其仅响应构造时绑定的token所属线程的取消请求；需共享外部std::stop_source的token才能实现跨线程协同取消。
std::stop_callback 本身不跨线程触发取消，它只响应构造时绑定的 std::stop_token 所属线程的 request_stop() 调用；想让多个线程协同响应同一取消信号，必须共享一个外部 std::stop_source，再各自用其 get_token() 构造回调。
为什么 std::stop_callback 在子线程里注册却收不到主线程的 request_stop()？
常见错误是误把 std::jthread::get_stop_token() 传给其他线程，以为能“监听”主线程状态。实际上每个 std::jthread 自带独立的 std::stop_source，彼此隔离；它的 std::stop_token 只是一个只读快照，不会随外部调用而更新。
典型失效现象：
- 主线程调
t1.request_stop()，但子线程注册的std::stop_callback完全没执行 - 多个线程共用同一个从
std::jthread拿到的 token，却期望都能响应全局退出 - 回调函数被定义在 lambda 参数内部，lambda 返回即析构，
request_stop()发生时对象已不存在
如何正确实现跨线程统一取消信号广播？
关键在于上收控制权：用一个外部、长生命周期的 std::stop_source 作为唯一信源，显式分发其 std::stop_token 给各线程。
实操要点：
-
std::stop_source必须是 static、全局或类静态成员——不能是局部变量，否则可能早于线程销毁 - 每个线程的
std::stop_callback都要绑定自己收到的 token（不是复用同一个 callback 实例） - 回调函数内避免耗时操作：如
std::ofstream::close()、锁竞争、std::this_thread::sleep_for()，否则会阻塞整个取消流程 - 若需响应系统信号（如
SIGINT），可在 signal handler 中安全调用g_stop_source.request_stop()（std::stop_source::request_stop()是 async-signal-safe）
std::stop_callback 生命周期失效的典型场景
最常踩的坑不是逻辑写错，而是对象提前析构——RAII 特性让它“生即注册、死即注销”，一旦离开作用域就彻底失联。
错误写法示例：
std::jthread t([](std::stop_token token) {
std::stop_callback cb(token, []{ /* cleanup */ }); // ❌ 局部变量，lambda 返回即销毁
while (!token.stop_requested()) { /* work */ }
});
正确做法包括：
- 将
std::stop_callback声明在std::jthread变量之后、同一作用域内（如函数开头） - 作为类成员变量持有，绑定到任务管理器等长期对象的生命周期
- 用
std::shared_ptr<:stop_callback></:stop_callback>显式延长生命周期（需注意线程安全）
什么时候干脆别用 std::stop_callback？
它不是必需品。多数简单场景下，直接轮询 token.stop_requested() 更清晰、更可控、更少出错。
适合用 std::stop_callback 的场合仅限于：
- 需要在“非工作线程上下文”中执行清理，比如关闭跨线程共享的
std::ofstream、释放std::shared_mutex、记录日志 - 回调动作轻量、无锁、不阻塞、不依赖其他线程状态
不适合的场合包括：
- 任务主循环逻辑本身——该由轮询驱动，而非依赖回调通知
- 需要精确顺序或互相依赖的多个清理动作——标准不保证多个
std::stop_callback的执行顺序 - 回调里访问悬垂引用（如捕获了已析构栈对象的引用）
真正难的不是写回调函数，而是确保它活得到 request_stop() 被调用的那一瞬间，同时不拖慢取消路径——这点极易被忽略，且调试困难。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
