std::stop_callback不跨线程触发且不自动传播取消信号，仅响应本线程内共享的std::stop_source::request_stop()；其执行依赖正确生命周期管理，否则注册即失效。
std::stop_callback 本身不跨线程触发，也不会自动传播取消信号——它只响应本线程内关联的 std::stop_source::request_stop() 调用。想让多个线程协同响应同一取消请求，必须共享一个外部 std::stop_source，再各自用它的 get_token() 构造回调。
为什么 std::stop_callback 在子线程里注册后根本不执行？
最常见原因是对象生命周期太短，RAII 特性导致注册即失效。
- 错误写法：
std::jthread t([](std::stop_token token) { std::stop_callback cb(token, []{ cleanup(); }); });→cb是 lambda 内局部变量，函数返回即析构，后续request_stop()完全无回调可调 -
std::stop_callback构造时注册、析构时注销，它不“驻留”在线程内部，也不跨作用域存活 - 若回调捕获了栈上局部对象（如
std::ofstream&或std::mutex&），析构后访问就是悬垂引用，可能引发未定义行为 - 正确做法：把
std::stop_callback定义在和线程同生命周期的作用域，比如紧挨着std::jthread声明之后，或作为类成员变量
如何让多个线程响应同一个 SIGINT 或手动取消？
关键不是传 token，而是共享 std::stop_source 实例，并确保它活得比所有线程都久。
- 必须用外部
std::stop_source（不能是std::jthread自带的私有 source）：static std::stop_source global_stop;或在main()开头声明 - 信号处理函数中调用
global_stop.request_stop()—— 这是 async-signal-safe 的唯一安全方式 - 每个线程启动时接收
global_stop.get_token()，再用它构造自己的std::stop_callback，不能复用同一个 callback 实例 - 多个线程共用同一 token 时，
std::stop_callback执行顺序不保证，别让它们互相依赖（比如 A 回调 unlock mutex，B 回调 lock 同一 mutex）
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 阻塞）、等待其他线程结束 - 回调不重入、不排队、执行完即失效；它不是事件循环，也不是钩子机制
- 若需记录日志，用 lock-free 日志库或原子写入，避免在回调里触发同步 I/O
和 std::jthread 配合时最容易忽略的三个细节
看似简单，但错一个就静默失效。
- lambda 参数类型必须是
std::stop_token或const std::stop_token&，否则std::jthread注入的是默认构造的空 token，后续所有stop_requested()都返回 false - 构造顺序很重要：先声明
std::stop_callback，再启动std::jthread；反过来可能导致注册失败或提前析构 -
std::jthread析构时会自动request_stop()+join()，但如果此时std::stop_callback已析构，这次通知就彻底丢失——你看到的“线程没清理”其实是回调根本没跑
真正难的不是写回调函数，而是确保它活得到 request_stop() 被调用的那一瞬间，同时不拖慢整个取消路径。很多静默失效、崩溃、资源泄漏，根源都在生命周期管理被当成理所当然——而 C++20 的协作式取消模型，恰恰把这份责任交还给了程序员。
