该用 Task.CompletedTask 而不是 new Task(() => {}) 时：需同步返回已完成 Task 且无实际异步工作；前者零分配、已完成，后者需 Start 且处于 Created 状态致 await 卡死。
什么时候该用 Task.CompletedTask 而不是 new Task(() => {})
Task.CompletedTask 是一个预创建的、已成功完成的 Task 实例，适用于「同步返回已完成任务」的场景。它不分配新对象，也不启动线程或调度器，开销几乎为零。
直接 new Task(() => {}) 不仅要分配内存，还必须手动调用 .Start()，否则任务永远不执行；更严重的是，它处于 Created 状态，不是 Completed，下游 await 会卡住或抛 InvalidOperationException。
- ✅ 正确：返回已知无异步工作、但签名要求返回
Task的方法 - ❌ 错误：用它代替真正需要异步执行的逻辑（比如 I/O 或耗时计算）
- ⚠️ 注意：
Task.CompletedTask没有结果值，返回Task时得用Task.FromResult(value)
Task.CompletedTask 和 Task.FromResult(0) 的区别
两者都代表已完成任务，但语义和类型完全不同：
-
Task.CompletedTask是Task类型，适合 void-returning 异步方法签名 -
Task.FromResult(0)返回Task，且Result是0；若你只需要完成信号，却用了它，就多装箱了一次（对值类型）或引入了不必要的数据 - 性能上：
CompletedTask是静态只读字段，零分配；FromResult每次调用都新建一个Task实例（尽管内部做了缓存优化，但不如CompletedTask极致）
public async Task DoWorkAsync()
{
// ✅ 同步路径，无实际异步操作
if (_isDisabled)
return Task.CompletedTask;
await _service.ProcessAsync();
}
在接口实现中强制使用 CompletedTask 的典型场景
当实现一个定义为 Task SomeMethodAsync() 的接口，但某个具体实现类根本不需要异步行为时，CompletedTask 是最轻量、最符合契约的选择。
- 避免用
Task.Run(() => {})—— 它会调度到线程池，引入不必要上下文切换 - 避免用
Task.Delay(0)—— 创建定时器、触发调度，纯属浪费 - 不能用
return;—— 编译失败，方法签名要求返回Task
public class NullLogger : ILogger
{
public Task LogAsync(string message)
{
// 什么也不做，但满足异步接口
return Task.CompletedTask;
}
}容易忽略的陷阱：泛型任务和状态机生成
看起来只是“返回一个已完成任务”，但编译器对 async 方法的处理很敏感。如果在 async 方法里写 return Task.CompletedTask;，C# 仍会生成完整状态机 —— 即使没 await 任何东西。
真正零开销的做法是：不用 async 关键字，直接返回 Task.CompletedTask。
- ❌
public async Task M() => Task.CompletedTask;→ 生成状态机，多余 - ✅
public Task M() => Task.CompletedTask;→ 直接返回，无状态机 - ⚠️ 如果方法体里混有
await和同步短路逻辑，才需要async+ 条件返回CompletedTask
这个细节在高频调用路径（如中间件、序列化器）里会影响 GC 压力和内联机会。
