必须用Task或Task时：需await、参与异步流或返回结果；async方法仅允许返回Task、Task、void、ValueTask、ValueTask，其中void仅限UI事件处理器。
什么时候必须用 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 ValueTaskReadAsStringAsync() { if (_bufferedResult != null) return new ValueTask (_bufferedResult); // 同步路径：栈上分配 else return new ValueTask (ReadFromNetworkAsync()); // 异步路径：内部仍持有一个 Task }
如果这个方法常被 await 后再传给 Task.WhenAll，那每次都要走 .AsTask()，间接多一次分配 —— 此时不如一开始就返回 Task。
