std::jthread 自动绑定 std::stop_source 并传递 std::stop_token 给线程函数，需在自然等待点主动检查 stop_requested() 实现优雅终止；token 可跨线程复制共享状态，但纯计算循环必须手动插入检查点。
std::stop_token 怎么配合 std::jthread 用？
直接用 std::jthread，别手写 std::thread + std::stop_source 组合。它自带绑定的 std::stop_source，构造时自动关联，析构时自动请求停止——这是“优雅终止”的底层保障。
-
std::jthread的构造函数会把内部std::stop_source的get_token()结果传给线程函数，你只需接收std::stop_token参数 - 线程函数里不主动轮询也行，但一旦要提前退出，必须检查
token.stop_requested()，不能只靠异常或超时 - 如果线程函数没声明接收
std::stop_token，std::jthread仍能调用request_stop()，但你的逻辑完全收不到信号——等于白配
轮询 stop_token 的正确姿势是什么？
别在密集循环里每轮都调 token.stop_requested()；更别用 while (!token.stop_requested()) 这种空转写法——CPU 占满、功耗高、还可能错过中断点。
- 在自然等待点检查：比如
std::this_thread::sleep_for()后、queue.pop()返回前、一次网络读取完成后 - 优先用支持取消的等待函数：
std::condition_variable::wait_until(..., token)或std::shared_mutex::try_lock_shared_for(..., token)，它们收到停止请求会直接返回false或抛std::stop_exception - 手动轮询时加
std::this_thread::yield()或短延时（如1ms），避免死等
为什么 request_stop() 后线程没立刻停？
因为 std::stop_token 只是通知机制，不是强制杀线程。是否响应、何时响应、怎么清理，全由你在线程函数里控制。
-
request_stop()是原子设置标志位，几乎瞬间完成；但线程执行流还在跑，得等它自己走到检查点 - 如果线程卡在系统调用里（如
read()、accept()），且该调用不接受stop_token，那只能等它返回后才可能响应——这时考虑用可中断的替代方案（如io_uring、带超时的poll()） - 析构
std::jthread会隐式调request_stop()+join()，但如果线程没检查 token，就会卡在join()上死等
std::stop_token 能跨线程传递吗？
能，而且设计上就鼓励这么做。一个 std::stop_source 的 get_token() 可以被复制任意次，所有副本共享同一停止状态。
立即学习“C++免费学习笔记（深入）”；
- 适合父子任务场景：主线程持有
std::stop_source，把token传给子线程，子线程再传给它的子任务（比如回调、协程、定时器） - 注意生命周期：
std::stop_token本身不含资源，拷贝安全；但源对象（std::stop_source或std::jthread）销毁后，所有关联token的stop_requested()仍返回true（已触发状态不可逆） - 别误以为 “token 失效 = 停止失效”——只要曾经
request_stop()过，所有副本永远返回true
最常被忽略的一点：没有“取消点”的纯计算循环，std::stop_token 就是摆设。你得亲手插检查点，或者换用支持协作式取消的抽象（比如 std::execution::sender 配合 std::stop_token）。否则所谓“优雅”，只是名字好听而已。
