协程类型要支持co_await，必须提供operator co_await()返回一个满足awaitable概念的对象，该对象须有public、非模板的await_ready()（bool）、await_suspend()（返回void/bool/handle）和await_resume()（返回表达式结果）四个成员函数。
协程类型必须满足哪些最小接口才能被 co_await？
不是随便写个类就能用 co_await 的。编译器只认三件套：operator co_await()、await_ready()、await_suspend() 和 await_resume()。缺任何一个，co_await my_obj 就直接报错 —— 常见错误是漏掉 await_resume()，编译器提示 “no matching function for call to ‘await_resume’”，但没说缺哪部分。
这四个函数里，await_ready() 决定是否跳过挂起；await_suspend() 负责把协程句柄存起来或立刻恢复；await_resume() 返回 co_await 表达式的值。它们都必须是 public 成员函数，且不能是模板（除非你明确特化）。
struct my_awaiter {
bool await_ready() const noexcept { return false; }
void await_suspend(std::coroutine_handle<> h) { /* 保存 h 或触发回调 */ }
int await_resume() noexcept { return 42; } // 返回类型要和 co_await 表达式一致
};
如何让自定义类型支持 co_await？operator co_await() 怎么写？
用户写的类型（比如 async_task<int>）本身不直接提供那四个 await 函数，而是靠 operator co_await() 返回一个满足要求的 awaiter 对象。这个 operator 必须是 const 成员函数或非成员函数，返回类型得是可 await 的类型。
常见错误：返回临时对象却没加 const 引用修饰，导致 move 后析构，await_suspend() 拿到悬垂指针；或者返回值类型不满足 awaitable 概念（比如忘了实现 await_ready）。
立即学习“C++免费学习笔记（深入）”；
- 推荐写法：返回一个轻量级、不含资源管理的 awaiter（如仅含状态标志和句柄存储）
- 避免在 operator 中做耗时操作 —— 它在协程挂起点执行，应尽可能快
- 如果 awaiter 需要访问原对象状态，用
const_cast不安全；正确做法是让 awaiter 持有原始对象的 const 引用或 shared_ptr
struct async_task {
int result_;
std::coroutine_handle<> continuation_;
<p>auto operator co_await() const & {
struct task_awaiter {
const async<em>task& t</em>;
bool await<em>ready() const noexcept { return t</em>.result_ != 0; }
void await_suspend(std::coroutine<em>handle<> h) { t</em>.continuation_ = h; }
int await<em>resume() const noexcept { return t</em>.result_; }
};
return task_awaiter{*this};
}
};
await_suspend() 返回什么会影响协程调度逻辑
await_suspend() 的返回值不是 void —— 它控制协程是否立即恢复、是否切换到别的调度器、甚至是否取消挂起。返回类型决定行为：
-
void：挂起，等别人调用resume() -
bool：true 表示已安排恢复，协程不会自动挂起；false 等同于 void -
std::coroutine_handle<>：立刻切到该 handle 继续执行（常用于线程切换或调度器移交）
容易踩的坑：返回 std::coroutine_handle<> 后没确保目标 handle 有效，或没清空原 handle，导致 double-resume crash；返回 true 却没真正安排恢复，协程就永远卡住。
典型场景是配合线程池：在 await_suspend() 里把 handle 提交到 worker 线程，然后返回 true，告诉编译器“这事我接管了”。
为什么 await_resume() 的异常传播容易出问题？
await_resume() 是协程恢复后第一个执行的函数，它的异常会直接向上抛给 co_await 所在作用域。但如果它本身不 throw，而之前 suspend 阶段的异步操作失败了（比如网络超时），错误信息就得通过其他方式传递 —— 比如把 exception_ptr 存进 awaiter，再在 await_resume() 里 rethrow。
- 不要在
await_resume()里做复杂计算或 I/O —— 它应在栈上快速完成 - 如果可能失败，返回类型建议用
std::expected<T, E>或手动管理异常状态，而不是依赖未定义行为 - 注意 noexcept：若声明为
noexcept却抛异常，程序直接 terminate
很多自定义 awaiter 在测试时一切正常，上线后偶发崩溃，根源就是 await_resume() 没处理好异步任务的错误路径。
