std::stop_callback未触发的最常见原因是对象生命周期过短；它是raii类型，构造时注册、析构时注销，若定义为局部变量则线程函数返回即销毁，应延长其作用域或改用轮询token.stop_requested()。
std::stop_callback 不会中断正在运行的代码，它只在 request_stop() 被调用时执行一次清理函数——前提是这个 std::stop_callback 对象还活着。
为什么注册了 std::stop_callback 却没触发
最常见原因是对象生命周期太短。它是个 RAII 类型，构造即注册、析构即注销。
- 错误写法：
std::jthread t([](std::stop_token token) { std::stop_callback cb(token, []{ /* cleanup */ }); });→cb是局部变量，线程函数返回就析构了 - 正确做法：把
std::stop_callback定义在和线程同生命周期的作用域，比如类成员、或std::jthread变量声明之后的同一作用域 - 更稳妥的选择：多数场景下直接轮询
token.stop_requested()，比注册回调更简单、更可控
std::stop_callback 适合干啥、不适合干啥
它真正有价值的地方，是响应“非工作线程”的停止信号，比如关共享 socket、写日志、释放全局资源——这些操作不适合塞进任务主循环里。
- 适合：在回调里调用
close()、unlock()、flush()等轻量且无阻塞的操作 - 不适合：做耗时 I/O（如
write()大文件）、等待锁、调用join()其他线程 —— 回调不重入、不阻塞、不保证顺序，卡住会影响整个 stop 流程 - 多个
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必须在此之前已注册且未析构，否则白搭
真正难的不是写回调，而是确保它活得到被调用的那一刻，同时不干扰主线程逻辑节奏。很多崩溃和静默失效，都出在“以为注册了就万事大吉”，却忽略了作用域和所有权。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
