直接fs.readFileSync会爆内存，因其将整个大文件一次性加载进V8堆内存，触发JavaScript heap out of memory错误；应改用fs.createReadStream配合csv-parse流式处理，并严格控制highWaterMark、解析选项与背压。
为什么直接 fs.readFileSync 会爆内存
读取几百MB以上的CSV或JSONL文件时，fs.readFileSync 把整个文件一次性加载进V8堆内存，极易触发 FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory。这不是VSCode的问题，而是Node.js进程本身的内存限制（默认约1.4GB）。即使你调高了 --max-old-space-size，也掩盖不了“全量加载→全量解析→全量驻留”的低效本质。
fs.createReadStream + csv-parse 流式处理实操要点
流式读取不是加个 pipe 就完事，关键在控制缓冲和错误传播：
- 必须设置
highWaterMark：例如fs.createReadStream("data.csv", { highWaterMark: 64 * 1024 })，避免底层Buffer无节制堆积；默认值（64KB）对大文件偏小，但设太大（如1MB）反而拖慢响应 -
csv-parse的delimiter、columns、skipEmptyLines要显式声明，否则默认行为会尝试推断表头并保留空行，增加解析开销 - 别在
for await循环里做同步阻塞操作（如JSON.stringify写文件），否则背压失效，内存持续上涨 - 示例片段：
const parser = fs.createReadStream("huge.csv").pipe(parse({ delimiter: ",", columns: true, skipEmptyLines: true }));<br>for await (const row of parser) {<br> // 每次只处理一条记录，内存恒定<br> processRow(row);<br>}
VSCode里调试流式脚本的两个硬坑
你在VSCode里跑流式Node脚本，容易卡死或断点失效，原因很具体：
Comprehensive Three.js 3D graphics reference
下载
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
- VSCode的调试器默认启用
node --inspect，而流式处理中大量异步事件会触发调试器频繁暂停，导致for await看似卡住——实际是调试器在逐帧捕获事件循环，关掉“所有异步断点”或改用console.log打点更可靠 - 终端输出被VSCode的集成终端缓冲，尤其用
process.stdout.write时可能延迟显示，加process.stdout.setEncoding("utf8")和process.stdout.write("\n")强制刷新 - 若用
npm run dev启动带热重载的脚本（如ts-node + nodemon），流式读取中途重启会导致文件句柄未释放，报错EBADF: bad file descriptor，应改用纯node命令执行
JSONL比CSV更省心？不，它有隐性陷阱
JSONL（每行一个JSON对象）看似结构简单，但实际比CSV更容易出问题：
- 单行超长JSON（比如嵌套很深的日志）会撑爆
readline默认的maxBufferSize（16KB），需手动设为{ maxBufferSize: 1024 * 1024 } - JSON.parse() 同步执行，若某一行格式错误，整个流就中断——必须用
try/catch包裹每一行，且不能只console.error，得调用stream.destroy(new Error(...))主动终止，否则残留数据会卡在内部Buffer里 - VSCode打开JSONL文件本身就会尝试语法校验，占用CPU；建议用
code --read-only --disable-extensions huge.jsonl配合命令行处理，而非在编辑器里双击打开
真正难的不是写对第一行流式代码，而是让整个链路（读取→解析→转换→输出）始终处于可控背压下。一旦某个环节阻塞（比如写磁盘太慢），前面的ReadStream就会缓存越来越多数据，直到OOM。监控 process.memoryUsage().heapUsed 是唯一验证方式，别信“看起来没卡”。
