ValueTask 仅在异步操作同步完成时比 Task 快，因其避免堆分配；若总是异步完成，则无优势甚至略慢。
ValueTask 什么时候比 Task 快
ValueTaskValueTask<t></t> 可以用栈上的结构体返回，而 Task<t></t> 每次都 new 一个对象——这会触发 GC 压力。
常见同步完成场景包括：MemoryStream.ReadAsync（缓冲区有剩余）、ChannelReader.TryRead（队列非空）、自定义 IValueTaskSource<t></t> 实现的即刻完成 awaitable。
- 如果方法 90% 以上走同步路径，
ValueTask<t></t>能显著降低 Gen0 GC 次数 - 如果总是异步完成（比如真实网络 I/O），
ValueTask<t></t>内部仍会创建Task<t></t>，额外多一层封装开销（微乎其微，但不占优） - 没有 await 的情况下直接取
.Result或调用.GetAwaiter().GetResult()，ValueTask<t></t>会 throwInvalidOperationException（已释放或未 await），而Task<t></t>允许这样做（不推荐）
ValueTask 的复用限制和生命周期陷阱
ValueTask<t></t> 是一次性值类型，设计上禁止重复 await 或多次消费。一旦 await 完成，内部持有的 IValueTaskSource<t></t> 可能已被回收或重置；再次 await 会触发 ObjectDisposedException 或静默错误。
对比 Task<t></t>：它是引用类型，可安全多次 await、存储到字段、传给多个消费者。
- ❌ 不要将
ValueTask<t></t>存入类字段：private ValueTask<string> _cache;</string> - ❌ 不要两次 await 同一个变量：
var vt = GetDataAsync();<br>await vt;<br>await vt; // 可能崩溃
- ✅ 正确做法：立即 await，或转成
Task<t></t>（调用.AsTask()），再做后续操作
Task 和 ValueTask 在泛型约束与接口实现上的差异
Task<t></t> 实现了 INotifyCompletion 和 ICriticalNotifyCompletion，也实现了 IDisposable（空实现）；ValueTask<t></t> 同样实现这些接口，但它的 IDisposable 是为防止误用而设的——调用 Dispose() 仅在它包装的是 IValueTaskSource<t></t> 且尚未完成时才有效。
关键约束差异：
-
ValueTask<t></t>要求T必须是可默认构造的（where T : default隐含），因为内部结构体需支持无参初始化；Task<t></t>无此限制 - 无法对
ValueTask<t></t>使用await foreach（除非它包装的是IAsyncEnumerable<t></t>）；而Task<iasyncenumerable>></iasyncenumerable>可以 -
Task<t></t>支持.ContinueWith()、.Wait()、.Result等同步阻塞 API；ValueTask<t></t>不支持——必须先.AsTask()
应该选哪个：看调用方需求，不是看实现方性能
很多人误以为“高性能 API 就该返回 ValueTask<t></t>”，其实选择依据是调用模式：
- 库作者提供底层 I/O 方法（如
Stream.ReadAsync）→ 返回ValueTask<int></int>，因为使用者大概率 await 一次且重视分配 - 业务逻辑层组合多个 await → 返回
Task<t></t>，避免把ValueTask<t></t>传播出去导致调用方踩坑 - 需要缓存、重试、超时包装（如
Policy.WrapAsync(...).ExecuteAsync(...)）→ 统一转.AsTask()，否则策略库无法安全持有 - 单元测试中 Mock 异步方法 →
Task<t></t>更容易 fake（Task.FromResult），ValueTask<t></t>需要构造ManualResetValueTaskSourceCore<t></t>，麻烦得多
最常被忽略的一点：ValueTask 的性能收益只在高吞吐、低延迟、同步完成比例高的服务中可测；普通 Web API 或命令行工具几乎感知不到，反而因误用引入隐蔽异常。
