C#自定义Task扩展方法TaskMap的合理性及是否存在原生实现问询

1. 方法逻辑合理性与预期匹配度 #

你的TaskMap实现逻辑完全合理，和你预期的功能完全吻合：

• 不会改变原Task的执行时机：.NET 中绝大多数场景下异步方法返回的Task都是热启动的，你拿到扩展方法的task参数时它已经在调度执行了，await操作只是等待它执行完成，既不会触发也不会延后它的执行流程
• 原Task的所有状态都会正确透传：包括执行成功的返回值、抛出的各类异常、取消触发的OperationCanceledException，表现和直接使用原Task完全一致
• 当映射函数为x => x时，除了极小的async状态机构建、函数调用开销，最终的执行效果和直接赋值原Task没有差异

2. 同类官方/标准实现情况 #

基础类库（BCL）没有内置同名的TaskMap扩展，但有等价的原生实现方式和官方维护的标准扩展：

• 原生可以用ContinueWith方法实现等价逻辑，但直接使用ContinueWith需要手动配置TaskContinuationOptions才能匹配async/await的上下文捕获、异常传递行为，易用性和安全性远不如你写的async/await版本
• 由.NET Foundation官方维护的System.Linq.Async（异步LINQ标准库）包中，提供了针对Task<T>的Select扩展方法，功能和你的TaskMap完全一致，是业界通用的标准实现，用法如下：

  // 引用System.Linq.Async包后即可直接使用
  Task<int> originTask = Task.FromResult(10);
  Task<string> mappedTask = originTask.Select(x => x.ToString());
  

• 如果你在使用Rx.NET（响应式扩展），System.Reactive.Linq包中也提供了同样的Select扩展支持Task<T>的映射操作

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