为什么很多人都靠感觉选同步还是异步？按理说，

只要写过一段时间 Node。基本都纠结过这个问题，有人怕出事，干脆把接口里能写成异步的全写成异步；有人图省事，能同步就同步。这两种写法都曾导致你在生产环境里出现：请求延迟飙升、RT 高、并发吞吐下降。

说到痛点一。高并发时接口卡顿

当请求数量激增，主线程被同步阻塞后后续请求只能排队等待；最终导致页面渲染变慢甚至超时。

再看痛点二。线上日志中频繁出现“I/O 阻塞”报警

日志显示某些 API 在高峰期频繁触发 I/O 阻塞警报，这是因为代码里用了同步文件读取、数据库查询等操作。

先把 Node 的运行方式摆出来

Node 的主要是事件循环：主线程一次只能执行一条同步任务。只要有任何阻塞操作，它就会把所有请求一起拉住。

const fs = require;app.get => { const text = fs.readFileSync;res.send)，});

此处 readFileSync 会一直占用主线程；如果文件较大或磁盘 IO 慢，会导致整个服务瞬间不可用。

异步版本让文件读取放进 libuv 的工作线程池，从而不会阻塞事件循环。

同步不是禁忌，但别放进不该待的地方

Synchronous code can be fine if its scope is limited.

服务启动阶段。用同步很正常

const config = JSON.parse);按理说，

只执行一次且在监听之前完成。不影响并发请求，

单机脚本、内部工具，同步更顺手

数据迁移、批量文件处理等场景根本不关心并发；只要按顺序跑完即可，

轻量纯内存逻辑，本来就该同步

function mapUser { return { id:user.id。nickname:user.nickname,isVip:user.level>=5 };}

无 I/O。无网络延迟，这种逻辑天然就是同步语义。如果硬造成 async，只是让代码显得复杂却没有收益。

从但注意边界来看，即便是内存计算，也可能阻塞主线程

If you process large JSON structures or run heavy CPU loops inside a request handler。it will still block event loop. In that case consider moving it to a worker thread or making it asynchronous via Promise.resolve.n.

异步真正该上场的地方

数据库操作

app.get=>{const orders=await orderService.list;res.json，});

Redis / MQ / 第三方 HTTP 调用

文件读写

至于痛点三，文件上传大包导致所有请求卡死？

A single synchronous file write during an upload will hold up every or request until it's finished.

使用者接口里的耗时操作

• A1: 是否等待外部资源？—如果是请改为 async。
• A2: 是否在主请求链路上？—越靠近入口越需注意，
• A3: 是否可能拖慢整体吞吐？不过，—如果是必须拆分或改为非阻塞。
• A4: 属于启动期还是运行期？—启动期可宽松一点，但运行期应保守处理。

常见误区的观点是，把 “async/await” 当作默认答案

• "所有接口都必须全异步": 并非如此。参数校验、结果拼装等轻量动作可以保持同步，以减少不必要的 Promise 链和堆栈深度。
• "同步写法一定更差": 在低并发、本地测试或脚本里同步往往更直观、更易维护。 关键看它是否进入了并发方法。
• "写满 async 就代表工程规范": 真正的关键是代码是否正确处理错误与资源释放，而不是外观上的 async 标记。

说到决策表，何时用 sync / 异步

场景/职责域	建议做法	典型痛点说明
服务启动 & 配置加载 单机脚本 / 内部工具 轻量纯内存逻辑 数据库 CRUD & Redis/MQ 调用 文件上传/下载 面向使用者线上接口

读取配置 / 初始化模板 … Synchronous OK – 单次调用且在 listen 前完成！ 无堵塞风险；仅影响启动时间，

批量迁移 / 建立脚本 … Synchronous 优先 – 不关心并发！ 生产环境无影响，只需关注任务完成时间。

字段映射 / 简单判断 … Synchronous – 纯 CPU 无 I/O 无需额外 Promise 开销；保持简洁，

数据库 CRUD & Redis/MQ 调用 … Asynchronous – 必须非阻塞 否则全链路被锁住高并发下响应大幅度下降。

文件上传/下载 或 大规模读写 …

Asynchronous – 防止磁盘 I/O 阻塞  

同上，特别是在多使用者上传场景下容易卡顿。

面向使用者线上接口主方法 …

Prefer Asynchronous – 主方法尽量无阻塞  

This is where you feel RT spike instantly when blocking occurs.

场景/职责域 服务启动 & 配置加载 单机脚本 / 内部工具 轻量纯内存逻辑 数据库 CRUD & Redis/MQ 调用 文件上传/下载 面向使用者线上接口 建议做法 Synchronous OK – 单次调用且在 listen 前完成！Synchronous 优先 – 不关心并发！Synchronous – 纯 CPU 无 I/O Asynchronous – 必须非阻塞 Asynchronous – 防止磁盘 I/O 阻塞 Prefer Asynchronous – 主方法尽量无阻塞

典型痛点说明 无堵塞风险；仅影响启动时间，生产环境无影响，只需关注任务完成时间。无需额外 Promise 开销；保持简洁，否则全链路被锁住高并发下响应大幅度下降。同上，特别是在多使用者上传场景下容易卡顿。这是当你发现 RT 飙升时最常见的问题。

请根据自己的业务情形和实际流量自行调整此表，仅供参考。

最终的

• SYNCHRONOUS： 适合一次性初始化、单机脚本及极小体积内存运算。不应落入高并发 API 的主链路中，否则会拖慢整个程序响应速度。

A SYNCHRONOUS CODE BLOCKING THE EVENT LOOP IS THE REAL BUG — 而不是“它叫 sync”。这就是为什么需要清晰地识别哪些地方应该变成 Async 的原因之一。

请你现在思考以下问题：

是否正在等待外部资源?

它位于 API 主执行链路上吗?

它是否可能拖慢整体吞吐?

它属于启动阶段还是运行期间?按理说，

---

一句话 ： 先判断这段代码会不会堵住别人。再决定它该不该写成 synchronous。

---

---