std::stop_callback不会跨线程自动触发，仅响应绑定的std::stop_source::request_stop()；其是否执行90%取决于对象是否存活——RAII特性使其构造即注册、析构即注销，提前销毁则回调永不触发。
std::stop_callback 不会跨线程自动触发，它只响应自己绑定的 std::stop_source::request_stop() 调用；能否生效，90% 取决于 std::stop_callback 对象是否还活着，而不是你写了多少行回调逻辑。
为什么 std::stop_callback 注册了却完全不执行？
最常见原因是对象提前析构——std::stop_callback 是 RAII 类型，构造即注册，析构即注销。一旦销毁，后续 request_stop() 就找不到它了。
- 错误写法：
std::jthread t([](std::stop_token token) { std::stop_callback cb(token, []{}); });→cb是 lambda 局部变量，函数返回瞬间析构，回调永远不触发 - 正确位置：必须和线程同生命周期或更长，比如在
main()中先声明std::stop_callback，再启动std::jthread - 若在线程函数内必须用，应通过类成员或智能指针管理，避免栈上短命对象
- 捕获局部资源时，禁止引用栈变量（如
std::ofstream&），改用值捕获或std::shared_ptr
如何让多个线程响应同一个取消信号？
关键不是“传 token”，而是“共享 std::stop_source”。每个 std::jthread 自带的 stop_source 是隔离的，不能互相通知。
- 必须用外部统一的
std::stop_source，例如声明为static std::stop_source global_stop;或main()中的局部变量 - 所有线程都接收
global_stop.get_token()，而非t.get_stop_token() - 每个线程各自构造自己的
std::stop_callback实例（不能复用同一个对象） - 触发取消时，只调一次
global_stop.request_stop()，所有存活的回调将同步执行 -
std::stop_source的生存期必须严格长于所有依赖它的std::stop_callback
std::stop_callback 里能写什么、不能写什么？
它运行在 request_stop() 被调用的线程上下文中（可能是主线程、信号处理线程），不是工作线程本身。执行必须轻量、无锁、不阻塞。
- ✅ 安全操作：
close(fd)（裸文件描述符）、delete ptr（非托管内存）、done_flag.store(true, std::memory_order_relaxed)、cv.notify_one() - ❌ 禁止操作：
std::ofstream::close()（可能刷盘阻塞）、std::mutex::lock()（可能死锁）、write()/fsync()、等待其他线程、抛异常 - 回调不重入、不排队、执行完即失效；它不是事件循环，也不是钩子机制
- 多个回调绑定同一 token 时，执行顺序不保证，彼此不能有依赖（比如 A 解锁、B 加锁同一 mutex）
std::stop_callback 和轮询 stop_requested() 是什么关系？
std::stop_callback 是“通知器”，token.stop_requested() 才是“执行开关”。两者必须配合，缺一不可。
- 只注册回调但不轮询：任务主循环不会退出，线程卡住，资源无法释放
- 只轮询但不注册回调：取消时缺少即时清理入口，比如无法及时关闭共享 fd 或通知条件变量
- 轮询点要足够密：长循环中必须插
if (token.stop_requested()) break;；阻塞前必须检查，比如if (token.stop_requested()) return;再调sleep_for() - 不要指望
std::jthread析构自动触发有效回调——如果std::stop_callback已提前析构，request_stop()就静默失效
真正容易被忽略的是：回调对象的生存期管理比逻辑编写更关键；而回调里看似 innocuous 的一行 std::ofstream::close()，就足以让整个取消流程卡死在主线程里。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
