Node.js中声明长变量及完整存储大PDF Base64字符串的方法

让我逐个帮你解决这两个Node.js相关的问题：

其实Node.js（基于V8引擎）对变量的大小并没有严格的硬性上限——只要你的系统内存足够，就能存储很长的字符串、大Buffer或者其他数据类型。不过具体怎么处理，要看你存储的数据类型：

• 长字符串：直接赋值就行，比如 const longString = "..."，哪怕是几十MB的Base64字符串都没问题，只要内存吃得消。
• 二进制大数据：更推荐用Buffer或者Uint8Array，它们是专门处理二进制数据的类型，比纯字符串更高效。比如读取大文件时可以用fs.readFileSync返回Buffer：const largeBuffer = fs.readFileSync('./big-file.pdf');
• 超大规模数据：如果数据大到内存都装不下（比如几百GB的文件），别一次性存在变量里，用**流（Stream）**来分段处理，这样不会占满内存，性能也更好。

你遇到的问题大概率是child_process.exec()的缓冲区限制导致的——exec会把子进程的stdout/stderr输出全部缓存到内存里，但它有一个默认的maxBuffer限制（默认是1MB），当你的输出超过这个大小，就会被自动截断，导致你拿到的是不完整的字符串。

这里有两个靠谱的解决办法：

方案1：增大exec的maxBuffer参数 #

直接在调用exec时指定更大的maxBuffer值，比如你的PDF是15MB，Base64编码后会比原文件大33%左右（大概20MB），所以把maxBuffer设为2510241024（25MB）就足够覆盖：

const { exec } = require('child_process');
exec('java -jar .....some variables', { maxBuffer: 25 * 1024 * 1024 }, function (error, stdout, stderr) {
  if (error) {
    console.error(`执行出错: ${error}`);
    return;
  }
  // 先打印长度确认是否完整
  console.log('Base64字符串总长度:', stdout.length);
  const data = { base64PdfString: stdout };
  // 这里再处理data就没问题了
});

注意：如果后续文件还会更大，这个方法就不太合适，因为还是会把整个字符串加载到内存里，可能导致内存占用过高。

方案2：改用child_process.spawn()处理流 #

spawn是流式处理子进程输出的API，不会一次性缓存所有数据，更适合大文件场景。你可以分段接收stdout的数据，再拼接成完整的字符串：

const { spawn } = require('child_process');
const javaProcess = spawn('java', ['-jar', '.....some variables']);
let base64String = '';

// 分段接收数据
javaProcess.stdout.on('data', (chunk) => {
  base64String += chunk.toString();
});

// 所有数据接收完成
javaProcess.stdout.on('end', () => {
  console.log('完整Base64字符串长度:', base64String.length);
  const data = { base64PdfString: base64String };
  // 继续后续的PDF生成逻辑
});

// 处理错误输出
javaProcess.stderr.on('data', (err) => {
  console.error(`子进程错误输出: ${err}`);
});

javaProcess.on('error', (err) => {
  console.error(`启动子进程失败: ${err}`);
});

这个方法更健壮，不管文件多大，都不会一次性占满内存。

另外还要排查一个小坑：你用console.log('Output value -> ' + stdout)的时候，终端可能因为自身的显示限制截断了输出，但实际变量stdout是完整的。你可以先打印stdout.length看看长度是否符合预期，再判断是不是真的截断了。

内容的提问来源于stack exchange，提问作者coder