Node.js 使用 fs 模块异步读取大文件导致事件循环阻塞怎么改用流？

当 Node.js 使用 fs.readFile 读取大文件时，整个文件内容会一次性加载到内存，容易引发内存峰值并在回调处理时阻塞事件循环。改用 fs.createReadStream 流式读取可以分块处理数据，利用背压机制避免内存溢出和长时间阻塞。

先说结论：对于超过几兆或大小未知的文件，必须使用流式读取替代全量读取。

先定位：确认文件体积是否可能超过可用内存或导致处理延迟。
先做：将 fs.readFile 替换为 fs.createReadStream 并配合流式处理逻辑。
再验证：监控进程内存峰值和事件循环延迟是否下降。

快速处理思路

直接使用 fs.createReadStream 创建可读流，通过 pipe 方法对接目标写入流，或使用 async iterator 逐块读取。

const fs = require('fs');
const stream = fs.createReadStream('large-file.txt');

stream.on('data', (chunk) => {
  // 处理数据块
});
stream.on('end', () => {
  // 读取完成
});
stream.on('error', (err) => {
  // 处理错误
});

为什么会这样

fs.readFile 需要等待文件完全读取后才返回回调，期间占用连续内存。

流式读取将文件分割为 chunk，读一块处理一块，避免单次内存分配过大。Node.js 官方文档指出，readFile 会将整个文件加载到缓冲区，而流允许逐步处理数据。

分步处理

按以下步骤将全量读取重构为流式读取，确保每一步都有回滚方案。

引入模块：使用 require('fs') 或 import fs from 'fs'。
创建流：调用 fs.createReadStream(path, options)。
绑定事件：必须监听 data、end 和 error 事件，防止未捕获异常。
处理背压：如果使用 writable 流，使用 pipe 自动处理背压；如果是自定义逻辑，检查 write() 返回值。

怎么验证是否生效

通过监控内存使用和事件循环延迟来确认优化效果。

检查内存：在代码中打印 process.memoryUsage().rss，观察峰值是否降低。
检查延迟：使用 clinic.js 或手动记录事件循环起止时间差。
日志观察：确认没有 Out Of Memory 错误且文件处理完整。

常见坑

流式处理容易忽略错误监听和背压控制，导致进程崩溃或内存泄漏。

忽略 error 事件：流抛出错误时若不监听 error 事件，Node.js 进程会直接退出。
同步处理数据块：在 data 事件回调中执行耗时同步操作仍会阻塞事件循环。
编码问题：读取文本文件时未指定 encoding 可能得到 Buffer 而非字符串。

常见问题

fs.readFile 和 fs.createReadStream 性能区别是什么？

readFile 适合小文件，流适合大文件。

readFile 一次性加载，内存占用高；流分块加载，内存占用稳定。公开资料中没有看到可靠的量化数据表明具体阈值，通常建议文件较大时使用流。

小文件也需要改用流吗？

小文件不需要，readFile 代码更简洁。

对于几 KB 或几百 KB 的文件，readFile 的开销更小且代码易维护。流式处理主要解决大文件内存和背压问题。

参考来源

Node.js 官方文档 - fs.readFile: https://nodejs.org/api/fs.html#fsreadfilepath-options-callback
Node.js 官方文档 - fs.createReadStream: https://nodejs.org/api/fs.html#fscreatereadstreampath-options
Node.js 官方文档 - Stream: https://nodejs.org/api/stream.html