await已完成Task会同步完成，不挂起也不切换上下文；它直接返回Result或同步抛出异常，性能零开销且调试时无状态机跳转。
await 一个已完成的 Task 不会挂起，直接返回结果
如果 Task 已经处于 RanToCompletion、Cancelled 或 Faulted 状态，await 会同步完成，不触发上下文切换或线程让出。它本质上等价于立即读取 Result（对 Task<t></t>）或检查异常（对失败/取消状态），但语义更安全——不会意外阻塞线程或抛出未包装的异常。
常见误判场景：以为“await 就一定异步”
很多开发者看到 await 就默认有调度开销，其实不然。典型易错点包括：
- 调用
Task.FromResult<int>(42)</int>后await—— 完全同步，无任何延迟 - 在同步方法中先调用
SomeAsyncMethod().ConfigureAwait(false)，再await返回的 task —— 若该 task 已完成，后续 await 仍不调度 - 缓存了已完成的
Task<string></string>（如单例初始化结果），反复await它 —— 每次都是零开销
性能与调试影响：看不出“await”痕迹
因为没有状态机跳转和上下文捕获，编译器生成的状态机可能被高度优化（尤其 Release 模式）。调试时你会看到：
- 断点在
await行不会暂停，光标直接跳到下一行 - 调用栈里没有额外的
MoveNext帧 - 性能分析器中该
await几乎不计入异步耗时
这容易让人误以为代码“没走 await”，其实是走完了，只是太快。
错误处理行为一致，但异常抛出时机不同
无论 task 是否已完成，await 对 Faulted 或 Cancelled 状态的处理逻辑完全相同：把 InnerException 或 OperationCanceledException 重新抛出。但关键区别在于：
- 已完成 task 的
await是同步抛出异常（像普通 throw） - 未完成 task 的
await是异步抛出（在 task 完成后、通过状态机恢复时）
这意味着如果你在 try/catch 里 await 一个已失败的 task，异常会立刻被捕获；而 await 一个稍后才失败的 task，则可能跨 await 边界抛出。
var completedTask = Task.FromException<int>(new InvalidOperationException("boom"));
try
{
await completedTask; // ← 这里立刻 throw，不是“稍后”
}
catch (InvalidOperationException ex)
{
// 能捕获到
}
真正容易被忽略的是：这种同步性会让某些依赖“await 必然异步”的测试或超时逻辑失效——比如你写了 await Task.WhenAny(t, Task.Delay(100))，但 t 已完成，那 WhenAny 也立刻返回，根本不会等 100ms。
