std::stop_token不能直接stop，因为它只是观察者，不持有停止状态；真正触发停止的是std::stop_source，需通过其request_stop()发起请求，而stop_token仅支持stop_requested()轮询或wait()等待。
std::stop_token 为什么不能直接 stop？
因为 std::stop_token 本身只是个“观察者”——它不持有停止状态，也不能触发停止。真正能发起请求的是 std::stop_source，而 std::stop_token 只负责轮询或注册回调。常见错误是在线程函数里拿到 std::stop_token 就以为能调用 token.stop()，结果编译失败：该类型根本没有这个成员函数。
正确做法是把 std::stop_source 传进线程（或捕获到 lambda），需要退出时调用其 request_stop()；工作线程则通过 token.stop_requested() 检查，或用 token.wait() 阻塞等待。
如何在线程函数中响应 stop 请求？
典型模式是循环中定期检查 stop_token 状态，尤其在长时间阻塞操作（如 sleep、queue.pop()、socket.recv()）前后插入检查点。不要只在循环开头 check 一次——否则可能卡住数秒甚至更久才响应。
- 用
token.stop_requested()做轻量轮询，适合已存在循环结构的场景 - 用
token.wait()主动挂起直到被通知，适合“等一个信号再干活”的模型（但注意它不可被中断，且需配合std::stop_source的生命周期） - 若使用
std::condition_variable，应把stop_token和条件变量一起 wait：cv.wait(lock, [&]{ return token.stop_requested() || !queue.empty(); });
示例：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
void worker(std::stop_token token, std::queue<int>& q, std::mutex& m) {
while (!token.stop_requested()) {
std::unique_lock lock(m);
cv.wait(lock, [&]{ return token.stop_requested() || !q.empty(); });
if (token.stop_requested()) break;
auto val = q.front(); q.pop();
lock.unlock();
process(val);
}
}
std::jthread 怎么简化 stop 流程？
std::jthread 是 C++20 对可协作中断线程的封装，构造时自动绑定 std::stop_source，析构时自动 join()，且提供 get_stop_token() 成员函数。相比裸 std::thread，它省去了手动管理 stop_source 生命周期的麻烦。
- 直接捕获
jthread.get_stop_token()传给工作函数，无需额外传递stop_source - 调用
jthread.request_stop()即可触发所有关联的stop_token，比手动调stop_source.request_stop()更直觉 - 注意：
std::jthread析构会阻塞等待线程结束，若线程未响应 stop 请求，会导致析构卡死——这反而是个安全提示，说明你的退出逻辑有缺陷
哪些操作会让 stop_token 失效或行为异常？
std::stop_token 是可复制、可移动的，但它的有效性依赖于原始 std::stop_source 是否还存活。一旦 stop_source 被销毁（比如局部变量离开作用域），所有从它派生的 stop_token 仍可调用 stop_requested()（返回 false），但无法再注册回调或 wait() ——此时 token.wait() 会立即返回，不阻塞也不报错，容易被误判为“已停止”。
- 避免把
stop_token存在比stop_source生命周期更长的对象里（比如 static 成员、单例缓存） - 注册回调用
token.register_callback([]{ ... })时，回调对象必须确保在stop_source销毁前被移除，否则可能访问悬空资源 - 跨线程传递
stop_token安全，但不要跨线程传递stop_source后再销毁它——除非你明确控制了所有持有方的生命周期
最稳妥的做法：让 std::jthread 管理整个生命周期，或确保 stop_source 的生存期严格覆盖所有使用它的线程和回调。
