std::stop_callback 是绑定到 std::stop_source 生命周期、仅在 stop_token 被明确请求停止且尚未停止时触发一次的 RAII 回调；它不响应线程退出或作用域结束，需栈上持有或成员变量持久化以确保生效。
std::stop_callback 是什么，它在什么场景下才真正生效
std::stop_callback 不是“注册一个随时能调用的回调”，而是绑定到 std::stop_source 的生命周期，并仅在关联的 stop_token 被请求停止（即 request_stop() 被调用）且该 token 尚未被停止时，自动触发一次。它不响应线程退出、异常退出或作用域结束——只响应明确的停止请求。
常见错误现象：
- 回调函数没执行 → 很可能
std::stop_source已被销毁，或stop_token已处于 stopped 状态（token.stop_requested()返回 true），此时构造std::stop_callback会直接忽略回调 - 回调执行了两次 → 错误地在循环中反复构造新
std::stop_callback对象，而旧对象尚未析构（每个实例只触发一次，但多个实例各自触发）
使用场景：
- 长时间运行的 worker 线程中监听取消信号并释放资源（如关闭文件句柄、取消 pending I/O）
- 在协程或异步任务中，配合
std::jthread自动管理停止逻辑
如何正确构造并保持 std::stop_callback 生效
std::stop_callback 是 RAII 类型，其析构会自动注销回调。因此它必须存活到停止请求发生之后，否则注册即失效。
立即学习“C++免费学习笔记（深入）”；
关键点：
- 必须用
std::stop_token构造（不能传std::stop_source.get_token()的临时对象） - 推荐在栈上持有，或在类成员中持久化（避免悬垂引用）
- 回调捕获的变量需确保生命周期 ≥
std::stop_callback对象本身
示例（安全写法）：
std::jthread t([](std::stop_token stoken) {
// ✅ 正确：callback 对象在栈上，生存期覆盖整个 lambda 执行
std::stop_callback cb(stoken, []{
std::cout << "cleanup: closing socket\n";
// close(socket_fd); // 实际清理逻辑
});
<pre class="brush:php;toolbar:false;">while (!stoken.stop_requested()) {
// do_work();
std::this_thread::sleep_for(100ms);
}});
错误写法（回调永不触发）：
// ❌ 错误：token 是临时对象，stoken 停止状态不可靠，cb 构造可能直接跳过
std::stop_callback cb(std::stop_source{}.get_token(), []{ /*...*/ });为什么 std::stop_callback 无法捕获异常，以及怎么绕过
std::stop_callback 的回调函数若抛出异常，程序会直接调用 std::terminate() —— 标准明确禁止在其中抛异常。
这不是设计疏漏，而是为了保证停止语义的确定性：取消路径必须快速、无副作用、不可中断。
所以：
- 回调体内所有操作必须是 noexcept（或至少用
try/catch吞掉异常） - 不要调用可能抛异常的 STL 容器操作（如
std::vector::push_back）、new、std::cout（虽然通常不抛，但非 guaranteed noexcept） - 清理动作尽量轻量：关闭 fd、置 flag、调用
close()（POSIX）、closesocket()（Win）等系统级无异常接口
示例（安全清理）：
std::stop_callback cb(token, [&fd]{
if (fd != -1) {
::close(fd); // POSIX，noexcept
fd = -1;
}
});和 std::jthread 配合时最容易忽略的生命周期陷阱
std::jthread 析构时会自动调用 request_stop() 并 join()，但它的 std::stop_source 成员在析构末尾才销毁。这意味着：
- 如果你在
std::jthread对象作用域外还保留着它的get_stop_token()，那个 token 可能已无效（析构后访问是未定义行为） - 更隐蔽的是：把
std::stop_callback存在全局/静态对象里，而该对象析构晚于std::jthread→ token 失效，回调静默失败
容易踩的坑：
- 把
std::stop_callback放进std::shared_ptr并跨线程传递 → 若原始std::jthread已结束，token 可能已失去关联 - 在类中保存
std::stop_token成员，但没同步管理std::stop_callback生命周期 → token 还在，但对应 stop_source 已销毁
最稳妥的做法：
- 所有与停止相关的对象（
std::stop_callback、需要响应停止的资源句柄）都放在同一个作用域内，与std::jthread同生共死 - 如需跨作用域通知，改用
std::atomic<bool></bool>+ 手动轮询（牺牲一点实时性，换来确定性）
清理逻辑真正可靠的边界，往往不在回调注册那一刻，而在你能否保证 token 关联的 stop_source 还活着。
