协程（Coroutine）和 async/await 在 Unity 里根本不是一回事
Unity 的
Coroutine是 Unity 引擎自己封装的一套基于
IEnumerator+
yield return的单线程分帧调度机制；而
async/await是 C# 语言级的异步模型，底层是编译器生成的状态机，依赖
Task和
SynchronizationContext。它们都能“不卡主线程”，但原理、适用范围、错误行为完全不同。 协程只能在主线程跑，
yield return new WaitForSeconds(2)受
Time.timeScale影响，暂停后下一帧或指定时间才恢复
async/await默认也回到主线程（靠 Unity 的
UnitySynchronizationContext），但
await Task.Run(...)里的代码真正在后台线程执行，不能调 Unity API 协程函数必须返回
IEnumerator，用
StartCoroutine()启动；
async方法返回
Task或
void（仅限事件处理器），直接调用即可 协程无法被
cancellationToken原生取消；
async方法可自然接收
CancellationToken并响应取消
yield return 不是 await，但 async/await 编译后确实用了类似 yield 的状态机
yield return是生成器语法，用于构造
IEnumerator；
await是异步关键字，用于挂起
async方法。二者表面相似，但语义和运行时行为截然不同——
yield永远只产生一个值并让出控制权，
await则等待一个“可等待对象”（如
Task）完成，并恢复整个方法上下文。 C# 编译器把每个
async方法编译成一个隐藏的状态机类，内部字段保存局部变量，用
MoveNext()驱动——这和
yield生成的状态机结构高度相似，但目的不同：一个是迭代产出，一个是异步流转
yield return null等效于“等一帧”，
await Task.Yield()才是语义上最接近的替代，但它会触发一次真正的线程上下文切换（哪怕仍在主线程） 别试图用
yield return去模拟
await：它不支持
CancellationToken、无法 await
Task、也不能自动捕获异常堆栈（协程内抛异常会直接崩掉整个协程）
什么时候该用 Coroutine，什么时候该用 async/await？
看操作性质和协作需求。Unity 项目里混用很常见，但选错会导致调试困难、取消失效、资源泄漏。
用Coroutine：纯帧粒度控制（如 UI 动画逐帧缩放）、简单延时（
yield return new WaitForSeconds(0.5f)）、配合
AsyncOperation（
yield return Resources.LoadAsync） 用
async/await：需要并发控制（
await Task.WhenAll(t1, t2)）、需取消（传入
cancellationToken）、要组合多个异步源（
UnityWebRequest+
Addressables.LoadAssetAsync+
FileIO） 混合用：可以
await StartCoroutineAsTask(MyCoroutine())（需自行封装），但更推荐统一迁移到
UniTask或原生
Task——协程没有
ConfigureAwait(false)，没法脱离主线程上下文
最容易踩的三个坑
这些不是理论问题，是上线后真实导致卡顿、内存暴涨、崩溃的高频点。
yield return new WaitForSeconds(1)每次都 new 对象 → 堆分配 → GC 尖峰；应复用静态实例或改用
await Task.Delay(1000)
async void方法无法被
await，异常会直接炸到
Application.logMessageReceived，且无法取消；除事件处理器外，一律用
async Task在
Task.Run里调用
GameObject.SetActive(true)→ 运行时报错
UnityEngine.Object is not valid，因为 Unity API 不允许跨线程访问
协程和 async/await 的边界，在 Unity 里从来不是“哪个更高级”，而是“哪个更贴合当前任务的生命周期”。越早明确区分「帧同步节奏」和「异步完成时机」，越少半夜被 QA 的“偶现卡顿”消息叫醒。
