应使用std::jthread+std::stop_token实现可取消定时循环：用steady_clock计算next时间点，while(!stoken.stop_requested())中sleep_until(next)后二次检查取消状态，更新next时防过期追赶；重排程需原子替换任务句柄；禁用std::async；全程统一使用steady_clock。
用std::jthread+std::stop_token实现可取消的定时循环
要在C++中让一个定时任务在任意时刻被立即停止，且不依赖系统时间调整、不产生毫秒级漂移，必须用std::jthread绑定std::stop_token，并在每次等待后主动检查取消状态。
第一步：定义任务函数，接收std::stop_token参数，使用std::chrono::steady_clock::now()计算下一次触发时间点。
第二步：在while循环条件中直接写!stoken.stop_requested()，而不是先sleep再判断——否则最后一次sleep会白等。
第三步：调用std::this_thread::sleep_until(next)，不能用sleep_for(interval)，否则每轮误差会累积；sleep_until在收到取消请求时会立即返回，但标准不保证唤醒时机，所以返回后必须再查一次stoken.stop_requested()，【漏掉这第二次检查会导致任务多执行一轮】。
第四步：任务体执行完毕后，更新next = next + interval；若do_work()耗时过长，导致next已过期，需额外判断if (std::chrono::steady_clock::now() > next) next = std::chrono::steady_clock::now() + interval，否则会陷入“追赶模式”连续触发。
重新排程必须原子替换任务句柄
重新排程不是“改一个变量”，而是“停旧任务 + 启新任务”的两步操作，中间不能有空窗，也不能让旧任务在新任务启动后意外触发。
方法一：用std::shared_ptr<:jthread>持有当前任务线程句柄，重排程时先调用ptr->request_stop()，再std::swap(ptr, std::make_shared<:jthread>(...))。注意request_stop()只是发通知，必须确保原任务逻辑里有及时响应的检查点，否则线程可能仍在运行。
方法二：用std::atomic<:shared_ptr>>替代裸指针，插入新任务时用store()原子覆盖，同时调用旧句柄的request_stop()。这能避免多线程并发调用reschedule()时出现竞态，【普通std::shared_ptr赋值非原子，多线程下可能引发use-after-free】。
避免用std::async实现定时任务
std::async返回的std::future无法注入std::stop_token，也不提供stop_source接口，它只适合一次性异步执行，不适合需要反复触发、随时取消的定时场景。
常见错误是把std::stop_token传进async的lambda，却只在开头检查一次——这等于没取消逻辑。因为async不管理生命周期，不拦截sleep或I/O，更不会在阻塞点自动响应取消信号。
这一步操作起来很简单，直接把std::async替换成std::jthread即可；但若已有大量async调用，强行改会造成接口断裂，不如新建一个轻量调度器封装层，统一接管所有周期性任务。
时间基准必须用steady_clock
所有定时计算、sleep_until参数、间隔累加，都必须基于std::chrono::steady_clock。system_clock会被NTP校准或用户手动修改，可能导致任务跳过执行或重复触发；high_resolution_clock在某些平台不保证单调性，同样不可靠。
错误示例：auto now = std::chrono::system_clock::now(); next = now + 100ms; —— 编译可能通过，但运行时行为不可预测。
正确写法：auto now = std::chrono::steady_clock::now(); next = now + 100ms; 所有time_point类型必须来自同一clock，跨clock转换需显式duration_cast，且仅限必要日志上报场景。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
