为Task<IEnumerable<T>>编写类LINQ扩展方法是否存在副作用？

我对如下场景的括号嵌套感到困扰：
var items = (await SomeService.GetDataAsEnumerableAsync()).ToList();
因此考虑编写如下扩展方法：

public static class TaskEnumerableExtensions
{
    public static async Task<T> FirstAsync<T>(this Task<IEnumerable<T>> task)
    {
        return (await task).First();
    }

    public static async Task<T?> FirstOrDefaultAsync<T>(this Task<IEnumerable<T>> task)
    {
        return (await task).FirstOrDefault();
    }
}

这样就能写成var items = await SomeService.GetDataAsEnumerableAsync().ToListAsync();。但我担心存在潜在副作用，想了解：

• 这类扩展方法是否合法？
• 是否会改变TPL核心行为（如异常处理）？
• 在循环中使用是否会产生明显开销？

1. 扩展方法的合法性 #

这类扩展方法完全合法。C#扩展方法允许为已有类型（此处为Task<IEnumerable<T>>）添加静态形式的"实例方法"，只要满足定义在静态类、第一个参数带this关键字的规则即可，你的实现完全符合语法规范，不会出现编译错误。

需要注意命名冲突风险：如果后续.NET类库或第三方库提供了同名的FirstAsync/FirstOrDefaultAsync扩展方法，可能会引发二义性，此时需通过显式调用静态类方法解决（例如TaskEnumerableExtensions.FirstAsync(task)）。

2. 对TPL核心行为的影响（含异常处理） #

不会改变TPL的核心行为，异常处理逻辑与直接写(await task).First()完全一致：

• 原任务抛出的异常：await task会自动解包AggregateException并抛出底层具体异常，和直接调用的行为无差异；
• 枚举方法自身的异常（比如First()在空序列时抛出InvalidOperationException）：会正常抛出，逻辑和直接调用一致；
• 任务取消场景：原任务被取消时，await task会抛出TaskCanceledException，与原生使用逻辑相同。

本质上，你的扩展方法只是封装了"await任务+调用枚举方法"的逻辑，未修改TPL的任务调度、异常传播等核心机制。

3. 循环中的开销 #

这类扩展方法的开销可以忽略：

• 每次调用仅多一层静态方法调用，以及async/await状态机的极小开销。现代.NET运行时对async/await优化成熟，尤其是当await的任务已完成时（常见场景），状态机几乎无额外消耗；
• 与直接写(await task).First()相比，两者执行逻辑完全等价，扩展方法只是语法层面的封装，无额外内存分配或计算成本。

除非是极端高频的循环场景（如每秒数百万次调用），否则日常业务中完全感受不到差异。

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