Node.js 同步代码阻塞事件循环通常由 CPU 密集计算或同步 I/O 引起，定位瓶颈需使用性能分析工具检测事件循环延迟，并通过 Worker Threads 或异步化改造解决。适用场景为高并发 API 服务出现随机超时且 CPU 使用率异常升高，风险边界在于重构同步代码可能引入新的异步复杂度。
先说结论：解决 Node.js 事件循环阻塞的核心是识别耗时同步操作并将其移出主线程，优先使用异步 API 或 Worker Threads 处理 CPU 密集任务。
- 先定位：使用 clinic.js 或 node `--inspect` 抓取火焰图，确认阻塞代码行号。
- 先做：将同步文件系统调用改为异步，将复杂计算移至 worker_threads。
- 再验证：监控事件循环延迟日志，确认请求超时错误消失且 P99 延迟下降。
命令速用版
以下命令用于快速启动性能分析或检测事件循环延迟，需在测试环境执行。
启动 inspect 模式：
node `--inspect-brk` app.js
使用 clinic.js 诊断：
npx clinic doctor -- node app.js
检测事件循环延迟脚本：
在代码中插入 setInterval 检查时间差，大于阈值即打印警告。
为什么会这样
Node.js 采用单线程事件循环模型，同步代码执行期间无法处理其他 I/O 回调。
当主线程执行同步代码（如大型 JSON 解析、同步文件读取、复杂正则匹配）时，事件循环停止转动，新的请求回调无法进入执行栈，导致外部客户端等待超时。CPU 密集任务会导致单核满载，I/O 阻塞会导致请求堆积。
分步处理
步骤 1：监控事件循环延迟
在应用启动时添加监控代码，记录每次循环实际耗时与预期耗时的差值。若差值持续超过阈值，说明存在阻塞。
步骤 2：抓取性能火焰图
使用 clinic.js 或 0x 工具在压测期间生成火焰图。观察调用栈中占比最高的同步函数，定位具体代码行号。
步骤 3：重构阻塞代码
对于 I/O 操作，替换为 async/await 或 Promise 版本 API。对于 CPU 计算，使用 worker_threads 模块创建子线程处理，通过 message 端口通信。
步骤 4：设置超时保护
为耗时任务设置独立超时逻辑，避免单个请求拖死整个进程，必要时使用进程管理器自动重启异常进程。
怎么验证是否生效
查看应用日志中事件循环延迟警告是否减少或消失。使用压测工具对比优化前后的 P99 响应时间，确认请求超时错误率降至正常水平。观察服务器 CPU 使用率是否从单核满载变为多核分担或整体下降。
常见坑
大对象 JSON 序列化：JSON.stringify 处理大型对象是同步且耗时的，建议在 Worker 中处理或流式处理。
同步数据库驱动：部分旧版数据库驱动提供同步方法，务必确认使用的是异步回调或 Promise 接口。
正则回溯：复杂的正则表达式在特定输入下会产生灾难性回溯，阻塞主线程，需优化正则或使用专用库。
日志同步写入：高频同步写入日志文件会阻塞 I/O，应使用异步日志库或写入 stdout 由进程管理器收集。
常见问题
Worker Threads 和 child_process 有什么区别？
Worker Threads 共享内存适合 CPU 密集计算，child_process 独立进程适合隔离不稳定任务。
事件循环延迟多少算正常？
公开资料中没有看到可靠的量化数据，通常建议控制在较低水平以避免感知卡顿。
异步代码一定会避免阻塞吗？
不一定，异步回调内部如果包含同步计算，依然会阻塞事件循环。
参考来源
Node.js 官方文档 - Event Loop
Node.js 官方文档 - Worker Threads
Clinic.js 官方文档 - Performance Diagnosis