Task是协程的RAII包装而非协程本身，仅持std::coroutine_handle管理生命周期；真正执行体在promise中，awaiter控制挂起/恢复逻辑，三者强绑定协作。
Task 是协程的“对外名片”，不是协程本身
很多人一看到 Task<int></int> 就以为它“是”协程，其实它只是个轻量包装：一个持有 std::coroutine_handle 的 RAII 对象，负责生命周期管理。协程真正的执行体藏在 promise 对象里，而 Task 只是它的“门面”和“句柄代理”。
- 协程函数返回
Task<t></t>时，编译器会自动构造 promise、分配协程帧，并把 handle 存进Task实例中 -
Task析构 → 内部 handle 被销毁 → 如果协程还没结束，就直接强制销毁（不 resume、不清理）→ 常见崩溃或资源泄漏源头 - 它不执行任何逻辑，也不调度；它只管“活着的时候能被谁等、怎么取结果”，比如提供
co_await task或task.get_result()
Awaiter 是协程挂起/恢复的“开关控制器”
每次你写 co_await expr，真正干活的是 expr 的 awaiter —— 它决定“现在能不能跳过挂起”“挂起后往哪扔”“恢复时带什么值回来”。它和 Task 没继承关系，但常被 Task 的 operator co_await() 返回。
-
await_ready()返回true？那根本不会挂起，co_await等价于同步调用 -
await_suspend(handle)是唯一能做调度的地方：你可以把它投给线程池、塞进事件循环、甚至丢给另一个协程等待 —— 但注意：这里不能抛异常、不能阻塞太久，否则卡住整个协程调度链 -
await_resume()必须快速返回，不能含 suspend 操作；它返回的值就是co_await expr的结果
Promise 是协程的“幕后管家”，决定一切行为边界
Task 的类型里必须嵌套定义 promise_type，它才是协程语义的总控：谁来分配内存、遇到 co_return 怎么存值、出异常怎么捕获、结束时要不要自动 resume 调用方……这些全由 promise 控制。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 如果你没显式定义
initial_suspend()，默认是std::suspend_always{}→ 协程创建后立刻挂起，直到第一次co_await才启动 -
final_suspend()返回std::suspend_always{}是常见做法：让协程停在末尾，由Task自己决定何时销毁；若返回std::suspend_never{}，协程结束会自动 resume 调用方 —— 但调用方可能已退出作用域，导致 use-after-free - promise 里必须实现
get_return_object()，它返回的就是那个Task实例；也必须实现unhandled_exception()，否则协程内抛异常会直接 terminate
三者协作时最容易踩的坑
它们不是松散组合，而是强绑定的契约关系：promise 决定协程怎么活，awaiter 决定它在哪暂停/恢复，task 决定它对外怎么被使用。错配就会出问题。
立即学习“C++免费学习笔记（深入）”；
- 把
Task当普通对象传值传递 → 复制出多个 handle，但只有一个能 resume，其余析构时可能 double-resume 或静默失败 - 在
await_suspend里直接调用handle.resume()（即同步 resume）→ 看似“快”，实则破坏了异步语义，且容易栈溢出（协程嵌套过深） - promise 的
final_suspend()返回std::suspend_never{}，又没在外部手动 resume → 协程帧泄漏，promise 析构不触发，资源永远不释放 - 忘记在 promise 里保存
std::exception_ptr→ 协程内抛异常后静默吞掉，调用方co_await task时直接卡死或未定义行为
最麻烦的往往不是语法写错，而是生命周期交叠：比如 Task 在栈上临时存在，而它内部的协程还在后台跑；或者 awaiter 把 handle 交给某个线程池，但那个线程池提前 shutdown 了 —— 这些地方没有编译错误，只有运行时崩得莫名其妙。
