std::stop_callback未触发的主因是生命周期管理失败；其为RAII类型，析构即注销，若定义为局部变量（如lambda内）则线程函数返回即销毁，故需延长至与线程同生命周期，或改用轮询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、记录日志等——这些操作不适合塞进任务主循环里，也不该由任务自己检查 token 来驱动。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 适用：在回调里关掉子线程共用的
std::ofstream或std::shared_mutex - 不适用：试图在回调里做耗时 I/O、锁竞争、或等待其他线程 —— 回调不阻塞、不重入、不保证执行顺序，卡住会影响整个 stop 流程
- 注意：多个
std::stop_callback可绑定到同一个std::stop_token，但标准不保证执行顺序，别让它们互相依赖
和 std::jthread 配合时最容易踩的坑
std::jthread 自带 std::stop_source，但它的 std::stop_token 是线程私有的；你不能靠它自动通知外部资源，必须显式暴露或共享 std::stop_source。
立即学习“C++免费学习笔记（深入）”；
- 误以为
t.get_stop_token()能跨线程广播 —— 实际上它只反映本线程的停止请求，无法被其他线程直接监听 - 想让多个线程响应同一取消信号？得用外部
std::stop_source，再通过get_token()分发给各线程 -
std::jthread析构时会自动request_stop()+join()，但它的std::stop_callback必须在此之前已注册且未析构，否则白搭
真正难的不是写回调，而是确保它活得到被调用的那一刻，同时不干扰主线程逻辑节奏。稍不留神，回调就变成“注册了等于没注册”。
