异步定时任务精确取消的关键在于协作式检查点设计与系统级唤醒机制协同：需在循环起始、I/O前后、sleep返回后高频检查stop_token，并配合eventfd/timerfd人工唤醒，同时确保stop_source生命周期安全。
异步定时任务的精确取消，不能靠“停掉线程”或“杀掉句柄”——std::stop_token 不提供强制中断能力，它只提供协作式信号通道。真正能精确取消的关键，在于你把检查点放在哪里、怎么和定时器行为对齐、以及如何避免“信号已发但任务没看到”的空窗期。
为什么 std::this_thread::sleep_for 无法被 stop_token 直接中断
这是最常踩的坑：std::this_thread::sleep_for 是阻塞调用，不响应 std::stop_token。即使你在别处调用了 source.request_stop()，睡眠中的线程也不会提前醒来。
- 必须改用带超时的轮询方式：例如
std::this_thread::sleep_for(10ms)+ 紧接着检查token.stop_requested() - 若底层使用
epoll_wait()或timerfd，需手动唤醒（如向配套 pipe 写入字节），否则stop_token只是“挂起状态”，无实际效果 - 协程中更危险：直接
co_await std::chrono::seconds{5}不会响应 cancel；必须用支持std::stop_token的 awaiter（如 cppcoro 的when_all_ready或自定义 timeout wrapper）
在定时循环中嵌入 stop_token 检查的正确位置
检查不能只做一次，也不能只在循环开头——要覆盖所有可能长时间停留的路径。
- 每次迭代开始前：防止刚进入循环就收到取消
- 每次 I/O 调用（如
read()、recv()）之前和之后：系统调用可能阻塞，且返回后需确认是否仍应继续 - 每次
sleep_for或wait_for返回后：这是最典型的“醒来即检查”时机 - 避免写成
if (!token.stop_requested()) { /* 整个 for 循环 */ }—— 这样一旦触发，后续所有迭代全跳过，但任务逻辑实际并未“响应取消”，只是“跳过了执行”
跨线程传递 stop_source 时生命周期管理要点
把取消能力暴露给异步任务，本质是传递一个 std::stop_source 的副本。但它不是智能指针，析构行为需明确控制。
立即学习“C++免费学习笔记（深入）”；
- 局部
std::stop_source source;+[token = source.get_token()]() mutable { ... }→ 错误：lambda 可能延迟执行，而source已析构，token.stop_possible()返回false，后续所有检查都失效 - 正确做法一：用
std::jthread自带的stop_source，它与线程生命周期绑定，安全可靠 - 正确做法二：将
std::stop_source作为类成员变量持有，或用std::shared_ptr<:stop_source></:stop_source>显式延长生命周期 - 注册清理回调时，
std::stop_callback构造函数内不能阻塞或做耗时操作，否则会拖慢整个取消流程
结合 timerfd 实现高精度可取消定时器的关键补丁
Linux 下用 timerfd 做异步定时器时，stop_token 本身不触发 fd 就绪。必须人工注入事件让 epoll_wait 返回，才能进检查逻辑。
- 创建 timerfd 后，额外绑一个
eventfd或pipe，用于接收 cancel 信号 - 在
source.request_stop()之后，向该eventfd写入 8 字节整数（eventfd_write）或向pipe写入任意字节 -
epoll_wait返回后，先读取 timerfd（判断是否真超时），再检查token.stop_requested()；两者任一成立，都视为应退出 - Workflow 等高性能框架正是这么干的：红黑树管理到期时间，
timerfd控制最小超时，eventfd承担 cancel 注入，三者协同实现微秒级响应
真正难的不是“怎么发取消信号”，而是“怎么确保信号必达且必被响应”。高频检查点、非阻塞等待、跨线程对象生命周期、系统级唤醒机制——这四层缺一不可。漏掉任何一层，都会出现“调了 request_stop() 却等了几秒才退出”的现象。
