先记住这个答案
exec 和 execFile 为完成回调收集标准输出与错误输出，maxBuffer 限制收集的字节数，超限会触发错误、截断输出并尝试终止子进程。Node 22 文档中的默认值为 1024 乘 1024 字节，不能按 JavaScript 字符串长度估算中文等多字节文本。少量且可预测的结果可以适当提高上限；持续日志或大型结果更适合 spawn 配合流式消费或文件输出。还要检查 stderr，避免只盯 stdout，并且不能把截断的结果当作完整业务数据。
- maxBuffer 约束的是字节数量
- stdout 与 stderr 都可能触发超限
- 大结果应改变消费方式，而不是无限加大缓存
先确认超限来自哪一条输出
工具可能把进度、警告或调试日志持续写到 stderr，即使 stdout 中只有很小的 JSON，也仍然可能超限。应检查工具的输出协议和日志选项，避免把诊断流误当作可以无限忽略的附属内容。
默认上限和错误表现应按实际 Node 版本核对。记录错误 code、所用预算和经过限量处理的摘要即可，不要在错误处理里再次打印巨量原始输出，否则诊断本身又会增加日志和内存压力。
中文文本要按编码后的字节估算
下面固定输出四十个汉字，其 UTF-8 大小超过四十字节。较小预算会失败，足够预算才能完整返回；这比用字符串 length 判断大小更能说明缓冲上限的实际单位。
超限后拿到的 stdout 可能只是前缀，不能继续作为完整 JSON、压缩数据或校验结果使用。业务层应把超限视为失败，明确是否重试、换输出方式或提示结果过大，而不是悄悄接受残缺内容。
import { execFile } from 'node:child_process';
export function collectText(maxBuffer: number): Promise<string> {
return new Promise((resolve, reject) => {
execFile(process.execPath, ['-e', 'process.stdout.write("汉".repeat(40))'], {
encoding: 'utf8', maxBuffer, timeout: 2000
}, (error, stdout) => {
if (error) reject(error);
else resolve(stdout);
});
});
}测试分别使用小于实际 UTF-8 字节数的上限和足够的上限，检查前者报超限、后者返回完整文本。示例不会宣称截断后具体保留几个字符，因为不应把截断细节当作业务协议。
持续或大型输出应采用不同的数据通道
改用 spawn 后，可以将数据接入支持背压的消费者或文件流，避免把整个结果留在内存里。但如果仍然把每个 chunk 拼进总字符串，只是换了 API，内存增长问题没有真正解决。
文件输出还需要明确容量、权限和清理策略；流式输出需要处理下游写入失败和子进程结束。选择哪种方式取决于结果如何被使用，不能只把 maxBuffer 设置成极大值来掩盖未知数据规模。
容易答错的地方
- 按照字符数设置缓冲上限
- UTF-8 中汉字通常占多个字节，JavaScript 字符串长度也不等于编码后的字节数。应使用适当编码的字节长度估算，并为协议和换行预留预算，不能用屏幕上看见的字符数量直接推导内存限制。
- 超限后继续解析返回的 stdout
- 输出可能被截断，部分数据看起来可读也不代表完整。应先检查调用是否成功，再验证内容协议；把失败结果当作成功缓存会把偶发输出过大变成持续的数据一致性问题。
面试官还会怎么问？
只监听 execFile 的 stdout 就能绕过 maxBuffer 吗？
不能据此假定完成回调的收集限制消失。需要大规模流式处理时应选择与目标一致的接口和消费方式，明确是否仍有内部或业务层累计，不能只增加一个 data 监听器就宣布不再缓冲。
maxBuffer 和流的 highWaterMark 是一回事吗？
不是。maxBuffer 是这些收集输出接口的总量预算，highWaterMark 通常参与流缓冲与背压阈值管理。二者的作用范围和触发行为不同，不能通过调整一个就假设另一个限制也改变。
提高上限前应该检查哪些信息？
确认正常结果最大字节数、stdout 与 stderr 的用途、并发任务数量和可用内存。若输出规模没有合理上界，应优先改为流或文件处理，再设计取消、失败和产物完整性校验。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。