std::stop_token是c++20引入的协作式取消信号载体，解决传统bool标志位缺乏统一语义、无法与jthread绑定及不支持自动回调的问题；它需配合std::jthread使用，线程函数首参接收token并定期检查stop_requested()，阻塞调用须选用带token重载版本（如cv.wait(lk, st, pred)），且须注意token背后stop_source的生命周期。
std::stop_token 是什么，它解决什么问题
它不是线程的“杀毒软件”，不能强制终止正在跑的线程；它是协作式取消的信号载体——线程自己定期检查 stop_token 是否被请求停止，再决定是否退出。C++20 之前，我们靠轮询 bool 标志位 + std::atomic，但缺乏统一语义、无法与 std::jthread 绑定、也不支持自动注册回调。现在 stop_token 把“要不要停”这件事标准化了。
怎么用 std::stop_token 配合 std::jthread 做优雅退出
std::jthread 是关键：它自带 stop_source，构造时自动关联一个 stop_token，析构时自动调用 request_stop()（只要没被 detach()）。你只需在工作函数里接收并检查它：
void worker(std::stop_token st) {
while (!st.stop_requested()) {
// 做点事...
std::this_thread::sleep_for(100ms);
}
// 清理资源
}
std::jthread t{worker}; // 自动传入 token
- 必须把
std::stop_token作为第一个参数传给线程函数（std::jthread的约定） - 不要在循环里只靠
st.stop_requested()判断就 return——如果循环体耗时长或阻塞（比如recv()），得配合可中断等待（见下一条） -
std::jthread析构时会阻塞等待线程结束，除非你显式调用detach()（不推荐）
遇到阻塞调用（如 condition_variable::wait）怎么响应 stop_request
直接轮询 stop_requested() 不行：线程卡在 wait() 里，根本没机会检查。正确做法是用带 stop_token 的重载版本：
std::condition_variable cv;
std::mutex mtx;
// ...
while (keep_running) {
std::unique_lock lk{mtx};
cv.wait(lk, st, [&]{ return ready || st.stop_requested(); });
if (st.stop_requested()) break;
// 处理 ready...
}
- 必须用
cv.wait(lk, st, predicate)形式，否则无法感知停止请求 - 谓词（predicate）里要显式检查
st.stop_requested()，因为wait被唤醒后可能只是虚假唤醒 - 类似地，
std::this_thread::sleep_until也有接受stop_token的重载，别漏掉
容易踩的坑：token 生存期、手动 stop_source、跨线程误用
stop_token 是轻量值类型，拷贝安全，但它的有效性依赖背后 stop_source 的生命周期。常见错误：
立即学习“C++免费学习笔记（深入）”；
- 从局部
std::stop_source拿get_token()传给线程 → 线程还没启动，source 就销毁了 →stop_requested()永远返回false - 在线程函数里反复调用
st.stop_requested()却没做任何清理 → 请求停止后线程还在空转消耗 CPU - 把同一个
stop_source给多个线程共用，但没同步逻辑 → 某个线程调request_stop()后，其他线程也该响应，但未必有统一退出策略 - 误以为
std::thread支持stop_token→ 它不支持，必须用std::jthread或手动管理stop_source
最稳妥的起点就是：只用 std::jthread，只写一个接收 std::stop_token 的函数，所有阻塞调用都选带 token 的重载版本。复杂的地方在于，停止不是一拍即合的事——你要设计好检查点、清理路径和超时兜底，否则 token 再标准也没用。
