std::stop_callback未触发的最常见原因是生命周期管理错误：回调对象提前析构，导致request_stop()调用已销毁对象而引发未定义行为。
std::stop_callback 不会自动停止线程，也不会撤回任务——它只在 request_stop() 被调用时执行一次函数，前提是对象还活着。
为什么注册了 std::stop_callback 却没触发？
最常见原因是生命周期管理错误：回调对象提前析构，导致后续 request_stop() 尝试调用已销毁对象，引发未定义行为（UB）。
- 错误写法：
std::jthread t([](std::stop_token token) { std::stop_callback cb(token, []{ cleanup(); }); /* cb 是局部变量，lambda 返回即销毁 */ }); -
std::stop_callback是 RAII 类型，构造即注册，析构即注销；它不“驻留”在线程内部，也不跨作用域存活 - 若回调捕获了栈上变量（如局部
std::ofstream或std::mutex引用），析构后访问就是悬垂引用 - 正确做法：把
std::stop_callback定义在和线程同生命周期的作用域，例如函数开头、类成员、或显式管理的std::stop_source之后
std::stop_callback 里能做什么？
它运行在调用 request_stop() 的线程上下文中，不是工作线程本身，因此必须轻量、无锁、不阻塞。
- ✅ 推荐操作：设置
std::atomic标志、调用std::condition_variable::notify_all()、发 lock-free 日志 - ❌ 禁止操作：
close()文件描述符、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已提前析构，这次通知就完全丢失 - 构造顺序很重要：先声明
std::stop_callback，再启动std::jthread，否则可能注册失败
真正难的不是写回调函数，而是确保它活得到 request_stop() 被调用的那一瞬间，同时不拖慢取消路径——多数场景下，直接轮询 token.stop_requested() 比注册回调更直白、更可控、更少出错。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
