std::stop_callback 是绑定到 std::stop_token 的回调对象，仅在关联的 std::stop_source 调用 request_stop() 且该 token 仍有效时执行；适用于异步任务中配合 std::jthread 进行线程安全的清理。
std::stop_callback 是什么，它在什么场景下才真正生效
std::stop_callback 不是“注册后就自动触发”的清理钩子，它只在关联的 std::stop_source 被显式调用 request_stop() 且当前线程/协程仍在监听该停止令牌（std::stop_token）时才执行。常见误解是把它当成类似 atexit 的全局终结器——它不是。它绑定到某个具体 std::stop_token 实例的生命周期，且仅在该 token 处于“可停止”状态、且尚未被销毁时才可能运行。
典型适用场景：一个异步任务（比如 std::jthread 启动的函数）正在轮询 stop_token，或阻塞在支持取消的等待操作（如 std::condition_variable::wait_until 带 token）中；此时外部调用 stop_source.request_stop()，所有已注册的 std::stop_callback（只要其所属 token 尚未析构）会在该线程退出前、或在 request_stop() 返回前（取决于实现调度）同步执行。
如何正确构造和持有 std::stop_callback 实例
关键点：std::stop_callback 对象必须存活到其回调被调用完成，否则行为未定义。它不能是临时对象，也不能在回调执行前被析构。
- ✅ 推荐方式：在异步任务函数作用域内定义为局部变量（非 auto 或 lambda 捕获），确保其生命周期覆盖整个任务执行期
- ❌ 错误写法：
std::stop_callback{token, []{ cleanup(); }};—— 这是个纯右值，构造完立即析构，回调永远不会注册成功 - ⚠️ 注意：如果把
std::stop_callback存在std::shared_ptr或类成员里，要确保该智能指针/对象在任务结束前不被释放；否则可能提前析构导致回调丢失 - ? 参数约束：回调函数对象必须可拷贝（或可移动，C++20 起支持移动语义），且不能抛异常（
noexcept是隐式要求，否则编译可能失败或运行时终止）
std::stop_callback 和 std::jthread 的配合要点
std::jthread 自带 std::stop_source，其 get_stop_token() 返回的 token 可用于构造 std::stop_callback。但注意：回调注册时机必须在 jthread 启动之后、且 token 有效期内。
立即学习“C++免费学习笔记（深入）”；
常见错误是在线程函数入口处注册回调，却忘了 token 在线程函数返回后会失效（jthread 析构时自动 join，此时 token 已无效）；更安全的做法是在任务逻辑开始前注册，并依赖 jthread 的 RAII 特性保证 stop_source 存活到线程结束：
std::jthread worker([](std::stop_token stoken) {
// ✅ 正确：在 token 有效时注册
std::stop_callback cb{stoken, []{
std::cout << "cleanup running\n";
// 关闭文件句柄、释放内存、注销事件等
}};
while (!stoken.stop_requested()) {
// 工作循环...
std::this_thread::sleep_for(100ms);
}
});
注意：回调执行期间，stoken 仍有效，但线程即将退出，不应再依赖其他线程局部资源（如 TLS 变量）或尝试再次请求停止。
为什么 stop_callback 有时不触发？排查方向
最常被忽略的是 token 是否真的“可停止”——即对应 std::stop_source 是否还活着，以及是否调用了 request_stop()。
- 检查
stop_source是否已被移动或析构（例如jthread已 join 且超出作用域） - 确认调用
request_stop()的是同一个std::stop_source实例，而非副本（std::stop_source不可复制，只能移动） - 验证回调函数是否因异常退出（即使声明了
noexcept，若内部 throw 会导致程序终止，看起来像“没执行”） - 注意：如果任务在
stop_requested()返回 true 后立即 return，而回调尚未被调度执行，std::jthread的析构会等待回调完成——但若回调本身阻塞或死锁，整个程序会 hang 住
真正棘手的地方在于：回调执行时机由实现决定，既不是严格同步也不是完全异步；它可能在 request_stop() 返回前执行，也可能稍晚一点，但一定在关联 token 销毁前。这意味着你不能假设它“立刻发生”，也不能假设它“一定在某行代码之后”。
