std::stop_source仅发送停止请求，消费者必须显式轮询std::stop_token才能响应；因其无阻塞等待和异常机制，需在循环或等待点手动检查stop_requested()，并合理传递token（按值捕获或通过jthread）。
std::stop_source 本身不能直接终止线程，它只负责发送停止请求；真正响应并退出循环的，必须是消费者线程里显式检查 std::stop_token 的逻辑——这点不搞清，协作模型会卡死或漏处理。
为什么消费者必须手动轮询 stop_token 而不能依赖异常？
std::stop_token 没有内置阻塞等待机制，也不抛出异常。它的作用就是提供一个轻量、无锁的“是否该停”的布尔信号。常见错误是以为调用 stop_source.request_stop() 后，std::condition_variable::wait 或 queue.pop() 会自动中断：
- std::condition_variable::wait 仅在超时或被 notify 唤醒时返回，
stop_token不触发唤醒 - std::queue 本身无 stop_token 支持，pop 操作不会感知停止请求
- std::jthread 自动注册 token 并在析构时 request_stop，但**仍需消费者主动检查 token 状态才能及时退出**
正确做法是在每次循环迭代开始或关键等待点插入 if (token.stop_requested()) break;。
如何把 stop_token 安全传给消费者线程？
传递方式直接影响线程安全和生命周期管理。最稳妥的是在构造消费者 lambda 时按值捕获 std::stop_token（它是可复制的轻量对象）：
std::stop_source ss;
auto token = ss.get_token();
std::thread consumer([token, &queue]() {
while (!token.stop_requested()) {
auto item = queue.try_pop(); // 假设是带超时/非阻塞 pop
if (item.has_value()) {
process(*item);
} else {
std::this_thread::sleep_for(1ms); // 避免忙等
}
}
});
注意：std::jthread 更推荐，它自动绑定 token 并在 join 时 request_stop：
<pre class="brush:php;toolbar:false;">std::jthread consumer([](std::stop_token token, std::queue<int>& q) {
while (!token.stop_requested()) {
// … 同上
}
}, ss.get_token(), std::ref(queue));
</int>
别把 stop_source
生产者要不要检查 stop_token？什么时候该停？
要，但时机和策略不同。生产者通常不因“停止请求”立即中止，而是完成当前批次后优雅退出，避免数据丢失或状态不一致：
- 如果生产者从文件/网络读取，应在每次 read 后检查
token.stop_requested()，防止读到一半强行中断 - 如果生产者是定时生成数据（如传感器模拟），应在 sleep 前检查 token，避免睡完才发现该停了
- 关键点：生产者调用
queue.push()前，最好确认消费者是否还在运行（例如检查consumer.joinable()或配合额外标志位），否则可能 push 到已析构的 queue 导致崩溃
更健壮的做法是让生产者也接收 std::stop_token，并在所有潜在阻塞点（read、sleep、push）前检查，但 push 本身不响应 token —— 那是消费者的事。
最容易被忽略的是：stop_token 的语义是“协作式通知”，不是强制杀线程；任何阻塞在系统调用（如 read()、accept()）或第三方库函数里的线程，必须靠超时 + token 检查来破局，没法靠 request_stop() 单方面生效。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
