返回Promise时是否需加async修饰？两种写法哪种更规范？

这个问题问得很务实，两种写法都能正常工作，但背后藏着一些值得注意的细节差异，咱们一步步捋清楚：

1. 行为上的细微区别 #

• 对于示例2（普通函数返回Promise）：如果函数内部抛出同步错误（比如调用未定义的函数、访问null的属性这类），会直接抛出同步异常，调用者必须用try/catch捕获，没法通过Promise的.catch()处理。
• 对于示例1（async函数）：任何同步错误都会被自动包裹成rejected状态的Promise，调用者可以统一用.catch()或者await + try/catch处理，不需要区分错误是同步还是异步产生的。

举个直观的例子：

// 示例2：同步错误直接抛出，无法通过Promise捕获
function fetching() {
  const a = null;
  a.b; // 触发同步TypeError
  return fetch('someUrl');
}
fetching(); // 直接抛出错误，不会进入后续的.catch()

// 示例1：同步错误被自动转为Promise拒绝
async function fetching() {
  const a = null;
  a.b; // 同步错误被包装成Promise.reject
  return fetch('someUrl');
}
fetching().catch(err => console.log(err)); // 能正常捕获到TypeError

2. 性能上的微小差异 #

async函数会多一层Promise的包装逻辑（哪怕你返回的已经是Promise），这会带来极其微小的性能开销——在绝大多数业务场景下，这点开销完全可以忽略不计。只有当这个函数被数百万次高频调用时，才需要考虑这点差异。

3. 可读性与团队协作 #

• 加async前缀能明确传递异步语义：看到async function，调用者不用看函数内部逻辑，立刻就知道这是一个异步函数，会返回Promise，能直接用await或者.then()调用。
• 团队协作时，统一风格比纠结写法更重要：如果团队约定所有异步函数都加async，那哪怕是直接返回Promise的函数也跟着加，能减少认知成本；如果团队习惯只在用到await时才加，那也可以遵循这个约定。

结论：哪种写法更恰当？ #

• 如果你的函数未来可能会添加await逻辑，或者需要把同步错误统一转为Promise拒绝，优先选示例1（加async），更稳妥。
• 如果只是纯粹转发一个Promise，且完全确定不会有同步错误，同时追求极致性能（这种场景极少），可以选示例2。
• 从可读性和维护性的角度，我个人更推荐示例1——额外的async前缀能清晰传递异步语义，避免后续维护时的误解，这点好处远大于那点可忽略的性能开销。

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