Node.js — process.exit() 截断管道输出

症状

　　只在管道之后才存在的截断就是指纹：管道接 cat 落盘后 tail 查看结尾，JSON 在对象中间戛然而止；而终端直接运行同一命令却输出完整——tty 写入的同步性掩盖了竞态。在 exit 前插一行诊断即可看见机制：打印 process.stdout.writableLength，非零的排队字节数就是铁证，process.exit(0) 紧随其后把这些字节直接杀死。

诊断思路

　　先用“管道落盘 + 查看结尾字节”复现截断并与终端直跑对比，确认是管道专属问题；再全局 grep process.exit，每一次紧跟在 write 之后的调用都是在操作系统刷完之前砍掉队列的嫌疑人；最后在关键位置输出 writableLength，量化退出时刻仍在排队的字节。catch 块里在异步写回调执行前就 exit 的代码，以及未 await 的 stream pipeline，是两个高频藏身处。

根因

　　process.exit() 同步地立即终止进程，不会等待挂起的异步写入排空。stdout 接管道时写入是异步且带缓冲的，退出时刻仍停留在可写队列里的字节永远到不了读者手里，输出于是被截断。

修复与验证

　　常规完成路径删除 process.exit，让事件循环在流结束后自然收尾；必须显式传递退出码时用 process.exitCode 记录、循环排空后自动应用，错误语义不变。确需立即退出的场景，先 await write 回调或 stream.pipeline 完成再 exit。验证时对比两种执行模式的字节数：终端直跑与管道接 cat 必须逐字节一致，重复多次；再压测一个比管道缓冲大数 MB 的负载覆盖内核级背压；最后强制失败路径，断言 $? 仍为 1，证明等待排空的关停没有牺牲错误码语义。

代码示例

node gen.js | cat > out.json
tail -c 32 out.json
# {"rows":[{"id":997,"name":"r…   <- ends mid-object

process.stdout.write(payload);
console.error('queued bytes:', process.stdout.writableLength);
process.exit(0); // kills the queue above

async function main() {
  process.stdout.write(payload);
  // no exit call: loop ends when stdout finishes
}
main().catch((err) => {
  console.error(err);
  process.exitCode = 1; // recorded, applied after drain
});

await new Promise((resolve) => process.stdout.write(payload, resolve));
process.exit(exitCode);