std::stop_callback未执行的主因是对象提前析构，因其RAII特性：构造时注册、析构时注销；必须确保其生命周期覆盖整个线程运行期，且回调应轻量、无锁、不阻塞。
std::stop_callback 注册了但完全不执行？不是代码写错了，而是它早就析构了。 它只在 request_stop() 调用那一刻、且对象仍存活时，在调用者线程中执行一次。绝大多数“没反应”问题，根源是生命周期管理失当，而非信号没发出去或 token 没传对。
为什么 std::stop_callback 在子线程里注册后根本不执行
最典型错误是把它塞进 std::jthread 启动 lambda 里：
std::jthread t([](std::stop_token token) {
std::stop_callback cb(token, []{ cleanup(); }); // ❌ 错！cb 是局部变量，lambda 返回即析构
});
std::stop_callback 是 RAII 类型：构造即注册，析构即注销。一旦作用域结束，回调就彻底失效，后续任何 request_stop() 都找不到它。
- 绝对不要在 lambda 内部、函数参数、循环体或任何可能提前返回的作用域中声明
std::stop_callback - 若捕获栈上局部对象（如
std::ofstream&），回调执行时访问的是悬垂引用，行为未定义 - 验证方式很简单：在回调里加日志输出；如果日志从不出现，优先检查生命周期，而不是怀疑
request_stop()是否被调用
如何让多个线程响应同一个取消信号
std::jthread 自带私有 std::stop_source，彼此完全隔离。t.get_stop_token() 返回的只是个只读快照，不监听变更——把它传给别的线程注册 std::stop_callback，等于监听一个永远不会变的假信号。
立即学习“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 的存活std::stop_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() - ⚠️ 它不抛异常、不改变线程状态、也不中断任务主逻辑——只是通知，不是中断
真正容易被忽略的是：回调执行时机不可控，且只发生一次；你无法靠它“等待资源释放完成”，也不能指望它替你做轮询退出。协作取消的本质，仍是工作线程主动检查 stop_token.stop_requested() 并在安全点退出。
