Node.js exec 报 stdout maxBuffer length exceeded

Node 调用命令行工具读取 JSON，数据一多就报 ERR_CHILD_PROCESS_STDIO_MAXBUFFER，错误中带着 stdout maxBuffer length exceeded。这时子进程可能已经启动并输出了结果，失败发生在父进程收集输出的阶段。先核对错误码和超限的那一路输出，再决定减少结果、增加有限缓冲，还是改用流式处理。

同一种错误也可能指向 stderr。不能只因为业务结果写在 stdout，就忽略工具另外输出的大量诊断日志。

限制计算的是字节

exec() 和 execFile() 会收集子进程的 stdout、stderr，随后把结果交给回调。两路分别受 maxBuffer 限制。已核对的 Node.js 24.10.0 默认值为 1024 * 1024 字节；旧版默认值可能不同，应按运行版本确认。

超过限制后，Node 会终止子进程并截断输出。返回的那一段 JSON 不一定完整，不能捕获错误后照常解析，再把解析失败当成另一项独立故障。中文等非 ASCII 文本的字节数还可能大于字符数，字符串的 length 不能直接用来判断是否超过这个字节上限。

先记录实际 Node 版本、调用接口、错误码和命令的输出规模。应用若用了 Promise 封装库，还要检查这个库如何传递选项；Node 原生支持 maxBuffer，不代表任意封装都接收同名参数。分享日志时移除令牌、配置内容及业务数据。

只需要少数字段时，减少命令输出

例如读取 Kubernetes 对象后只取名称，没有必要先把全部对象 JSON 送回 Node。可以按目标工具支持的查询或过滤参数，让它只输出需要的字段。输出格式改变后，解析代码必须一起修改。

还需分清 Promise 返回值。原生 execFile 经 promisify 包装后，成功结果是包含 stdout、stderr 的对象。对整个结果调用 split() 会得到新的类型错误。应从 result.stdout 取文本，再按实际输出格式处理；若使用其他库，以那个库的返回结构为准。

减少输出并不能保证无限增长的数据永远小于上限，但通常能先去掉业务根本不用的内容。

已知结果有上界，再调整 maxBuffer

下面演示原生接口的选项位置。它启动当前 Node，只输出一行固定文本；5 * 1024 * 1024 用于展示有限字节值的写法，不是所有任务的推荐容量：

const { execFile } = require('node:child_process');

execFile(
  process.execPath,
  ['-e', 'process.stdout.write("ready\\n")'],
  { maxBuffer: 5 * 1024 * 1024 },
  (error, stdout) => {
    if (error) {
      console.error(error.code, error.message);
      return;
    }
    console.log(stdout.trim());
  }
);

替换成实际工具时，保留已核对的程序路径、参数、cwd 和环境设置。根据最大结果规模及并发数量确定上限；每个调用都会占用内存，不能只考虑单次执行。不要把 Infinity 当成常规处理办法。

若结果无法合理限定，采用异步 spawn()，在产生数据时消费 stdout 和 stderr，并限制下游队列或落盘规模。两路管道都需要处理，避免一边未消费而阻塞。不能换成 spawn 后仍把所有块无界拼回内存，也不能期待给 spawn 加 maxBuffer 就自动获得 exec 的收集上限。

从原命令检查完整结果

在受控环境用正常数据和预计最大数据重跑，核对退出状态、完整结果和业务解析。stderr 很大的失败路径也需要检查。错误消失但数据缺项，仍不算成功。

命令若可能写入外部系统，超限只说明父进程收集失败，不证明子进程什么都没做。重跑前核对完成记录，避免重复执行。若实际错误是程序启动前的 ENOENT，参见execFile 的路径与 cwd 检查。