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

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

《多数高频异步方法，应使用ValueTask而非Task，本质是堆内内存浪费——不是能不能用，而是不用就浪费了。》

为什么 Task 在热路径里是性能黑洞

每次 async Task 方法返回，编译器必须在堆上分配两个对象：状态机实例（约 400 字节）和 Task 对象本身（约 48 字节）。10ms 一次的硬件轮询，1 秒就是 100 个 Task；60 秒后 GC 压力已不可忽视。

• 同步完成路径（如缓存命中）也逃不掉堆分配 —— Task.FromResult 仍要 new 一个 Task
• 高频调用下，GC 频次上升，STW 时间变长，响应毛刺明显
• 不是“慢”，而是“没必要的开销”：90% 的 GetUserAsync、TryReadAsync 类方法，本可零堆分配

ValueTask 怎么做到零分配

ValueTask 是 struct，它内部用 union 模式区分两种状态：同步完成时直接存值（栈上），异步未完成时才包装一个真正的 Task 或 IValueTaskSource（此时才有堆分配）。

• 同步路径：return new ValueTask<string>(cachedValue) —— 纯栈传递，无堆操作
• 异步路径：return new ValueTask<string>(FetchFromDbAsync()) —— 只复用已有 Task，不额外 new
• 注意：不能对同一个 ValueTask 实例多次 await，否则抛 InvalidOperationException

哪些地方必须改，哪些地方不能乱改

改对地方才能见效，改错地方反而引入 bug。

• ✅ 必须改：缓存读取、配置解析、本地 I/O（如 FileStream.ReadAsync 已返回 ValueTask）、硬件轮询等高频、常同步完成的接口
• ❌ 不能改：需要组合 await 的场景，如 Task.WhenAll、ContinueWith —— 必须先调 .AsTask() 转换，此时又回到堆分配
• ⚠️ 谨慎改：公开 API 接口。一旦返回 ValueTask，调用方就不能再用 .Result 或 .Wait()，且无法安全多次 await；内部方法优先，库作者需权衡兼容性

容易被忽略的坑：生命周期与所有权

ValueTask 是值类型，但内部可能持有对堆对象（如 Task）的引用。如果把它存到字段、集合或跨 async 方法传递，会引发悬垂引用或重复 await 异常。

• 不要把 ValueTask 存进 private ValueTask<T> _cache 字段 —— struct 字段复制后，原实例仍可能被 await 过一次
• 不要在 using 语句中 await 后还试图访问其结果变量（尤其涉及 ref 返回时）
• 调试时看到 ValueTask.Status == TaskStatus.RanToCompletion 并不意味着它“安全可重用”——struct 的拷贝行为会让判断失效