std::stop_callback不跨线程触发，仅在request_stop()调用时于调用者线程中执行一次；最常见失效原因是对象提前析构，因其为RAII类型，构造注册、析构注销。
std::stop_callback 本身不跨线程触发，也不会自动让其他线程停止 —— 它只在 request_stop() 被调用的那一刻、且对象仍存活的前提下，在调用者的线程上下文中执行一次回调。
为什么 std::stop_callback 注册了却完全不触发
最常见原因是对象提前析构：它是个 RAII 类型，构造即注册，析构即注销。一旦离开作用域（比如定义在 lambda 参数里、循环体内或函数局部），就立刻失效。
- 错误写法：
std::jthread t([](std::stop_token token) { std::stop_callback cb(token, []{ cleanup(); }); });→cb是栈上局部变量，lambda 返回即销毁 - 正确做法：把
std::stop_callback声明在和线程同生命周期的作用域，例如紧挨着std::jthread变量之后，或作为类成员 - 若捕获外部资源（如
std::ofstream），必须值捕获或用std::shared_ptr，不能引用栈变量，否则回调执行时访问的是悬垂内存
如何让多个线程响应同一个取消信号
每个 std::jthread 自带独立的 std::stop_source，彼此隔离；靠 t.get_stop_token() 传给别的线程是无效的 —— 那只是个只读快照，不监听变更。
- 必须使用外部统一的
std::stop_source，例如static std::stop_source g_stop;或全局/单例持有 - 各线程通过
g_stop.get_token()获取 token，并各自绑定自己的std::stop_callback -
std::stop_source的生命周期必须比所有使用它的线程更长，不能是局部变量（否则析构后request_stop()行为未定义） - 多个
std::stop_callback可绑定同一 token，但标准不保证执行顺序，别让它们互相依赖
std::stop_callback 里能做什么、不能做什么
它运行在调用 request_stop() 的线程上下文中（不一定是工作线程），因此必须轻量、无锁、不阻塞、不重入。
- ✅ 推荐操作：设置
std::atomic标志、调用std::condition_variable::notify_one()、关闭裸文件描述符（close(fd)）、释放裸指针（delete ptr） - ❌ 禁止操作：阻塞 I/O（
write()、fsync()）、锁竞争（std::mutex::lock()）、睡眠（std::this_thread::sleep_for()）、等待其他线程结束 - ⚠️ 回调函数不抛异常、不改变线程状态、也不中断任务主逻辑 —— 它只是“通知”，不是“指令”
轮询 stop_requested() 比注册回调更可靠吗
多数场景下是的。因为 std::stop_callback 的核心难点不在逻辑，而在生命周期管理；而 token.stop_requested() 是纯函数调用，无析构风险，语义清晰，且天然适配中断点插入。
- 在长循环头部、每次迭代开始处检查
if (token.stop_requested()) return; - 在可能阻塞的操作（
read()、sleep_for()、网络收发）前加判断 - 对耗时操作分片处理，例如每处理 100 个数据项后查一次 token
- 注意：仅靠回调不轮询 = 任务永远不会真正退出；两者必须配合 —— 回调做跨线程清理，轮询做本线程退出
真正容易被忽略的，不是怎么写回调函数，而是谁来管它的寿命、在哪声明、由谁析构。很多静默失效，都发生在 request_stop() 调用前，std::stop_callback 已经悄悄析构了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
