std::stop_callback是c++20协作式取消机制中仅在关联stop_source调用request_stop()后、且自身存活时自动执行一次的回调，不在线程退出时兜底执行，也不保证在目标线程上下文中运行。
std::stop_callback 是什么，它在什么时机执行
std::stop_callback 是 C++20 引入的协作式线程取消机制的一部分，它**只在关联的 std::stop_source 被请求停止（request_stop()）后、且该回调对象仍存活时，自动调用一次其绑定的可调用对象**。它不在线程退出时“兜底”执行，也不保证在目标线程上下文中运行——实际执行线程取决于谁调用了 request_stop()（通常是其他线程），且回调函数运行在那个调用者的线程中。
常见误解是把它当“线程析构钩子”，结果发现逻辑没执行或执行错线程。关键点：它依赖 std::stop_token 的生命周期 + 显式 request_stop()，不是靠线程自然结束触发。
如何正确绑定并确保回调被调用
必须满足三个条件：token 有效、callback 对象持续存活、有人调用 request_stop()。典型错误是把 std::stop_callback 声明为局部变量却没控制好作用域。
- 把
std::stop_callback声明为类成员或std::shared_ptr管理的对象，避免提前析构 - 确保绑定的
std::stop_token来自同一个std::stop_source（例如从std::jthread的get_stop_token()获取） - 显式调用
stop_source.request_stop()或让std::jthread析构时自动触发（jthread析构会调用request_stop()并join()）
示例：
std::jthread t{[&](std::stop_token st) {
// 绑定回调（this->cleanup 必须是成员函数或捕获有效的 this）
std::stop_callback cb{st, [&] { cleanup(); }};
while (!st.stop_requested()) {
do_work();
std::this_thread::sleep_for(10ms);
}
}};
注意：这里 cb 是局部变量，但它在循环内保持活跃，且 t 析构时会先 request_stop → 触发 cb 执行 → 然后才销毁 cb。
为什么回调没执行？排查常见断点
最常踩的坑是 token 失效或 callback 提前销毁。具体看这些信号：
-
std::stop_token::stop_possible()返回false：说明 token 已无效（比如源已被移动、或来自已析构的jthread） - 回调函数里打印日志但没输出：大概率是
std::stop_callback对象已析构（检查作用域、是否被 move、是否被异常提前退出绕过） - 回调执行了但数据访问崩溃：因为回调运行在调用
request_stop()的线程中，而非目标工作线程 —— 若回调访问线程局部状态（如thread_local变量、栈变量地址），会出错 - 使用
std::thread而非std::jthread：std::thread没有内置 stop_source，需手动管理std::stop_source和生命周期，极易漏掉request_stop()
std::jthread 是更安全的起点
直接手搓 std::stop_source + std::thread 容易出错。推荐从 std::jthread 入手，它自带绑定的 stop_source，且析构时自动 request_stop() + join()，大幅降低误用概率。
要点：
- 用
jthread.get_stop_token()获取 token，别自己 newstop_source - 若需多个回调，重复构造
std::stop_callback即可，每个独立管理生命周期 - 不要在回调里做耗时操作（如 I/O、锁竞争），它阻塞的是调用
request_stop()的线程
复杂点在于：回调执行时机不可控（谁调 request_stop()，谁就执行回调），且无法保证原子性 —— 如果你依赖“回调执行完再继续”，得额外加同步（如 std::latch 或 std::condition_variable）。这点容易被忽略，尤其在测试时用单线程调用 request_stop() 看似正常，一到多线程就竞态。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
