std::stop_source 仅发信号，线程需主动检查 std::stop_token 并退出；condition_variable::wait 必须用带 token 的重载并显式检查 stop_requested()，否则无法响应停止请求。
std::stop_source 本身不能直接“优雅终止”生产者消费者模型——它只负责发信号，真正要靠你在线程里主动检查并退出循环。 大多数人卡在“发了 stop_request() 却线程没停”，根本原因是没在关键等待点响应中断，或者忽略了 std::stop_token 的传递与使用时机。
为什么 std::condition_variable::wait 要配合 stop_token 才能响应停止
单纯调用 stop_source.request_stop() 不会打断 cv.wait()，除非你用带 std::stop_token 的重载版本。否则线程会一直阻塞，直到被虚假唤醒或收到通知，完全无视停止请求。
- 必须用
cv.wait(lock, token, []{ return !queue.empty() || token.stop_requested(); })这种带 token 和谓词的写法 - 谓词里必须显式检查
token.stop_requested()，不能只依赖 queue 状态 - 如果用的是
cv.wait_for(lock, 100ms, ...)，也要确保超时后再次检查token.stop_requested() - 注意：C++20 前没有带 token 的
wait重载，强行升级编译器或改用std::stop_callback+ 手动标志位是常见 fallback
生产者线程里 stop_token 检查的三个关键位置
生产者通常一边生成数据一边往队列塞，但若不及时响应停止，可能在 queue.push() 前、中、后都漏掉退出机会。
- 循环开头：先调
if (token.stop_requested()) break;，避免无意义生成 - 等待入队前（比如队列满时）：用
cv.wait(lock, token, [&]{ return queue.size() - push 完成后：立即再 check 一次
token.stop_requested()，防止刚 push 完就收到停止信号却继续下一轮
消费者线程如何避免“假死”和资源泄漏
消费者最容易出问题的是：取到数据后处理耗时长，期间 stop_request 已发出，但线程还在忙 compute() 或 write_to_disk()，无法及时响应。
- 处理前务必再 check
token.stop_requested()，尤其是长耗时操作之前 - 若处理逻辑本身可分段（如解析大 buffer），应在中间插入
if (token.stop_requested()) return; - 别忘了在析构或退出路径上手动
queue.clear()（如果 queue 不是 lock-free 且无其他线程访问），否则残留元素可能造成悬挂引用 - 所有 RAII 对象（如
std::ofstream、std::unique_lock）必须确保在 stop 响应路径上正常析构，避免因提前 return 导致锁未释放
最常被忽略的一点：stop_token 必须从 std::stop_source 构造后，**按值传递给每个线程函数**（或通过 std::thread 参数传入），而不是捕获 lambda 中的局部 stop_source.get_token() —— 后者若在子线程启动前 stop_source 就销毁了，token 会变成无效状态，stop_requested() 永远返回 false。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
