什么时候必须用 Task
或 Task<t></t>
当你需要被
await、参与异步控制流、或返回结果时，
Task和
Task<t></t>是唯一合规选择。C# 编译器只允许
async方法返回这三种类型（加上
void和
ValueTask）——但
void仅限事件处理器等极少数场景。
常见错误是误以为“不返回值就该用
void”，结果导致异常无法被调用方捕获、无法用
await同步生命周期，甚至测试时难以等待完成。
Task：适合无返回值但需通知完成的异步操作，比如
SaveAsync()、
SendEmailAsync()
Task<t></t>：有返回值且可能涉及 I/O 或线程切换，比如
GetUserAsync(int id)返回
User所有
async方法体中用了
await，却声明返回
void→ 编译器不会报错，但会丢失上下文和异常传播能力
ValueTask
和 ValueTask<t></t>
的适用边界
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<t></t>最安全；
ValueTask是给基础库作者或性能敏感路径准备的“手术刀”，不是日常工具刀。
一个容易被忽略的事实：
ValueTask的结构体特性在跨
await边界后可能引发装箱（尤其当它内部包装了
Task），此时比直接返回
Task更重。
public ValueTask<string> ReadAsStringAsync()
{
if (_bufferedResult != null)
return new ValueTask<string>(_bufferedResult); // 同步路径：栈上分配
else
return new ValueTask<string>(ReadFromNetworkAsync()); // 异步路径：内部仍持有一个 Task
}如果这个方法常被
await后再传给
Task.WhenAll，那每次都要走
.AsTask()，间接多一次分配 —— 此时不如一开始就返回
Task<string></string>。
![c# byte[] 和 string 如何转换](/d/file/efpub/2026/02-21/smalle64be0ee112a3dda19ba9dbe2727c2f81771666614.jpg "c# byte[] 和 string 如何转换")
