必须用Task或Task时：需await、参与异步流或返回结果；async方法仅允许返回Task、Task、void、ValueTask、ValueTask，其中void仅限UI事件处理器。

, void, valuetask 的选择">

什么时候必须用 Task 或 Task

当你需要被 await、参与异步控制流、或返回结果时，Task 和 Task 是唯一合规选择。C# 编译器只允许 async 方法返回这三种类型（加上 void 和 ValueTask）——但 void 仅限事件处理器等极少数场景。

常见错误是误以为“不返回值就该用 void”，结果导致异常无法被调用方捕获、无法用 await 同步生命周期，甚至测试时难以等待完成。

• Task：适合无返回值但需通知完成的异步操作，比如 SaveAsync()、SendEmailAsync()
• Task：有返回值且可能涉及 I/O 或线程切换，比如 GetUserAsync(int id) 返回 User
• 所有 async 方法体中用了 await，却声明返回 void → 编译器不会报错，但会丢失上下文和异常传播能力

ValueTask 和 ValueTask 的适用边界

ValueTask 不是万能替代品，它只为高频、短时、大概率同步完成的场景优化内存分配。比如缓存命中、内存内计算、或已预热的连接复用。

滥用 ValueTask 反而增加复杂度：它不可重复 await，不能直接传给 Task.WhenAll，也不能隐式转换为 Task（需显式调用 .AsTask()）。

• 适合：MemoryStream.ReadAsync、ConcurrentDictionary.GetOrAdd 的异步重载、自定义缓冲读取器
• 不适合：HttpClient.GetAsync、数据库查询、文件读写等绝大多数真正 I/O 场景 —— 这些几乎总是异步完成，ValueTask 带来的堆分配节省微乎其微，反而引入额外判断开销
• 若方法既可能同步完成又可能异步完成，且被高频调用（如每毫秒调用数次），才值得考虑 ValueTask

async void 只在 UI 事件处理中勉强可用

async void 方法无法被 await，异常会直接抛到 SynchronizationContext（WinForms/WPF 中触发 Application.ThreadException，ASP.NET Core 中可能静默丢失），且无法参与取消传播。

它唯一被框架认可的使用位置是事件处理方法签名，例如 WinForms 的 button_Click 或 WPF 的 ButtonBase.Click。

• 禁止在业务逻辑层、服务类、工具类中暴露 async void 方法
• 测试时无法 await 它，也无法用 CancellationToken 控制它
• 若你写了 public async void DoWork() 并试图在单元测试里调用它 → 测试会立即结束，实际逻辑可能还没执行完

性能与可维护性的实际权衡点

选型不是看哪个“更先进”，而是看调用模式、生命周期和可观测性需求。95% 的业务代码用 Task 和 Task 最安全；ValueTask 是给基础库作者或性能敏感路径准备的“手术刀”，不是日常工具刀。

一个容易被忽略的事实：ValueTask 的结构体特性在跨 await 边界后可能引发装箱（尤其当它内部包装了 Task），此时比直接返回 Task 更重。

public ValueTask ReadAsStringAsync()
{
    if (_bufferedResult != null)
        return new ValueTask(_bufferedResult); // 同步路径：栈上分配
    else
        return new ValueTask(ReadFromNetworkAsync()); // 异步路径：内部仍持有一个 Task
}

如果这个方法常被 await 后再传给 Task.WhenAll，那每次都要走 .AsTask()，间接多一次分配 —— 此时不如一开始就返回 Task。