std::stop_callback不跨线程触发，仅在request_stop()调用时同步执行一次且于调用线程中运行；其核心问题是生命周期管理——对象析构即注销，必须共享长生存期的std::stop_source并配合主动轮询stop_requested()。
std::stop_callback 不跨线程触发，也不会自动让工作线程退出——它只在 std::stop_source::request_stop() 被调用时，**同步执行一次你注册的回调函数，且执行上下文是调用 request_stop() 的那个线程**（可能是主线程、信号处理线程，而非工作线程本身）。想让多个线程响应同一取消请求，必须共享一个外部 std::stop_source，并严格管理 std::stop_callback 的生命周期。
为什么 std::stop_callback 注册了却根本不执行？
最常见原因不是写法错，而是对象提前析构。它构造即注册、析构即注销，没有“后台驻留”机制。
-
std::stop_callback定义在std::jthread启动 lambda 内部 → lambda 返回时立即销毁，后续request_stop()无回调可触发 - 把
std::jthread::get_stop_token()传给子线程注册回调 → 这个 token 只反映该线程自身的停止状态，无法被外部触发 - 回调捕获了栈上局部变量的引用（如
std::ofstream&或std::mutex&）→ 回调执行时对象已析构，访问即未定义行为 -
std::stop_source是局部变量（比如在某个函数里声明）→ 函数返回后 source 析构，所有绑定它的 token 自动变为 “stop_requested == true”，但回调已注销，清理逻辑不会运行
如何正确共享取消信号给多个线程？
关键不是“传 token”，而是“共用同一个 std::stop_source 实例”，且它必须活得比所有线程都久。
- 在全局或
main()开头声明static std::stop_source global_stop;（不能是栈局部变量） - 每个
std::jthread启动时，显式传入global_stop.get_token()，而不是用t.get_stop_token() - 每个线程内用收到的 token 构造自己的
std::stop_callback实例（不能复用同一个 callback 对象） - 触发取消时，只调一次
global_stop.request_stop()，所有存活的 callback 将按标准保证被调用
示例错误对比：
❌ 错误：各自独立 source<br>std::jthread t1([](std::stop_token t) { std::stop_callback cb(t, []{}); });<br>std::jthread t2([](std::stop_token t) { std::stop_callback cb(t, []{}); });<br>// t1.request_stop() 对 t2 完全无效
✅ 正确：统一 source<br>static std::stop_source g_stop;<br>std::jthread t1([&g_stop](std::stop_token t) { std::stop_callback cb(t, []{}); });<br>std::jthread t2([&g_stop](std::stop_token t) { std::stop_callback cb(t, []{}); });<br>g_stop.request_stop(); // 两个 cb 都会执行
std::stop_callback 里能写什么、不能写什么？
它运行在 request_stop() 调用方的线程上下文中，不是工作线程自身，所以必须轻量、无锁、不阻塞、不抛异常。
立即学习“C++免费学习笔记（深入）”；
- ✅ 安全操作：
done_flag.store(true, std::memory_order_relaxed)、cv.notify_one()、close(fd)（裸文件描述符）、delete ptr（非托管内存） - ❌ 禁止操作：
std::ofstream::close()（可能刷盘阻塞）、std::mutex::lock()（可能死锁）、write()或fsync()（I/O 阻塞）、等待其他线程结束 - ⚠️ 注意：多个 callback 绑定到同一 token 时，执行顺序不保证，彼此不能有依赖（比如 A 回调 unlock mutex，B 回调 lock 同一 mutex）
std::stop_callback 和 stop_requested() 必须配合使用
std::stop_callback 是“通知器”，token.stop_requested() 才是“执行开关”。光注册回调不轮询，任务根本不会退出。
- 长循环中必须插入检查点：
if (token.stop_requested()) break; - 阻塞调用前加判断：比如
if (token.stop_requested()) return;再调用read()或sleep_for() -
std::jthread自动支持sleep_for中断，但你自己写的忙等（while(!done);）不会响应 - 如果回调里只设了个
std::atomic<bool></bool>，但主循环完全不读它，那这个标志毫无意义
真正容易被忽略的点是：callback 生命周期和轮询逻辑是两套独立机制，缺一不可；很多人只管注册 callback，却忘了在工作线程里主动检查 stop_requested() —— 这就像装了警报器却不听响声。
