不能靠 std::async 实现可取消定时任务，因其不支持协作式取消；必须用 std::jthread + std::stop_token，并在循环中高频检查 stop_requested()、使用 sleep_until() 和 steady_clock。
不能靠 std::async 实现可取消定时任务 —— 它压根不支持协作式取消，传了 std::stop_token 也不起作用，除非你手动在任务里反复检查。
为什么 std::async + std::stop_token 无法取消定时循环
std::async 启动的是“一次性执行”，不是调度器。它不会自动注入 std::stop_token，也不会在 sleep 或 I/O 点响应取消请求。即使你把 token 传进去，只要任务内部没主动轮询 token.stop_requested()，线程就继续跑，request_stop() 形同虚设。
典型错误写法：
auto task = [](std::stop_token token) {
if (!token.stop_requested()) { // ❌ 只查一次，无效
std::this_thread::sleep_for(5s);
do_work();
}
};
- 真正有效的检查必须嵌在高频路径：每次
sleep_until()前后、每次循环开头、每次耗时操作之后 - 若任务含计算密集段（如解压、遍历大容器），需在每几十次迭代后插入一次
token.stop_requested()检查 -
std::async返回的std::future没有stop_source接口，也无法向后台线程注入取消信号
用 std::jthread + std::stop_token 实现可取消定时循环
这是 C++20 推荐路径：std::jthread 自带绑定的 std::stop_source，析构时自动 request_stop() 并 join()，但前提是任务逻辑本身能及时响应。
立即学习“C++免费学习笔记（深入）”；
关键实操点：
- 必须用
std::chrono::steady_clock::now()计算下次触发时间，禁用system_clock（NTP 调整会导致跳变） - 必须用
std::this_thread::sleep_until(next)，不能用sleep_for(interval)—— 后者无法被取消唤醒，会累积时间漂移 - 每次
sleep_until()返回后，必须再调一次token.stop_requested()—— 因为虚假唤醒或超时唤醒都可能让线程继续执行 - 若
do_work()执行超时，下一轮仍按原计划推进（即“追赶模式”）；如需跳过逾期触发点，得加判断：if (std::chrono::steady_clock::now() > next) next = std::chrono::steady_clock::now() + interval;
std::stop_token 不生效的三大常见原因
现象是调用 jthread.request_stop() 后，线程还在跑下一轮。这不是 bug，而是协作模型的必然表现 —— 取消只是通知，不是硬中断。
-
悬空 token：在栈上创建局部
std::stop_source，然后捕获其get_token()到延迟执行的 lambda 中 → source 析构后，token 的stop_possible()返回false，所有检查失效 -
检查位置错误：把
if (token.stop_requested()) break;放在do_work()之后，导致任务体总被执行完才退出 -
阻塞点未覆盖：比如用了
read()、epoll_wait()这类不响应stop_token的系统调用，又没配合timerfd或eventfd做人工唤醒
跨线程统一取消要共享 std::stop_source，别依赖 jthread 内置的
多个 std::jthread 各自内置的 std::stop_source 是隔离的。想实现“一键全局取消”，必须由外部创建一个长生命周期的 std::stop_source，再把它的 get_token() 分发给所有线程。
- 推荐做法：在
main()或类成员中持有std::stop_source，用值传递方式把 token 传进每个std::jthread的 lambda -
std::stop_callback必须声明在std::jthread变量同一作用域内、且在其之后 —— 否则回调对象会在 lambda 返回时立即析构，失去注册效果 - 回调函数体内禁止阻塞操作（如锁、I/O），否则会拖慢整个取消流程；资源清理建议用原子操作或异步投递
最易被忽略的一点：取消不是“立刻停”，而是“下次检查时退出”。所以任务里所有可能长时间运行的路径，都得有明确、高频的 stop_requested() 检查点 —— 少一个，就可能卡住整个取消流程。
