在async函数中返回手动创建未解决Promise是否属于反模式？

1. 第一个函数是否属于反模式？ #

不属于。
你这里使用new Promise是为了把基于回调的XMLHttpRequest接口封装为可等待的Promise对象，属于回调API转Promise的标准合理操作，没有多余的冗余封装，完全符合最佳实践。await拿到结果后直接返回blob的逻辑也非常清晰，不存在反模式问题。

2. 重构后的第二个函数是否不属于反模式？ #

是的，重构后的写法已经不属于反模式。
首先明确：Promise构造器反模式的核心是不必要的冗余封装，比如本身已经有现成的Promise实例可用，还额外套一层new Promise的情况，典型示例如下：

async function badDemo() {
  // 完全没必要包一层new Promise，直接return fetch('/xxx')即可
  return new Promise((resolve, reject) => {
    fetch('/xxx').then(resolve).catch(reject)
  })
}

你的场景里storageRef.put(blob).on()是基于回调的API，没有原生Promise支持，所以用new Promise封装是完全必要的操作，不存在冗余。
而你把原来的「直接返回手动创建的Promise」改成「await手动封装的Promise后再返回结果」的写法，优势有两个：

• 可读性更高：和普通async函数的执行逻辑保持一致，后续维护者可以一眼看清执行顺序，不需要额外理解你在async函数里直接返回Promise的逻辑
• 可维护性更好：如果后续需要添加上传完成后的后置操作（比如日志上报、额外数据处理），直接加在await之后即可，不需要修改封装的Promise内部逻辑

原来的第二个版本的写法虽然功能上没有问题，但属于不推荐的轻度反模式，会增加不必要的理解成本。

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