协程延时任务的核心是挂起当前协程并交由调度器在超时后恢复，而非阻塞线程；需自定义awaitable类型实现await_ready、await_suspend（注册定时器回调）、await_resume，并配合线程安全的外部调度器与定时器机制。
协程延时任务的核心是 suspend 和 resume 控制
直接用 std::this_thread::sleep_for 会阻塞整个线程，而协程延时的关键在于：让当前协程挂起（suspend），把控制权交还给调度器，等时间到了再由调度器主动恢复（resume）。这要求你不能依赖系统 sleep，得靠定时器 + 手动唤醒机制。
标准 C++20 协程本身不提供调度器或定时器，co_await 的挂起点必须自己实现 awaitable 类型，且它的 await_suspend 要能注册回调到外部事件循环或定时器队列中。
- 常见错误：直接在
await_suspend里调用std::this_thread::sleep_for—— 这会让调度线程卡住，所有协程都停摆 - 正确做法：把延时请求交给一个独立的定时器线程（如
std::thread+std::priority_queue）或使用epoll/IOCP等异步 I/O 机制 - 最小可行结构需要三个部分：自定义
awaitable类、全局/局部调度器实例、定时器触发后的coroutine_handle::resume()
写一个可 await 的 delay 函数：delay_for 和 delay_until
你需要封装一个返回 awaitable 的函数，比如 delay_for(std::chrono::milliseconds)。它返回的对象必须实现 await_ready、await_suspend、await_resume 三成员函数。
await_ready 应该快速判断是否已超时（比如 0ms 延时直接返回 true）；await_suspend 是关键——它接收 std::coroutine_handle，你要把它存进定时器队列，并设置到期后调用 handle.resume()；await_resume 只需返回 void。
立即学习“C++免费学习笔记（深入）”；
struct delay_awaitable {
std::chrono::steady_clock::time_point wake_time;
delay_awaitable(std::chrono::steady_clock::duration d)
: wake_time(std::chrono::steady_clock::now() + d) {}
bool await_ready() const {
return std::chrono::steady_clock::now() >= wake_time;
}
void await_suspend(std::coroutine_handle<> h) const {
// 假设 global_scheduler 已启动并管理定时器
global_scheduler.enqueue_at(wake_time, h);
}
void await_resume() const noexcept {}
};
delay_awaitable delay_for(auto d) {
return delay_awaitable{d};
}
注意：global_scheduler 必须是线程安全的，且 enqueue_at 内部要用 std::mutex 或 lock-free 队列保护；否则多协程并发 delay 会崩溃。
调度器必须跑在独立线程里，且不能被 await_suspend 阻塞
如果你把定时器逻辑塞进 await_suspend 里轮询或 sleep，那这个函数就退化成同步阻塞了——协程没并发优势，还更重。
- 典型错误：在
await_suspend中写std::this_thread::sleep_until(wake_time)，导致每次 delay 都阻塞当前线程 - 正确做法：启动一个后台线程，持续检查最小堆（优先队列）顶部的到期时间，用
std::condition_variable::wait_until等待下一个到期点，唤醒后批量 resume 所有匹配的 handle - 性能影响：定时器精度受系统调度限制，Windows 上
std::condition_variable::wait_until默认精度约 15ms；Linux 可用timerfd_create提升到 sub-ms 级别 - 兼容性提醒：MSVC 对
std::coroutine_handle的移动语义支持较晚（VS 2019 16.11+ 才稳定），GCC 12+ 更可靠
实际使用时容易漏掉 co_await 前的 async 启动逻辑
协程函数返回类型必须是可 co_await 的类型（如自定义 task<void>），不能直接写 void foo() { co_await delay_for(100ms); } —— 这会导致编译失败，因为 void 不含 promise_type。
- 必须定义类似
struct task { struct promise_type { ... }; };，其中promise_type::get_return_object()返回task实例，initial_suspend()通常返回suspend_always{} - 启动协程要显式调用
foo().start();或co_await foo();（如果上层也是协程） - 忘记
co_await直接调用协程函数，只会构造 promise 并立即销毁，延时根本不会生效 - 调试时看到协程没执行？先检查返回类型有没有
promise_type，再确认是否真的触发了resume()
真正麻烦的不是写 delay，而是让整个协程生命周期和调度器对齐——handle 持有、异常传播、内存释放时机，这些在简单 demo 里藏得深，但一到真实业务就会暴露。
