std::stop_callback仅在request_stop()调用时于发起线程中执行一次，不跨线程触发；需共享同一std::stop_source实例并严格管理其生命周期，且任务主循环必须轮询token.stop_requested()。
std::stop_callback 本身不跨线程触发，也不会自动让子线程响应主线程的 request_stop() —— 它只在你调用 request_stop() 的那一刻、且对象仍存活时，在调用方线程中执行一次回调。 想让多个线程协同退出，关键不是“注册一个 callback”，而是共享同一个 std::stop_source 实例，并严格管理每个 std::stop_callback 的生命周期。
为什么 std::stop_callback 在子线程里注册后根本不执行
最常见原因是对象提前析构：它构造即注册、析构即注销，不是“驻留”在线程里的后台服务。
- 错误写法：
std::jthread t([](std::stop_token token) { std::stop_callback cb(token, []{}); });→cb是 lambda 内局部变量，lambda 返回即销毁，后续request_stop()完全无回调可执行 - 若回调捕获了栈上局部对象（如
std::ofstream&或std::mutex&），而该对象已析构，访问就是悬垂引用，行为未定义 - 误用
std::jthread自带的 token：比如传t.get_stop_token()给外部std::stop_callback，但该 token 只反映本线程是否被请求停止，无法被其他线程触发 - 根本没调
request_stop()，只是设了个自定义 flag ——std::stop_callback只响应std::stop_source::request_stop()
必须用外部统一 std::stop_source 分发 token
每个 std::jthread 自带独立 std::stop_source，彼此隔离。跨线程协作的前提是所有线程监听同一个源头。
-
std::stop_source必须声明为全局、static，或至少比所有使用它的线程活得更久；不能是函数局部变量 - 各线程启动时，接收该 source 的
get_token()结果（值传递），而非捕获局部变量或复用t.get_stop_token() - 每个线程都需用自己的 token 构造独立的
std::stop_callback实例；不能复用同一 callback 对象 - 信号处理函数中调用
global_stop.request_stop()是 async-signal-safe 的，这是安全起点
std::stop_callback 里只能做轻量无阻塞操作
它运行在调用 request_stop() 的线程上下文中（可能是主线程、信号处理线程），不是工作线程自身，因此必须极快返回。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- ✅ 安全操作：
close(fd)（裸 fd）、delete ptr（非托管内存）、done_flag.store(true, std::memory_order_relaxed)、cv.notify_one() - ❌ 禁止操作：
std::ofstream::close()（可能刷盘阻塞）、std::mutex::lock()（可能死锁）、write()或fsync()（I/O 阻塞）、等待其他线程结束 - 多个绑定同一 token 的 callback 执行顺序不保证，不能互相依赖（比如 A 回调 unlock mutex，B 回调 lock 同一 mutex）
- 回调不重入、不排队、执行完即失效；它不是事件循环，也不是钩子机制
任务主循环中必须轮询 stop_requested()
std::stop_callback 是“通知器”，token.stop_requested() 才是“执行开关”。两者必须配合使用。
- 长循环必须插入检查点：
if (token.stop_requested()) break;，不能只靠 callback 通知就认为任务会自动停 - 阻塞调用前加判断：比如
if (token.stop_requested()) return;再调用read()或sleep_for() -
std::jthread自动处理sleep_for()中的取消，但你自己写的忙等（while(!done);）不会响应 - 若回调里只设了个
std::atomic<bool> cancelled{false}</bool>，但任务主体压根不检查它，那这个标志形同虚设
真正容易被忽略的是：callback 生存期和轮询点的双重保障缺一不可。很多人花时间调试 callback 不触发，最后发现是它早在 request_stop() 前就析构了，或者任务根本没检查 token —— 这两个地方一错，协作取消就彻底失效。
