std::stop_callback不会自动跨线程生效，仅在request_stop()调用时于该线程中执行一次，且要求实例持续存活；常见失效原因是局部变量析构过早或误用jthread私有stop_source。
std::stop_callback 不会自动跨线程生效，它只在 request_stop() 被调用的那一刻、且对象仍存活的前提下，在调用者线程中执行一次回调。注册了却没反应？八成是 std::stop_callback 实例提前析构，或者你误用了 std::jthread 自带的私有 stop_source。
为什么 std::stop_callback 在子线程里注册后根本不执行
最常见错误是把它定义在 lambda 内部：
std::jthread t([](std::stop_token token) {
std::stop_callback cb(token, []{ cleanup(); }); // ❌ 错！cb 是局部变量，lambda 返回即析构
});
因为 std::stop_callback 是 RAII 类型：构造即注册，析构即注销。一旦作用域结束，回调就彻底失效，后续任何 request_stop() 都找不到它。
- 不要在
std::jthread启动 lambda 内声明std::stop_callback - 不要把它作为函数参数或循环体内变量
- 若捕获栈上局部对象（如
std::ofstream&），回调执行时访问的是悬垂引用，行为未定义 - 正确做法：和
std::jthread变量同级声明，或作为类成员变量
如何让多个线程响应同一个取消信号
每个 std::jthread 自带独立的 std::stop_source，彼此完全隔离。靠 t.get_stop_token() 传给别的线程是无效的——那只是个只读快照，不监听变更。
立即学习“C++免费学习笔记（深入）”；
- 必须使用外部统一的
std::stop_source，例如static std::stop_source g_stop;或全局/类静态变量 -
std::stop_source的生命周期必须比所有使用它的线程更长，不能是栈局部变量 - 各线程启动时接收
g_stop.get_token()，并各自用它构造自己的std::stop_callback - 触发取消时只调一次
g_stop.request_stop()，所有绑定该 token 的存活 callback 都会被同步执行
std::stop_callback 回调里能写什么、不能写什么
它运行在调用 request_stop() 的线程上下文中（可能是主线程、信号处理线程），不是工作线程本身。因此必须轻量、无锁、不阻塞、不重入。
- ✅ 推荐操作：
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 阻塞）、std::this_thread::sleep_for() - ⚠️ 它不抛异常、不改变线程状态、也不中断任务主逻辑 —— 只是“通知”，不是“指令”
std::stop_callback 和 stop_requested() 必须配合使用
std::stop_callback 本身不取消任务，也不中断线程。真正决定“是否停、停在哪、怎么收尾”的，是你自己写的轮询逻辑。
- 长循环里必须插入检查点：
if (token.stop_requested()) break; - 阻塞调用前加判断，比如
if (token.stop_requested()) return;再调用read() - 如果只在回调里设了个
std::atomic<bool></bool>标志，但任务主体压根不检查它，那这个标志形同虚设 -
std::jthread对std::this_thread::sleep_for()有内建取消支持，但你自己写的忙等（while(!done);）不会响应
最关键的复杂点在于：std::stop_callback 的生命周期管理没有编译器提示，出错时既不报错也不警告，只会静默失效。最容易被忽略的是——你写了回调，也传了 token，但忘了它必须活到 request_stop() 发生之后；而那个“之后”，往往发生在你 main 函数退出前、信号到达时、或用户点击关闭按钮的任意时刻。
