Node.js可读流close事件处理器调用机制及代码逻辑疑问

先看你提到的代码：

const fs = require('fs')

const readableStream = fs.createReadStream(__filename)
readableStream.close()

readableStream.on('close', () => {
    console.log('Stream closed')
})

这段代码确实会输出Stream closed，核心原因在于Node.js流的close()方法是异步触发关闭流程的，不是同步执行完就触发事件，这就给了你绑定监听器的时间窗口。下面拆解细节：

1. close()内部的逻辑 #

调用可读流的close()时，它并不会立即关闭流并触发事件：

• 首先标记流为「正在关闭」的状态，停止接收新的读取请求
• 向底层的文件描述符发起关闭请求，但这个IO操作是异步的，不会同步完成
• 把实际的关闭收尾逻辑（包括触发close事件）安排到事件循环的后续阶段，不会阻塞当前同步代码

2. on()内部的逻辑 #

on()是Node.js EventEmitter的核心方法，它的工作很直接：

• 将你传入的回调函数添加到对应事件（这里是close）的监听器列表中
• 因为此时close事件还没被触发，所以只是单纯完成监听器注册，不会立即执行回调

3. close事件回调何时进入事件循环队列？ #

当底层文件描述符真正完成关闭后，流的内部逻辑会把close事件的触发任务，添加到事件循环的close回调阶段（这个阶段专门处理资源关闭后的清理操作）。

而你绑定监听器的代码是在当前同步执行栈中运行的，会先于事件循环的close阶段任务执行，所以回调能被正常注册到监听器列表里，等事件触发时就会被执行。

完整执行顺序梳理 #

1. 同步执行：创建可读流实例，调用close()发起关闭请求（仅标记状态，未触发事件）
2. 同步执行：调用on('close')，将回调添加到监听器列表
3. 当前同步执行栈清空，事件循环进入后续阶段
4. 进入close阶段，执行流的关闭收尾逻辑，触发close事件，遍历监听器列表执行你的回调，输出Stream closed

内容的提问来源于stack exchange，提问作者russell.price