std::stop_callback不跨线程触发，因其执行时机和线程归属由构造时的stop_token决定，而token仅反映关联stop_source是否被请求停止，本身不监听其他线程；正确做法是共享同一外部stop_source并分发其token给各线程。
std::stop_callback 本身不跨线程传递取消信号，它只响应本线程的调用；想让多个线程协同响应同一取消请求，必须共享一个，再各自绑定回调。
std::stop_callback 为什么不会自动跨线程触发
它的执行时机和线程归属由构造时的
决定，而该 token 只反映其关联的
是否被请求停止——但 token 本身不“监听”其他线程。常见误解是把
传给别的线程，以为能监听主线程的停止状态，其实它只是个只读快照，无法接收后续变更。
错误表现：
子线程注册了
，但主线程调
后回调没执行
多个线程共用同一个
（比如从
拿的），却期望它们都能响应外部取消
根本原因：每个
自带独立的
，彼此隔离。
立即学习
“
C++免费学习笔记（深入）
”；
正确共享取消信号的写法：用外部
要让 A 线程发号、B/C/D 线程同时响应，就得把控制权上收一级——由外部创建统一的
，再分发 token 给各线程：
C函数速查手册（CHM版）
C函数速查手册（CHM版）
下载
关键点：
必须比所有使用它的线程活得更久（不能是局部变量）
每个线程的
都得绑定自己收到的 token，不能复用同一个 callback 实例
回调函数里避免耗时操作（如
、锁竞争），否则会拖慢整个取消流程
std::stop_callback 生命周期失效的典型场景
最常踩的坑不是逻辑写错，而是对象提前析构——RAII 特性让它“生即注册、死即注销”，一旦销毁就彻底失联：
在 lambda 参数列表里定义
→ lambda 返回即销毁
作为函数内局部变量声明，但线程还在跑，函数已退出
作为类成员，但所属对象在
前就被
或离开作用域
稳妥做法：
把
定义在
变量之后的同一作用域（保证同生命周期）
在类中作为成员变量，并确保类实例存活到取消完成
或者干脆不用它——多数任务只需在循环里轮询
，更直白、无生命周期负担
回调里能做什么、不能做什么
它不是“中断钩子”，而是一个**单次、轻量、不可重入的通知入口**：
✅ 适合：设置原子标志（
）、释放非阻塞资源（如
）、记录日志、关闭非共享句柄
❌ 禁止：调用
或
、写文件、加全局锁、等待其他线程、递归触发 resume（协程场景下易栈溢出）
⚠️ 注意：多个回调绑定同一 token 时，执行顺序不确定，别让它们互相依赖或竞争同一资源
真正难的从来不是写那几行回调代码，而是让这个对象活得到被调用的那一刻，又不干扰主线程节奏——稍一疏忽，它就静默失效，连 crash 都不给你机会。
request_stop()std::stop_sourcestd::stop_tokenstd::stop_sourcestd::jthread::get_stop_token()std::stop_callbackt.request_stop()std::stop_tokenstd::jthreadstd::jthreadstd::stop_sourcestd::stop_sourcestd::stop_sourcestd::stop_source global_stop;
std::jthread t1([&global_stop](std::stop_token token) {
std::stop_callback cb(token, []{ / cleanup in t1 / });
while (!token.stop_requested()) { / work / }
});
std::jthread t2([&global_stop](std::stop_token token) {
std::stop_callback cb(token, []{ / cleanup in t2 / });
while (!token.stop_requested()) { / work / }
});
// 主动触发所有线程
global_stop.request_stop(); // ✅ 这才是跨线程协作的起点
std::stop_sourcestd::stop_callbackstd::ofstream::close()std::stop_callback cb(token, ...)request_stop()deletestd::stop_callbackstd::jthreadtoken.stop_requested()std::atomicstd::shared_mutex::unlock()join()wait()