C产品如何满足特定用户需求？

本文共计1008个文字，预计阅读时间需要5分钟。

将 `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 表达式的那一瞬间。它不管理资源、不保证线程安全、不处理重入——这些都得由你写的同步短路逻辑自己兜底。一旦脱离“高频、短路、单次消费”这个铁三角，它就从性能利器变成定时炸弹。