std::stop_source退出线程的核心逻辑是协作式中断：它不强制终止线程，而是通过std::stop_token通知线程主动检查stop_requested()并在循环或等待点响应退出；必须正确传递token、在关键位置轮询或使用支持token的阻塞函数（如cv.wait(..., token)），且确保stop_source生命周期覆盖线程运行期。
std::stop_source 退出线程的核心逻辑是什么？
它不是靠轮询或信号，而是通过协作式中断机制：线程主动检查是否被请求停止，并在合适位置响应。关键在于 std::stop_token 的传递和 std::stop_callback 的注册，而不是强行终止线程执行流。
如何在线程函数里正确监听 stop_token？
必须把 std::stop_token 作为参数传入线程函数（或捕获进 lambda），并在循环/等待点调用 stop_token.stop_requested() 或使用 std::condition_variable::wait(..., token) 等支持中断的等待函数。
- 错误写法：
std::thread t([]{ /* 没传 token，完全无法响应 */ }); - 正确写法：
std::thread t([&token]{ while (!token.stop_requested()) { /* 工作 */ } }); - 更推荐：用
std::condition_variable::wait配合 token，避免忙等 —— 它会在收到 stop 请求时自动唤醒 - 注意：
stop_token是轻量拷贝对象，可安全传值；但需确保其生命周期覆盖线程运行期（比如绑定到std::thread对象前不要析构std::stop_source）
std::stop_source::request_stop() 会立即生效吗？
不会立即中止线程执行，只设置内部标志位并唤醒所有注册了 std::stop_callback 或正在用 token 等待的阻塞点。线程是否退出、何时退出，完全取决于你代码里检查和响应的位置。
- 调用
request_stop()后，已处于cv.wait(lock, token)的线程会立刻返回 false 并退出等待 - 若线程正执行耗时计算且没检查 token，就会继续跑完当前迭代——这是设计使然，不是 bug
-
request_stop()是幂等的：重复调用无副作用，但多次注册的std::stop_callback会全部触发一次 - 不能依赖它来“杀掉”死循环；必须在业务逻辑中插入检查点
常见坑：为什么 stop_token 始终返回 false？
最常见原因是 std::stop_token 对应的 std::stop_source 已被销毁，或线程启动时未正确捕获/传递 token。
立即学习“C++免费学习笔记（深入）”；
- 典型错误：在局部作用域创建
std::stop_source ss;，然后启动线程并传入ss.get_token()，但ss很快离开作用域析构 → token 失效 →stop_requested()永远为 false - 修复方式：把
std::stop_source成员变量放在管理线程的类里，或用std::shared_ptr<:stop_source></:stop_source>延长生命周期 - 另一个坑：lambda 捕获
ss而非ss.get_token()，导致 token 构造发生在 lambda 执行时——此时 ss 可能已析构 - 调试技巧：打印
token.stop_possible()，若为 false，说明 token 无效（通常因 source 已销毁）
实际协作退出的关键不在 stop_source 本身，而在你是否在每个可能长时间运行的环节都预留了响应点——漏掉一个 while 循环头、一次 sleep、一个 wait，就等于留了一道无法关闭的门。
