Parallel.ForEachAsync要求ValueTask时如何优雅传入返回Task的方法

Parallel.ForEachAsync要求body委托返回ValueTask，核心目的是降低高并发场景下的异步操作堆分配开销，但C#编译器在处理方法组转换时，不会自动将返回Task的方法包装为返回ValueTask的委托，因此直接传入返回Task的方法组会报编译错误。

不需要修改存量方法的返回类型，也不需要写冗余的多行lambda，有两种非常简洁的适配方案：

方案1：通用辅助方法（全场景复用，推荐） #

在项目的公共静态工具类中定义一次泛型适配方法：

static Func<T, CancellationToken, ValueTask> ToValueTaskBody<T>(Func<T, CancellationToken, Task> asyncFunc)
    => async (item, ct) => await asyncFunc(item, ct).ConfigureAwait(false);

定义完成后，所有调用Parallel.ForEachAsync的场景都可以直接复用，写法和直接传方法组几乎一致：

await Parallel.ForEachAsync(
    source: numbers,
    parallelOptions: new ParallelOptions{ MaxDegreeOfParallelism = 2 },
    body: ToValueTaskBody(WorkAsync));

该方案的优势：

• 一次定义全项目复用，不需要每次重复写lambda逻辑
• 内置ConfigureAwait(false)，避免不必要的同步上下文捕获，性能符合最佳实践
• 行为和手写async lambda完全一致，没有兼容问题

方案2：单行ValueTask构造（零额外状态机开销） #

如果是在控制台、ASP.NET Core这类本身不存在同步上下文的场景运行，不需要额外处理上下文捕获，可以直接用ValueTask的构造函数包装Task返回值，连async/await都不需要写：

await Parallel.ForEachAsync(
    source: numbers,
    parallelOptions: new ParallelOptions{ MaxDegreeOfParallelism = 2 },
    body: (item, ct) => new ValueTask(WorkAsync(item, ct)));

该写法不会生成async状态机，运行开销比async lambda更低，代码长度也和直接传方法组非常接近。唯一需要注意的是：如果工作方法会在第一个await执行前同步抛出异常，异常会被直接封装到并行操作的聚合异常中，和async/await的异常传播行为有极细微差异，标准async写法的工作方法不存在这个问题。

避坑提示 #

• 不要为了适配强行修改存量方法返回值：ValueTask的设计目标是优化高频、大概率同步完成的异步操作，对于普通业务场景中大概率会真正等待IO/延迟的方法，返回Task反而更符合设计规范，强行修改会增加不必要的维护成本。
• 不推荐使用多行lambda的写法：既会增加代码嵌套层级，也容易遗漏ConfigureAwait(false)配置，长期维护性差。

内容的提问来源于stack exchange，提问作者tmaj