std::stop_callback是在线程被请求停止时执行清理逻辑的钩子，仅当关联的std::stop_source调用request_stop()且回调对象仍存活时触发一次；适用于需及时释放资源或统一响应停止信号的场景。
std::stop_callback 是什么，它在什么场景下才真正生效
std::stop_callback 不是“让线程停止”的工具，而是“在线程被请求停止时执行一段清理逻辑”的钩子。它只在关联的 std::stop_source 调用 request_stop() 后、且该回调对象仍存活时被调用一次。它不阻塞、不等待、不保证执行时机（仅保证在请求发出后、线程函数返回前某时刻执行），更不会自动终止线程运行——线程是否退出，完全取决于你自己的循环判断或 std::stop_token::stop_requested() 检查。
典型适用场景：线程中持有需要及时释放的资源（如文件句柄、锁、临时缓冲区），但又不能把释放逻辑耦合进主循环的每个分支里；或者想在任意位置统一响应停止信号，避免重复写 if (token.stop_requested()) break;。
如何正确构造和保持 std::stop_callback 生效
最常见失效原因是回调对象生命周期短于线程运行期。一旦 std::stop_callback 析构，注册的清理函数就自动注销，后续停止请求将不再触发它。
- 必须在栈上或堆上长期持有其对象实例（例如作为线程函数的局部变量、类成员，或
std::shared_ptr管理） - 不能在 lambda 捕获中按值传递
std::stop_callback，也不能把它声明为临时对象：std::stop_callback{token, []{...}};—— 这行完就析构了 - 推荐写法：在函数开头定义，并确保作用域覆盖整个线程逻辑
void worker_thread(std::stop_token token) {
// ✅ 正确：对象生命周期贯穿整个函数
std::stop_callback cb{token, []{
std::cout << "cleanup: releasing resource\n";
// 释放资源...
}};
while (!token.stop_requested()) {
// 工作逻辑
std::this_thread::sleep_for(100ms);
}
// cb 自动析构，但回调已注册并会在 request_stop() 后触发（如果还没触发）
}
std::stop_callback 和 std::stop_token::stop_requested() 的协作关系
二者不是替代关系，而是互补：一个负责“响应”，一个负责“轮询”。std::stop_callback 无法替代主动检查 stop_requested()，因为：
立即学习“C++免费学习笔记（深入）”；
- 它只触发一次，而线程可能需多次响应（比如分阶段释放）
- 它不提供同步点——你无法知道它何时执行完毕，所以不能依赖它来“等资源释放完再退出”
- 若线程正在阻塞调用（如
std::condition_variable::wait），必须配合带std::stop_token的重载才能被唤醒，此时stop_callback可能尚未执行，但wait返回后你仍需检查stop_requested()
实际建议：用 stop_callback 做异步/非关键清理（如日志、统计上报），用 stop_requested() 控制主循环退出流程。
容易忽略的兼容性与异常安全细节
std::stop_callback 构造函数可能抛 std::system_error（例如系统资源耗尽），但 C++20 标准未要求实现必须抛异常，不同 STL 实现行为略有差异（libstdc++ 当前不抛，libc++ 在某些失败路径会抛）。因此：
- 不要假设构造一定成功，尤其在线程密集启动场景下
- 回调函数体内不应抛异常——若抛出，程序直接调用
std::terminate - 避免在回调中做耗时或可能失败的操作（如网络 I/O、磁盘写入），它本应轻量且可靠
- 注意：C++20 起支持，MSVC 19.29+、GCC 10+、Clang 12+；旧版本无此类型，需自行模拟或升级工具链
真正麻烦的从来不是注册回调这行代码，而是确保它活着、没被意外移动、没在错误时机析构，以及理解它根本不会帮你“停线程”——那还得靠你自己写好退出条件和同步逻辑。
