Node.js如何调度同步与异步任务？判定规则及对应API有哪些？

根本不存在主线程运行时动态扫描代码、自动判定某段逻辑要异步执行的机制，一段代码是同步跑还是进异步队列，完全由你调用的API本身的底层实现决定，核心判断维度有三个：

• 调用的是否是天生异步的IO类API：所有涉及文件读写、网络通信、硬件交互这类慢IO操作的API，底层会把实际IO操作交给libuv管理的线程池或者操作系统内核异步接口（比如epoll、kqueue）处理，调用时只会在主线程完成参数校验、请求提交，就立刻往下执行后续同步代码，不会等IO结果返回。等IO操作实际完成后，对应的回调函数才会被塞进事件循环的对应任务队列，等主线程同步调用栈完全清空后再执行。
  举个最直观的对比：

  // 同步API：直接在主线程等文件读完，赋值完成才会走下一行
  const content = fs.readFileSync('./test.txt')
  console.log('同步读完成')
  // 异步API：提交读请求后立刻走下一行，回调要等同步栈空了才会执行
  fs.readFile('./test.txt', (err, content) => {
    console.log('异步读完成')
  })
  console.log('异步请求已提交')
  // 最终输出顺序：同步读完成 -> 异步请求已提交 -> 异步读完成
  

• 是否显式调用了任务调度API：哪怕是纯CPU计算的逻辑，只要你主动用setTimeout、setImmediate、queueMicrotask、process.nextTick这类调度方法包裹，就会被按规则塞进对应的异步任务队列，等当前同步栈清空后再执行，不会在当前位置直接运行。
• 操作本身是否会阻塞事件循环：如果一个操作需要长时间占用主线程CPU、或者需要等待外部资源返回，官方不会默认把它做成同步API阻塞整个运行时，除非开发者主动选择带Sync后缀的同步版本。

常见误区：普通的同步逻辑（比如for循环遍历大数组、复杂计算、普通函数调用）不管执行耗时多长，都会一直占着主线程同步跑完，不会被运行时自动切到异步队列，这也是为什么CPU密集型逻辑会阻塞Node.js服务的原因。

Node.js核心模块的API设计有很明确的命名规则：所有阻塞主线程执行的同步IO类API，方法名都会带Sync后缀，不带后缀的同类API默认是异步实现。

常见同步API #

• 文件系统模块的同步方法：fs.readFileSync、fs.writeFileSync、fs.mkdirSync、fs.readdirSync、fs.statSync等所有带Sync后缀的fs方法
• 压缩、加密模块的同步计算方法：zlib.gzipSync、zlib.deflateSync、crypto.pbkdf2Sync、crypto.scryptSync、crypto.randomBytesSync
• 子进程模块的同步调用方法：child_process.execSync、child_process.spawnSync、child_process.execFileSync
• JavaScript语言内置的所有原生方法：比如JSON.parse、JSON.stringify、Array.map、Array.sort、循环遍历等基础语法逻辑全是同步执行

常见异步API #

• IO类异步方法：所有不带Sync后缀的fs方法（比如fs.readFile、fs.writeFile）、http/net模块的网络请求、连接监听、数据读写相关方法、stream流的所有数据读写、事件监听回调
• 事件循环调度类API：setTimeout、setInterval、setImmediate、process.nextTick、queueMicrotask，以及timers/promises模块提供的Promise版定时器
• 异步版工具方法：不带Sync后缀的zlib、crypto模块方法、dns.resolve等DNS查询方法、所有Promise封装的核心模块方法

异步API还会按执行优先级分成微任务队列、宏任务队列，不同队列的执行顺序有差异，但所有异步API的回调都不会在当前同步调用栈中直接执行

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