协程不是线程，co_await 不自动并发；它仅提供挂起/恢复机制，需手动配调度器（如线程池）；标准库无默认调度器，co_return 类型须与 promise_type 接口匹配；异常在 resume 后才抛出；generator 生命周期管理易致 UB。
协程不是线程，co_await 不会自动并发
很多人一看到 co_await 就默认“这能并行跑”，结果发现函数还是串行执行、CPU 占用没变高——因为 C++20 协程本身不调度，它只提供挂起/恢复的机制，调度器（比如你自己写的线程池、std::jthread、或第三方库如 libunifex）得自己配。
常见错误现象：co_await 一个耗时的 sleep_for 或网络调用后，整个调用栈卡住，其他协程也不推进。
- 必须显式把协程对象交给某个执行上下文，比如
executor.submit([]() -> task<void> { ... })</void> - 标准库至今没提供默认调度器，
std::coroutine_handle不能直接 run，得靠你传给线程、IO 多路复用循环，或封装在task/generator类里 - 别在主线程裸写
co_await f(); f().handle.resume();，除非你真在手写状态机
co_return 的返回类型必须匹配 promise_type::return_void() 或 return_value()
编译报错 no matching member function for call to 'return_void' 或类似提示，基本就是协程返回类型和 promise 声明对不上。
使用场景：自定义协程类型（如 task<t></t>）时，promise_type 要根据 co_return 写法提供对应接口：
立即学习“C++免费学习笔记（深入）”；
- 如果函数声明为
task<void> f()</void>，但写了co_return 42;→ 编译失败，应改用co_return;或换返回类型 - 如果声明为
task<int> f()</int>，却写了co_return;→ 同样失败，必须用co_return expr;，且expr类型要能隐式转为int -
co_return表达式类型最终由promise.return_value(expr)接收，不是直接赋值给协程返回对象
不要在协程里直接捕获 std::exception_ptr，co_await 可能不抛异常
协程挂起期间发生的异常（比如 awaiter 的 await_resume() 抛出），不会像普通函数那样向上冒泡；它会被捕获并存进协程的 promise，直到你调用 handle.resume() 后，在 await_resume() 返回点才重新抛出。
容易踩的坑：写了个 try-catch 包着 co_await async_op()，结果异常根本进不去 catch —— 因为 async_op() 返回的是协程对象，还没 resume。
- 真正该 try/catch 的是
handle.resume()调用点，或在await_resume()内部处理 - 更稳妥的做法：让 awaiter 的
await_resume()返回std::expected<t std::exception_ptr></t>，避免异常传播路径失控 - 标准
std::suspend_always等内置awaiter 不做异常封装，出问题就崩，别拿来练手
generator<t></t> 的生命周期管理比看起来危险
标准库的 std::generator<t></t>（C++23 引入，部分编译器需开启实验性支持）看似简单，但它的迭代器本质是协程 handle 的包装，一旦原始协程函数栈帧销毁（比如局部协程函数返回），再调用 begin() 就 UB。
典型错误：写了个函数返回 generator<int></int>，然后在 for-range 里用，但 generator 对象被 move 走或提前析构了。
- 确保
generator对象存活时间 ≥ 迭代过程；别把它存在std::vector里又反复 move - 不要从 lambda 或临时对象生成
generator，例如for (auto x : []{ co_yield 1; }())—— lambda 调用完就没了，resume 时访问已释放栈 - Clang 15+ 和 GCC 13+ 对
generator的诊断还很弱，崩溃前往往没警告
协程的 suspend/resume 是手动内存管理的延伸，不是语法糖。最麻烦的从来不是怎么写 co_await，而是谁 resume、何时 resume、在哪 resume、resume 失败了怎么办——这些全得你画清楚控制流图。
