std::stop_callback不触发的最常见原因是对象提前析构；它作为RAII类型，构造时注册、析构时注销，必须确保其生命周期覆盖从request_stop()调用到回调执行完毕的整个窗口。
std::stop_callback 不会自动取消任务，也不会让线程退出；它只在 request_stop() 被调用时执行一次回调函数——前提是这个对象还活着。
为什么 std::stop_callback 总是不触发？
最常见原因是对象提前析构：它是个 RAII 类型，构造即注册，析构即注销。一旦离开作用域（比如定义在 lambda 内、循环里或函数末尾），就彻底失效。
- 错误写法：
std::jthread t([](std::stop_token token) { std::stop_callback cb(token, []{}); });→cb是栈上局部变量，lambda 返回即销毁 - 错误写法：
auto token = source.get_token(); { std::stop_callback cb(token, []{}); } source.request_stop();→cb在}处已析构，request_stop()无回调可调 - 正确做法：把
std::stop_callback声明在和线程同生命周期的作用域，例如紧挨着std::jthread变量之后，或作为类成员
std::stop_callback 应该放在哪？生命周期怎么管？
它的生存期必须覆盖“取消请求发出”到“回调执行完毕”的整个窗口。标准没提供注册后持久驻留的机制，全靠你手动控制作用域。
- ✅ 推荐位置一：类成员变量，绑定到长期存活的对象（如
class TaskManager { std::stop_callback cb_; };） - ✅ 推荐位置二：函数作用域开头，与
std::jthread同级声明，且顺序必须是先声明cb，再启动线程 - ❌ 避免在 lambda 参数捕获列表中构造，也别在
while循环体内重复声明 - ⚠️ 若回调需访问外部对象（如
std::ofstream），务必值捕获或用std::shared_ptr，不能捕获栈变量引用
std::stop_callback 里能做什么、不能做什么？
它运行在调用 request_stop() 的线程上下文中（不一定是工作线程），因此必须轻量、无锁、不阻塞。
- ✅ 安全操作：设置
std::atomic标志、调用std::condition_variable::notify_one()、写 lock-free 日志缓冲区 - ❌ 危险操作：调用
close()、fsync()、std::mutex::lock()、std::this_thread::sleep_for()、等待其他线程结束 - ⚠️ 多个
std::stop_callback绑定到同一std::stop_token时，执行顺序不保证，不能互相依赖 - ⚠️ 回调不重入、不排队、执行完即失效；它不是事件循环，也不是钩子系统
和 std::jthread 配合时最容易忽略的坑
std::jthread 自带 std::stop_source，但它的 std::stop_token 是线程私有的，无法被外部直接监听或广播。
- 误以为
t.get_stop_token()能让其他线程响应取消 → 实际上它只反映本线程是否收到请求，不能跨线程传播 - 想统一通知多个线程？必须用外部
std::stop_source，再通过get_token()分发给各线程 -
std::jthread析构时自动request_stop()+join()，但如果std::stop_callback已提前析构，这次通知就静默丢失 - lambda 参数类型必须是
std::stop_token（或const std::stop_token&），否则std::jthread注入的是默认构造的空 token，stop_requested()永远返回false
真正难的不是写回调函数，而是确保它活得到 request_stop() 被调用的那一瞬间，同时不拖慢取消路径——多数场景下，直接轮询 token.stop_requested() 比注册回调更直白、更可控、更少出错。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
