c++20 协作取消依赖 std::stop_source、std::stop_token 和 std::jthread 三者配合：前者发信号，中间者轮询或注册回调，后者自动 join 并绑定 stop_source；必须在循环高频路径中显式检查 token.stop_requested()，仅传 token 不检查将失效。
std::stop_token 和 std::jthread 是协作取消的标配
标准库从 C++20 起提供了原生支持，不用手撸 std::atomic<bool></bool> 或自定义 flag。核心是 std::stop_source、std::stop_token 和 std::jthread 三者配合：前者发信号，中间者轮询/注册回调，后者自动 join + 关联 stop_source。
常见错误是只传 std::stop_token 却不检查它——令牌本身不中断线程，只是个“询问渠道”。必须显式调用 token.stop_requested() 或在循环中用 token.stop_possible() 判断是否值得检查。
-
std::jthread构造时自动绑定std::stop_source，比std::thread多一层生命周期保障 - 若任务已脱离线程（比如被移到协程或队列里），需手动传递并持有
std::stop_source的副本 - 回调注册（
token.register_callback()）适合清理资源，但不能阻塞；回调执行期间stop_requested()必为 true
在循环中检查 cancel 不能只靠一次判断
异步任务常是长循环或 I/O 等待，如果只在入口处查一次 token.stop_requested()，就等于放弃协作——任务会跑到底。真正的协作点得嵌进高频路径里，比如每次迭代开头、每次网络读之前、每次 sleep 之后。
典型场景：一个模拟耗时计算的 loop：
立即学习“C++免费学习笔记（深入）”；
void worker(std::stop_token token) {
for (int i = 0; i < 1000000; ++i) {
if (token.stop_requested()) break; // ✅ 关键检查点
heavy_computation_step(i);
}
}- 不要写成
if (!token.stop_requested()) { /* whole loop */ }—— 这样一旦触发就跳过全部逻辑，但无法响应中途取消 - 对阻塞调用（如
std::this_thread::sleep_for），建议用带超时的版本，并在每次醒来后检查 token - 某些系统调用（如
read()、epoll_wait()）不响应 stop_token，需结合std::stop_source.request_stop()+ 人工唤醒（如写 pipe、关 socket）
跨线程传递 stop_source 需注意对象生命周期
当你把取消能力暴露给外部（比如启动任务后返回一个 handle），实际上传递的是 std::stop_source 的副本。副本之间共享状态，但各自析构不干扰对方——这点和 std::shared_ptr 类似。
容易踩的坑是提前释放源对象：
- 若把局部
std::stop_source的get_token()传给异步 lambda，而 lambda 延迟执行，此时局部变量已销毁 →token.stop_possible()返回 false，且后续所有检查都失效 - 正确做法：用
std::jthread自带的 source，或明确延长std::stop_source生命周期（例如成员变量、std::shared_ptr<:stop_source></:stop_source>） -
std::stop_token可拷贝、可移动、空值安全（默认构造的 token 调用stop_requested()永远返回 false）
协程中使用 stop_token 要配合 co_await 和暂停点
C++20 协程没有内置取消语义，但你可以把 std::stop_token 当作普通参数传入，并在每个 co_await 前手动检查。关键在于：暂停点（suspend point）本身不是取消点，你得自己加。
比如一个等待某条件的协程：
auto wait_until_ready(std::stop_token token) -> std::suspend_always {
while (!ready && !token.stop_requested()) {
co_await std::suspend_always{};
}
}- 不能依赖
co_await自动感知取消；标准 awaiter 不读 token - 若底层有可取消的 awaitable（如某些第三方库的
async_read），它内部才可能集成 stop_token，否则仍需手动轮询 - 协程帧（coroutine frame）里的
std::stop_token成员变量，其生命周期由协程决定，无需额外管理
真正麻烦的是混合场景：协程挂起在某个系统调用上，而该调用又不接受 stop_token——这时候只能靠超时 + 定期检查，或者换用支持取消的 I/O 抽象层。
