std::stop_callback未执行的最常见原因是对象生命周期过短；它是RAII类型，构造时注册、析构时注销，若为栈上局部变量则在线程函数退出时立即销毁，无法响应后续request_stop()。
注册了 std::stop_callback 却没执行？大概率是它早就析构了，不是没触发，是根本没活到被触发那一刻。
为什么 std::stop_callback 没调用
最常见原因：对象生命周期太短。它是个 RAII 类型，构造即注册，析构即注销——和 std::mutex_guard 一个逻辑，但后果更隐蔽。
- 错误写法：
std::jthread t([](std::stop_token token) { std::stop_callback cb(token, []{ /* cleanup */ }); });→cb是栈上局部变量，线程函数一退出就销毁，后续调t.request_stop()它已不存在 -
std::stop_callback必须比request_stop()调用早创建、晚销毁；若它在主线程中定义，但std::jthread析构后才轮到它析构，那它能撑到回调执行完 - 别依赖 lambda 捕获的
std::stop_token—— 若捕获的是临时对象或已移动走的 token，回调注册时可能传入空 token，导致静默失效
什么时候该用 std::stop_callback，而不是轮询
它不是用来替代轮询的，而是补轮询做不到的事：在“非工作线程”里做跨线程资源清理。
- 适合场景：关闭所有线程共用的
std::ofstream、释放全局std::shared_mutex、记录终止日志、通知第三方库 shutdown - 不适合场景：在回调里调
read()、write()、std::mutex::lock()—— 这些操作不响应 stop，且卡住会拖慢整个停止流程 - 多个
std::stop_callback绑定到同一std::stop_token时，标准不保证执行顺序，别让它们互锁或依赖彼此状态
和 std::jthread 配合的典型陷阱
std::jthread 自带 std::stop_source，但它的 std::stop_token 是线程私有的；你不能靠它自动广播信号给外部资源。
立即学习“C++免费学习笔记（深入）”；
- 误以为
t.get_stop_token()可被其他线程监听 —— 实际上它只反映本线程是否收到request_stop()，无法被外部等待 - 想让子线程 + 主线程统一响应？得用外部
std::stop_source ss，再把ss.get_token()分发给各线程，包括std::jthread的参数 -
std::jthread析构时自动request_stop()+join()，但如果你的std::stop_callback是在析构后才定义（比如写在t声明之后但作用域内靠后），它可能根本没来得及注册就结束了
真正难的不是写回调函数，是让它活过那个 request_stop() 调用的瞬间——而这个瞬间往往发生在你完全没预料到的异常路径、超时分支或提前返回里。
