JavaScript中是否应将所有函数设为async？存在哪些问题与弊端？

嘿，这个问题问得特别实在——毕竟async/await用起来太顺手了，谁不想统一代码风格呢？不过真把所有函数都改成async，可会踩不少坑，不管是Node.js服务端还是转译后的客户端场景，都有不少需要注意的问题，给你一一梳理：

• 不必要的性能开销：async函数的本质是返回一个Promise，哪怕函数内部完全是同步逻辑，JS引擎也会额外创建Promise对象并调度微任务。对于高频调用的函数（比如循环内的工具函数、频繁触发的事件处理函数），这种累积的开销会明显影响性能——在Node.js高并发场景下可能降低吞吐量，在客户端则可能拖慢页面渲染或交互响应速度。比如：

  // 同步版本，直接返回值
  function add(a, b) { return a + b; }
  // async版本，强制包装为Promise
  async function addAsync(a, b) { return a + b; }
  

  每次调用addAsync都会生成一个新的Promise，带来额外的内存分配和调度成本。

• 破坏返回值兼容性：普通函数返回原始值或普通对象，而async函数必然返回Promise。如果盲目把所有函数改成async，现有代码中直接使用返回值的逻辑会全部失效——比如const res = myFunc()拿到的不再是预期的值，而是Promise对象，必须添加await或.then()才能获取结果。这种改动会引发大量兼容性bug，尤其是在和非async代码混合调用的场景中。

• 错误处理逻辑复杂化：同步函数的错误会直接抛出，而async函数的错误会被包装为Promise的reject状态。如果所有函数都是async，你需要在每一处调用都用try/catch包裹，或者链式调用.catch()，哪怕是原本可以同步处理的错误（比如参数校验失败、类型错误）。未处理的Promise rejection在Node.js中可能导致进程退出，在客户端会触发控制台报错，大幅增加调试和维护的复杂度。

• 调试体验下降：异步调用栈相比同步调用栈会包含大量Promise相关的冗余帧，当所有函数都是async时，错误栈会变得冗长且难以追踪。比如同步函数抛出错误时，调用栈能直接指向出错的代码行；而async函数的错误栈会夹杂Promise.then、asyncGeneratorStep等无关信息，定位问题需要花费更多时间。

• 违背语义化原则：async函数的核心语义是“该函数包含异步操作”，如果一个完全同步的函数被标记为async，会误导其他开发者认为它内部存在异步逻辑，增加代码的理解成本。保持同步函数的原样，能让代码的意图更清晰，符合“代码即文档”的最佳实践。

• 客户端转译后的体积膨胀：在客户端场景中，使用Babel等工具转译async/await时，会引入额外的辅助代码（如regeneratorRuntime）。如果大量同步函数被转为async，这些辅助代码的体积会显著增加，尤其是在tree-shaking不充分的情况下，会导致打包后的JS文件变大，影响页面加载速度。

总的来说，async/await是Promise的优秀语法糖，但只应该在确实包含异步操作的函数中使用。保留同步函数的原生形态，既能避免上述问题，又能让代码的性能、可读性和可维护性达到平衡。

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