用 ValueTask 替代 Task 可避免堆分配，但仅限同步完成路径且不跨 await 边界重用；错误使用会抛 InvalidOperationException；应优先用于高频内部方法，公共 API 慎用，需复用时转 Task，禁用 ConfigureAwait(false)。
用 ValueTask 替代 Task 时要注意同步完成路径
同步返回的异步方法（比如缓存命中、参数校验失败）用 ValueTask 能避免堆分配，但前提是不跨 await 边界重用或暴露给外部。常见错误是把 ValueTask 存进字段、传给非 await 上下文（如 ContinueWith），或在未 await 前多次 await —— 这会抛 InvalidOperationException: "ValueTask may only be awaited once"。
实操建议：
- 只在 hot path（如高频 API 入口、内存缓存读取）中对确定「大概率同步完成」的方法用
ValueTask - 避免在公共 API 返回
ValueTask，除非你完全控制调用方行为；内部方法可放宽 - 若需复用或延迟 await，先转成
Task：var task = valueTask.AsTask();
- 别用
ValueTask.ConfigureAwait(false)—— 它不存在，必须先转Task
异步流处理优先选 IAsyncEnumerable<T>，但别在循环里开新 async 方法
IAsyncEnumerable<T> 是 C# 8+ 处理高并发数据流（如分页查库、实时日志推送）的自然选择，但它本身不解决并发度控制。常见陷阱是写成这样：
await foreach (var item in GetItemsAsync()) // 每次 yield 都可能触发一次 DB 查询
{
await ProcessItemAsync(item); // 串行执行，吞吐掉一半
}正确做法是用 Task.WhenAll 控制并发批次，同时保持流式内存友好：
- 用
BufferBlock<T>（来自System.Threading.Tasks.Dataflow）做生产者-消费者解耦 - 限制并行度：用
Parallel.ForEachAsync（.NET 6+）并设MaxDegreeOfParallelism - 若仍用
await foreach，提前批量化：var batch = items.Take(100).ToList()，再Task.WhenAll(batch.Select(ProcessItemAsync))
锁不是唯一瓶颈，ConcurrentDictionary 和 ImmutableArray 往往更轻量
高并发下盲目加 lock 或 Monitor 容易成为争用热点，尤其在短临界区（如更新计数器、查缓存）。ConcurrentDictionary 的 GetOrAdd 和 AddOrUpdate 是无锁设计，比手动 lock + Dictionary 快 3–5 倍（实测 .NET 6+）。
但要注意：
-
ConcurrentDictionary的枚举不是线程安全快照，遍历时可能漏项或重复；需要完整快照就用ToArray() - 高频小对象拼接（如日志上下文构建）用
ImmutableArray<T>.Builder比List<T>+ lock 更省 GC - 纯读多写少场景，考虑
Lazy<T>+ConcurrentDictionary组合，避免重复初始化
可读性妥协点要显式标注，比如用 [SkipLocalsInit] 或内联 Span<byte>
极致性能优化（如零分配序列化、Socket 缓冲区复用）必然牺牲可读性。这时别藏技巧，用编译器特性或注释明确意图：
- 用
[SkipLocalsInit]省掉栈上数组初始化开销，但必须确保所有分支都赋值，否则行为未定义 - 字符串解析优先用
ReadOnlySpan<char>+Span<byte>，避免Encoding.UTF8.GetBytes(str)分配；但只在 hot path 用，普通逻辑保持string - 在方法名或 XML 注释里写清权衡：“// ⚠️ 零分配，但要求 input.Length
最难的不是写出高性能代码，而是让半年后的自己或同事一眼看出哪行是“为吞吐让步”，哪行是“真不能动”。可读性和性能冲突时，边界一定要划清楚——模糊地带最容易出偶发超时或内存泄漏。
