什么时候该用 Task.CompletedTask
而不是 new Task(() => {})
Task.CompletedTask是一个预创建的、已成功完成的
Task实例，适用于「同步返回已完成任务」的场景。它不分配新对象，也不启动线程或调度器，开销几乎为零。
直接
new Task(() => {}) 不仅要分配内存，还必须手动调用 .Start()，否则任务永远不执行；更严重的是，它处于
Created状态，不是
Completed，下游
await会卡住或抛
InvalidOperationException。 ✅ 正确：返回已知无异步工作、但签名要求返回
Task的方法 ❌ 错误：用它代替真正需要异步执行的逻辑（比如 I/O 或耗时计算） ⚠️ 注意：
Task.CompletedTask没有结果值，返回
Task<t></t>时得用
Task.FromResult<t>(value)</t>
Task.CompletedTask
和 Task.FromResult(0)
的区别
两者都代表已完成任务，但语义和类型完全不同：
Task.CompletedTask是
Task类型，适合 void-returning 异步方法签名
Task.FromResult(0)返回
Task<int></int>，且
Result是
0；若你只需要完成信号，却用了它，就多装箱了一次（对值类型）或引入了不必要的数据 性能上：
CompletedTask是静态只读字段，零分配；
FromResult每次调用都新建一个
Task<t></t>实例（尽管内部做了缓存优化，但不如
CompletedTask极致）
public async Task DoWorkAsync()
{
// ✅ 同步路径，无实际异步操作
if (_isDisabled)
return Task.CompletedTask;
<pre class='brush:php;toolbar:false;'>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 压力和内联机会。
