ValueTask不是Task的升级版，而是有严格使用边界的性能优化工具：仅限一次性await、不可同步阻塞、不支持组合API、仅在高频同步完成场景下收益显著。
别直接把 ValueTask 当成 Task 的“升级版”来替换，它不是更快的通用异步类型，而是一个有明确使用边界的性能优化工具——用错反而拖慢代码、引发运行时崩溃。
ValueTask 只能 await 一次，重复 await 会抛 InvalidOperationException
这是最常踩的坑。因为 ValueTask 是 struct，内部可能持有已释放的 IValueTaskSource<T>，第二次 await 就可能触发 ObjectDisposedException 或静默错误。
- ❌ 错误写法：
var vt = GetDataAsync(); await vt; await vt; - ❌ 存入字段再多次消费：
private ValueTask<string> _cached; ... await _cached; await _cached; - ✅ 正确做法：立即
await，或显式转成Task：await vt.AsTask(); - ✅ 若需多次检查状态，优先用
Task；ValueTask的设计目标就是“一次性消费”
ValueTask 不支持 .Result / .Wait()，调用就炸
ValueTask<T> 没有 .Result 属性，也不支持 .Wait() 方法。这不是疏漏，而是刻意限制——它不提供同步阻塞语义。
- ❌
var result = GetDataAsync().Result;→ 编译失败（无此成员） - ❌
GetDataAsync().GetAwaiter().GetResult();→ 运行时报InvalidOperationException：“ValueTask may only be awaited once” 或 “already completed” - ✅ 真需要同步结果？说明你本就不该用
ValueTask；换回Task<T>，或重构调用链为纯异步 - ⚠️ ASP.NET Core 中间件里混用
.Result是线程池饥饿的常见诱因，和ValueTask无关，但容易在迁移时暴露出来
ValueTask 的性能优势只在“高频 + 高同步完成率”路径上成立
它的价值不是“更快”，而是“少分配”。只有当方法大概率（比如 >60%）同步返回时，才值得引入 ValueTask。
- ✅ 合适场景：
MemoryCache.GetOrCreateAsync（缓存命中时直接返回）、ChannelReader.TryRead（队列非空）、自定义IValueTaskSource<T>实现的短路逻辑 - ❌ 不合适场景：
HttpClient.GetStringAsync（几乎总是异步 I/O）、Task.Run(() => heavyCalc())（纯 CPU 绑定，无法同步完成） - ⚠️ 注意：.NET Core 3.0 之前
ValueTask几乎没优化效果；.NET 6+ 才真正稳定，且收益高度依赖 JIT 对结构体内联的判断 - ? 如果你不确定同步完成率，先用
Task；等压测发现 Gen0 GC 频繁且热点集中在某几个异步入口，再针对性替换
ValueTask 不能直接参与 Task 组合，必须先 AsTask()
ValueTask 不实现 Task.WhenAll、Task.WhenAny、.ContinueWith 等 API 所需的完整契约。它只实现了基础 INotifyCompletion，仅够 await 使用。
- ❌
await Task.WhenAll(vt1, vt2);→ 编译失败 - ✅ 正确写法：
await Task.WhenAll(vt1.AsTask(), vt2.AsTask()); - ⚠️
.AsTask()会强制包装为Task<T>，失去零分配优势；如果组合操作本身是高频路径，说明你选错了抽象——应让组合层用Task，底层原子操作才考虑ValueTask - ?
IAsyncEnumerable<T>内部大量用ValueTask，但那是运行时深度定制的结果，业务代码别照搬
最容易被忽略的一点：ValueTask 的生命周期完全绑定在 await 表达式的那一瞬间。它不管理资源、不保证线程安全、不处理重入——这些都得由你写的同步短路逻辑自己兜底。一旦脱离“高频、短路、单次消费”这个铁三角，它就从性能利器变成定时炸弹。
