说实话，每次 code review 看到Runtime.getRuntime().exec(cmd)这种写法，我都会多停几秒。如果 cmd 还是字符串拼接出来的，那就不是停几秒的问题了——我脑子里会直接拉响警报。这不是矫情，而是过去几年里，我确实亲眼见过、也亲手排查过太多因为这一行代码引发的线上事故：有命令注入被打穿服务器的，有参数被 shell 拆得七零八落导致程序行为异常的，还有在 Windows 和 Linux 上行为不一致闹得运维半夜打电话的。

这篇文章不是要全盘否定Runtime.exec()，而是要搞清楚一件事：当你在 Java 里需要执行外部命令时，到底应该怎么传参，才能既安全又可靠。我会从命令注入的原理讲起，把Runtime.exec()拼字符串会踩的坑一个个列出来，然后给你一套可以直接落地的ProcessBuilder重构方案，最后附上我这些年在真实项目里积累的排查技巧。内容适合所有写 Java 后端、写自动化工具、或者维护遗留系统的开发者，无论你刚工作两年还是已经带团队，都应该系统的看一下这个问题，因为你永远不知道哪行拼接字符串的命令，会在什么时候变成一颗雷。

1. 内容整体设计与思路拆解

1.1 Runtime.exec() 的前世今生：为什么大家都爱这么写

Runtime.exec()从 Java 1.0 就有了，它当年被设计出来的时候，JDK 的 API 哲学和现在完全不一样，官方文档也没有特别强调命令注入的问题。更糟糕的是，早期大量 Java 入门教程、老旧项目代码，甚至一些框架的底层实现里，用的都是最简单粗暴的形态：

String cmd = "ping -c 3 " + ip; Process process = Runtime.getRuntime().exec(cmd);

或者更常见一点：

String cmd = String.format("ffmpeg -i %s -f mp4 %s", inputFile, outputFile); Process process = Runtime.getRuntime().exec(cmd);

这种写法观感上确实简单，逻辑也清晰——终端里怎么敲，字符串里就怎么写，回车一按，命令就跑起来了。但问题恰恰出在这个“终端里怎么敲”上。当你把整个字符串交给exec(String)时，JDK 在 Unix 平台上会默认把字符串丢给/bin/sh -c去解释执行，在 Windows 平台上则要经过cmd.exe。这就意味着，你以为你在执行一条命令，实际上你是在执行一段 shell 脚本。参数边界、特殊字符、转义规则，全部不由你控制，而是交给 shell 来裁决。

这里要先说清楚一个容易混淆的点：Runtime.exec()其实有多个重载，其中exec(String command)和exec(String[] cmdarray, String[] envp, File dir)在行为模型上是两回事。

• exec(String)会隐式调用系统的默认 shell 来解析整个字符串，shell 会先做分词、变量替换、通配符展开，再逐条执行最终解析出的命令。
• exec(String[])则是直接通过操作系统提供的进程创建接口，把参数数组逐项传给目标程序，中间没有 shell 这个翻译官。

用生活化的类比来说：exec(String)相当于你给管家递了一张纸条，纸条上写着“去书房把书拿来，然后顺便把窗台的花浇了”，管家是按自然语言理解整句话的，中间怎么断句、怎么理解，你控制不了；exec(String[])则是你按住管家的肩膀，一字一顿地交代：“去、书、房、拿、书。”每个词都是独立单元，不允许被拆开重组，更不允许被理解出额外的动作。

所以拼字符串的真正问题，不是“代码不够优雅”这种审美层面的小毛病，而是你把用户输入当成自然语言的一部分，毫无保留地交还给 shell 去断句。这就像你让一个陌生人替你对管家传话，又完全不管陌生人说了什么。用户输入里一旦混着分号、竖线、反引号、$()、&&之类的 shell 元字符，断句方式就可能完全失控。

1.2 拼字符串的执行模型：为什么说这是给自己埋雷

我拆解一下拼字符串实际产生的执行链路，你就能明白问题有多严重。

当你写下exec("ping -c 3 " + ip)时，如果用户传入的 ip 不是127.0.0.1，而是127.0.0.1; touch /tmp/hacked，那么传给 shell 的完整字符串就变成了：

ping -c 3 127.0.0.1; touch /tmp/hacked

shell 会先执行ping -c 3 127.0.0.1，然后无论第一条命令成功还是失败，都会继续执行touch /tmp/hacked。这里的分号就是 shell 里的“命令分隔符”，一条命令结束，下一条命令开始。而如果用户用竖线|，情况更复杂，左边命令的输出会直接变成右边命令的输入，可以直接把数据导走；如果用户用反引号或者$()，里面嵌套的命令还会先执行，并且把执行结果拼回到原命令的字符串里。这意味着什么？意味着用户输入可以被任意解释成新命令、管道、重定向、变量赋值，这就是经典的命令注入。

我不止一次在真实项目里看到过这种事故。某后台服务要根据用户上传的文件名去调用外部程序做格式转换，代码大概是：

String cmd = "/usr/local/bin/converter " + filename; Process p = Runtime.getRuntime().exec(cmd);

这里同样有个问题：文件名里如果包含空格，比如my report.doc，那么经过 shell 分词后，会被拆成/usr/local/bin/converter my和report.doc两个参数，外部程序拿到的文件名是错误的。更坏的情况是恶意用户提交report.doc; ls -la /etc，服务端就会依次执行两条命令。在演示环境里ls -la /etc看起来无害，但在真实环境里，恶意用户完全可以替换成任何指令——下载木马、删除数据、反弹 shell，全都干得出来。

所以，我接下来的思路很明确：先把Runtime.exec()拼字符串会踩的坑系统梳理清楚，然后介绍为什么ProcessBuilder是更好的替代方案，最后给出完整的重构实操和排查经验。每个关键点我都会解释背后的原理，因为只有理解了“为什么”，你才能写出真正靠谱的代码，而不是照葫芦画瓢。

2. 核心细节解析与实操要点：拼字符串的六个真实坑

2.1 参数边界丢失：你以为的一个参数，在 shell 眼里是一堆参数

第一个坑，就是参数边界完全丢失。命令行程序解析参数全靠空格、引号这些分隔符，但当你把用户输入拼进命令字符串后，用户输入里的空格会被 shell 当成参数分隔符。举个例子，假设你的程序要执行一个外部压缩工具，代码写成：

String userInput = "archive report v2.zip"; String cmd = "zip -r backup.zip " + userInput; Runtime.getRuntime().exec(cmd);

你以为userInput是一个文件名，但 shell 会把它拆成archive、report、v2.zip三个独立参数。外部工具收到三个文件参数，大概率直接报错，或者把不存在的文件当成输入。这种问题在正常使用中就会踩到，根本不需要恶意用户参与。

更常见的场景是路径里带空格。开发机上路径规规矩矩没有空格，代码跑得很顺；一到生产环境，文件路径里多了个空格，命令瞬间失效。我见过不少团队为了这种问题，给路径手动加前后引号，结果遇到路径里本身含引号的极端情况又炸了。加了引号只是把问题往后推了一层，并没有从根上解决“让参数保持独立”这件事。

2.2 特殊字符的连锁反应：分号、竖线、重定向、变量替换

第二个坑，就是 shell 元字符的连锁反应。前面已经提到了分号，这里再展开讲讲其它元字符：

• 分号;：命令分隔符，后面的命令无论前面成败都会执行。
• 竖线|：管道符，会把前面命令的 stdout 接到后面命令的 stdin。
• 与&&、或||：逻辑控制符，可以根据前面命令的返回值决定是否执行后面的命令。
• 重定向>、<、>>：把命令输出写入文件或从文件读取输入。
• 反引号`和$()：命令替换，先执行里面的命令，把结果插入原位置。
• 美元号$：变量引用，如果用户输入里写了$HOME、${PATH}，会被 shell 展开成环境变量值。

这些符号本身都是合法输入的一部分，很多场景下用户完全可能无意间带上。比如业务系统里让用户填一个备注字段，用户填的是“项目A && 项目B”，这个字符串如果被拼进命令，后果可能就是两条命令都被执行了。我在测试某个文件处理服务时，就遇到过用户上传的文件名里带括号和空格，拼接字符串执行后，shell 把文件名里的内容当成子命令执行，当场报错，日志里全是莫名其妙的片段。

有人可能会说：“我只要对用户输入做一下过滤，把特殊字符删掉不就行了？”这里要泼一盆冷水：特殊字符的过滤是一个非常深的水潭。你需要考虑 shell 的完整语法规则，还要考虑不同平台 shell 的差异，而且只要漏掉一个符号，防御就是零。你写一百行黑名单过滤，也堵不住所有边界情况，因为 shell 的解析规则本来就不是为“过滤输入”这种场景设计的。

2.3 跨平台差异：Windows 和 Unix 是两套完全不同的解析规则

第三个坑，是跨平台差异。cmd.exe和/bin/sh对特殊字符的处理规则完全不同。同一个字符串，在 Linux 上可能正常执行，在 Windows 上就行为诡异；反过来也一样。

我用一张表直接对比一下常见符号在两种平台下的表现：

同一个输入dir > list.txt && type list.txt，在 Windows 上是你想要的逻辑判断加重定向，在 Unix 上执行时，>和&&同样会被 shell 解析，但目录格式、命令名都不一样。如果你是在 Java 服务里拼一个跨平台命令，要么写两套字符串逻辑，要么写一堆兼容判断，代码复杂度直接翻倍。

但这还不是最麻烦的。最麻烦的是 Windows 的引号规则和 Unix 完全不同。在 Unix 里，单引号包裹的字符串内部不做任何展开，双引号内部会展开变量但还是保持整体参数；在 Windows 里，cmd.exe对双引号的处理有自己的逻辑，7 个"连排这种场景能让你 debug 到怀疑人生。我见过有人在执行路径带空格的程序时，在 Windows 上反复尝试引号组合，最后放弃了，直接拷贝程序路径到一个无空格的临时目录。真的，这种情况在真实开发里一点都不少见。

2.4 转义地狱：从代码里读懂“原本想传的参数”是一种奢求

第四个坑，是转义地狱。当你决定用拼字符串的方式，你就必须考虑多层转义：Java 字符串本身的转义、正则表达式的转义（如果需要校验）、shell 的转义、还有日志系统里的转义。这几层叠加起来，代码根本没法读。

举个例子，你想通过 shell 执行一个带引号的命令，Java 字符串里就得写成：

String cmd = "ls -l \"/tmp/My File\"";

这还算能看懂。如果参数里本身有单引号和双引号，你要在 shell 级别处理嵌套引用，代码里就会堆满反斜杠和引号，比如：

String cmd = "grep -r \"" + keyword + "\" /data/logs/" + date + "/app.log";

一旦 keyword 本身包含引号、反斜杠，或者需要转义的空格，你就必须知道 shell 在什么情况下会展开、什么情况下会保留。这种代码写出来的当下也许能跑，但三个月后回来看的人（很可能就是你自己）只能看到一堆\"和\\，根本搞不清原本想传什么参数。

我自己的体会是：拼字符串跑命令的代码，维护成本是“指数级”的。每加一个参数，就要重新推演一遍 shell 的解析流程；每次出问题，都要从头到尾做一次转义校验。这种代码写起来一时爽，排查起火现场时是真的想骂人。

2.5 命令注入：安全漏洞的入口

第五个坑，也是性质最严重的坑，就是命令注入。前面我已经讲过原理了，这里再深化一下。命令注入的本质是：你的程序把不可信数据（用户输入、外部接口返回的数据、消息队列消费的内容）拼接进了交给 shell 执行的高特权命令里，导致攻击者可以控制程序的执行逻辑。

这里必须明确一个边界：有些人觉得“我的系统是内网部署的，用户都是自己人，没人会故意输入恶意字符”，但命令注入不只来自恶意攻击者。一个普通用户，在输入框里填了一个带&符号的名称，比如设计部 & 市场部，如果这个字符串被拼进了某个清理命令，&可能触发“后台执行”或“逻辑与”，程序行为就不可控了。非恶意的误操作，同样能引爆雷。

安全领域有个基本共识：所有外部输入都是不可信的。这个共识在哪里都适用。命令注入的修复方式其实并不复杂——不要用字符串拼接去构造命令行，而是用参数数组的方式把命令和参数完全分离，让用户输入永远只作为一个参数值传递，而不是作为命令语法的一部分被解析。

2.6 延迟报错与排查困难：错的地方不在你能想到的位置

第六个坑，是延迟报错和排查困难。拼字符串执行命令时，很多问题不会在你拼接的那一行代码上报出来，而是要在外部程序内部才会爆发。比如参数分隔错了，外部程序可能收到一堆乱七八糟的参数，然后报一个“文件不存在”或者“参数不合法”的错误，跟你原本想执行的操作八竿子打不着。你顺着日志去排查，先怀疑外部程序，再怀疑系统环境，折腾半天才会想到，哦，原来是命令拼接时参数被拆碎了。

更气人的是，这种问题往往是偶发性的。用户这次输入的文件名没有空格，一切正常；下次输入的文件名带了空格，瞬间崩了。你在本地复现时用了一个不带空格的路径，又一切正常。这类“幽灵 bug”背后，十有八九是拼接字符串导致的参数边界问题。

3. 实操过程与核心环节实现：用 ProcessBuilder 重构你的进程调用

3.1 为什么是 ProcessBuilder 而不是别的

Java 1.5 引入了ProcessBuilder，它就是为了解决Runtime.exec()的一系列问题而设计的。核心设计理念就一句话：命令和参数分离，参数以列表或数组的形式传递，不经过 shell 解析。

ProcessBuilder的构造函数接收一个List<String>或String[]，第一个元素是命令本身，后面的元素都是参数。传给目标程序的参数，在操作系统层面就是一个个独立的字符串，中间没有任何 shell 分词的过程。用户输入里的空格、引号、分号、竖线，都只是参数里的一个普通字符，不会被解释成语法元素。

我用一个最简单的对比来说明：

// 错误写法：拼字符串，shell 参与解析 String cmd = "ping -c 3 " + ip; Process p = Runtime.getRuntime().exec(cmd); // 正确写法：参数数组，保持每个参数的独立边界 ProcessBuilder pb = new ProcessBuilder("ping", "-c", "3", ip); Process p = pb.start();

第二段代码里，即使 ip 的值是127.0.0.1; touch /tmp/hacked，传给ping程序的也只是三个独立参数127.0.0.1; touch /tmp/hacked，shell 不会去解释分号，外部程序会把整个字符串当成一个 IP 参数去判断。恶意输入最多让业务逻辑报错，却无法操纵命令执行。

3.2 ProcessBuilder 核心 API 拆解

ProcessBuilder常用的 API 不多，但每一个都值得讲清楚：

• command(List<String> command)/command(String... command)：设置要执行的命令和参数。这是最核心的方法，参数必须保持独立，不要拼成一个字符串。
• directory(File directory)：设置子进程的工作目录。这个很实用，可以避免你在命令里反复cd或者使用容易出错的相对路径。
• environment()：返回一个Map<String, String>，用来操作子进程的环境变量。注意这个 Map 是活的对象，你往里放键值对，子进程启动时就会带上。
• redirectErrorStream(boolean b)：把子进程的 stderr 合并到 stdout。对于日志收集来说非常有用，可以让你统一读一个流。
• redirectOutput(File file)/redirectError(File file)：把子进程输出直接重定向到文件，避免你手动消费流。
• start()：启动子进程，返回Process对象。

还有一个细节需要说明：ProcessBuilder默认不会经过 shell。这意味着如果你使用了 shell 特有的语法，比如管道|、重定向>、通配符*、环境变量引用$HOME，在ProcessBuilder直通模式下是不会生效的。你给外部程序传一个"*"参数，它收到的就是字面量*，而不是展开后的文件名列表。这一点看起来是限制，实际上是保护，它的本质是让你明确知道自己要做什么。

3.3 一个完整重构示例：从拼字符串到 ProcessBuilder

我拿一个实际场景给你演示重构过程。假设你的服务需要调用外部图像处理工具，把用户上传的图片转换成指定尺寸，原始代码是这样的：

String cmd = "convert " + inputPath + " -resize " + width + "x" + height + " " + outputPath; Process p = Runtime.getRuntime().exec(cmd);

这段代码的问题一眼可见：inputPath、outputPath里只要带空格或者特殊字符，命令就会碎掉；width和height如果来自外部配置，也存在被注入的风险。

重构后的代码：

ProcessBuilder pb = new ProcessBuilder( "/usr/local/bin/convert", inputPath, "-resize", width + "x" + height, outputPath ); pb.redirectErrorStream(true); Process p = pb.start();

重构之后，inputPath、outputPath无论包含什么字符，都只是作为一个整体参数传给convert程序。-resize是一个独立的参数，后面的几何参数是另一个独立参数，完全不受路径内容的影响。

如果你还需要控制工作目录和超时，可以继续加上：

pb.directory(new File("/tmp/convert-work")); Process p = pb.start(); boolean finished = p.waitFor(30, TimeUnit.SECONDS); if (!finished) { p.destroyForcibly(); throw new RuntimeException("图片转换超时"); } int exitCode = p.exitValue();

这里把超时控制在 30 秒，超时就直接强制结束子进程，避免它变成不死的僵尸任务，这一点在第四章还会继续展开。

3.4 真的需要 shell 特性时怎么办：受控的 shell 执行

看到这里你可能会问：那我的命令里确实需要管道、重定向、通配符这些 shell 特性，该怎么办？答案是可以明确使用 shell，但要用“受控脚本 + 参数外传”的方式，而不是字符串拼接。

最稳妥的模式是这样：命令主体写成一个脚本模板，用户输入或者动态数据作为参数位置传入。比如你需要执行一条复杂的 shell 命令，处理一个运行时确定的文件路径：

String script = "ls -l \"$1\" && wc -l \"$1\""; ProcessBuilder pb = new ProcessBuilder( "bash", "-c", script, "safe-script", filePath );

这里bash -c后面的字符串是我们自己写的脚本模板，safe-script是传给$0的参数名（纯占位），filePath作为$1传给脚本。用户输入的filePath即使包含分号、空格、引号，也只会被当作$1这个位置参数的值，不会被当成命令语法解析。脚本里的\"$1\"是双引号包裹的参数引用，保证带空格的文件路径也能正确传递。

这个模式的要点是：所有变量都必须用位置参数$1、$2传入，并且在脚本里引用参数时一定要加双引号。要避免把变量直接拼进 shell 脚本字符串里，那样等于又绕回了字符串拼接的老路。

4. 从“能跑”到“跑得稳”：进程管理的完整姿势

4.1 不读输出流，等于给自己埋第二颗雷

很多人在调用Process.waitFor()等待进程结束时，会遇到“程序卡死”的诡异现象。这不是 Java 的问题，而是操作系统管道缓冲区的机制在起作用。子进程的 stdout 和 stderr 是两根独立的管道，管道缓冲区是有容量上限的（通常是 4KB 到 64KB 不等，取决于系统）。当子进程输出大量数据时，如果父进程不及时读取，缓冲区满了之后，子进程就会被操作系统阻塞在写操作上，永远等不到缓冲区腾出空间，自然也就无法退出。这时候你去waitFor()，就会等到天荒地老。

正确姿势是启动进程之后，马上用两个独立的线程（或线程池）分别消费 stdout 和 stderr，然后再去等待进程结束。Java 8 之后还可以用 CompletableFuture 做异步消费，代码可以写得比较干净：

Process p = pb.start(); CompletableFuture<String> stdoutFuture = readStream(p.getInputStream()); CompletableFuture<String> stderrFuture = readStream(p.getErrorStream()); boolean finished = p.waitFor(10, TimeUnit.SECONDS); String stdout = stdoutFuture.get(1, TimeUnit.SECONDS); String stderr = stderrFuture.get(1, TimeUnit.SECONDS);

读流的函数里，用BufferedReader逐行处理即可。如果你的场景只是想把日志打进文件，可以直接用pb.redirectOutput(File)和pb.redirectError(File)，让系统直接把输出写进文件，连消费流的线程都不用写。这其实是我最推荐的做法，简单粗暴又不会出错。

还有一点必须强调：stdout 和 stderr 一定要分开读，或者用redirectErrorStream(true)合并后只读一个流。千万不要只读 stdout 不读 stderr，因为 stderr 一旦满了同样会阻塞子进程。踩过一次这个坑你就明白，调试时看到的“程序没反应”往往是流缓冲区锁死的假象。

4.2 超时与销毁：别让子进程变成僵尸

子进程的生命周期管理，是拼字符串时代最容易忽略的环节。你调用了Runtime.exec()之后，如果外部程序卡住不退出，父进程也会跟着卡住。更麻烦的是，子进程可能还会产生自己的子进程，如果外部程序是一个脚本或者一个守护进程，它启动的子进程不会因为主进程被销毁而自动结束。

waitFor(long timeout, TimeUnit unit)是 Java 8 引入的方法，可以给等待设置一个上限。超时之后，先调用destroy()温和地请求终止，过一小段时间还不退，再调用destroyForcibly()强制终止。为了防止进程残留，我一般会这样写：

if (!p.waitFor(15, TimeUnit.SECONDS)) { p.destroy(); if (!p.waitFor(5, TimeUnit.SECONDS)) { p.destroyForcibly(); p.waitFor(); } }

注意一点：在 Unix 上destroyForcibly()相当于发 SIGKILL，杀掉的只是直接子进程本身，不一定能杀掉它的子孙进程。如果外部程序启动的是一串进程树，你还需要考虑用进程组的方式整体管理，或者查一下目标进程的子进程 ID 再逐一清理。这个属于进阶话题，但在生产环境里非常实用。

4.3 环境变量与工作目录：隐秘的正确性

很多人拼字符串执行命令时，会被“当前工作目录”坑得体无完肤。你在 IDE 里跑程序，当前目录是模块根目录；部署到服务器后，当前目录变成了应用启动目录；如果经过容器封装，目录可能又是别的地方。命令里的相对路径，在不同环境下的解析结果完全不同。

ProcessBuilder.directory(File)可以显式指定工作目录，这是解决相对路径问题的最干净方案。举个例子：

ProcessBuilder pb = new ProcessBuilder("git", "status"); pb.directory(new File("/opt/repos/my-project")); pb.start();

这样不管应用在哪个目录启动，git status都会在指定仓库里执行。拼字符串时代，这种操作你得在命令里写cd /opt/repos/my-project && git status，不仅绕，而且一旦路径里带空格又得处理引号问题。

环境变量的处理也是同样的思路。pb.environment()返回一个可变 Map，你可以给子进程单独设置它需要的环境变量，而完全不影响父进程的环境：

Map<String, String> env = pb.environment(); env.put("JAVA_HOME", "/usr/lib/jvm/default"); env.put("LANG", "zh_CN.UTF-8");

如果你希望子进程继承父进程的大部分环境，只是调整个别变量，这个 Map 默认就是父进程环境的拷贝，改起来非常方便。这在处理外部工具依赖特定 JDK 版本、特定 locale、特定 PATH 的场景里，比拼命令字符串靠谱得多。

4.4 退出码与错误信息：每个非零退出码背后都有戏

进程执行完，退出码是判断成功与否的唯一标准。Unix 的惯例是 0 表示成功，非 0 表示失败，但不同外部程序的退出码含义各不相同，有的用 1 表示普通业务失败，有的用 2 表示参数错误。所以拿到非零退出码时，一定要连同 stderr 的内容一起记录到日志，否则排查问题的时候你只知道“失败了”，不知道为什么失败。

具体做法上，我建议把退出码、stdout 尾部内容、stderr 完整内容、执行时长、命令本身（注意脱敏）都放进日志。这样线上出了问题，看日志就能定位，不需要重新跑一遍复现。拼字符串时代很多人不会刻意去收集这些信息，出了问题只能干瞪眼，而 ProcessBuilder 配合流处理做起来并不复杂，一开始就把日志格式设计好，后面能省很多事。

5. 常见问题与排查技巧实录

5.1 经典案例一：命令明明在终端能跑，代码里就是不行

这是我被问到最多的问题。现象通常是这样的：同一个命令，复制到终端里执行完全正常，但放进 Java 代码用Runtime.exec()执行，要么报参数错误，要么行为怪异，要么干脆报“文件不存在”。

排查思路很清楚：先看是不是参数边界被 shell 拆碎了。终端里执行ls -l /tmp/my file.txt，shell 也把它拆成三个参数，但因为你自己在终端就是按空格拆的，所以其实没问题。可如果代码里拼接时把用户输入my file.txt当成了一个参数，shell 拆完后程序收到的却是两个参数。这个案例的解法就是换成ProcessBuilder的参数数组形式，让参数保持边界。

5.2 经典案例二：命令执行了，但没有任何输出

排查思路：先看是不是没消费输出流导致缓冲区阻塞，然后看是不是外部程序把输出写到了 stderr 而不是 stdout。很多第三方工具把日志和错误都写到 stderr，如果你只读了 stdout，就会觉得“什么也没发生”。解决方案就是redirectErrorStream(true)把两个流合并，或者分别消费两个流。拼字符串时代的代码，往往只调用了waitFor()，没认真处理流，才会被这个问题坑到。

5.3 经典案例三：跨平台部署后行为不一致

排查思路：先对比两个平台上 shell 的解析规则差异。同样的命令字符串，在 Unix 上可能依赖了/bin/sh的分词行为，在 Windows 上由cmd.exe解析后就完全不一样了。另外还要注意一行路径分隔符：Windows 用反斜杠，Unix 用斜杠。如果你在代码里写死了路径，部署到另一个平台就会炸。解决方案是在路径拼接时使用File.separator或者直接用Path、Paths工具类，命令本身用参数数组，不依赖 shell 分词。

我把这些常见问题整理成了一张速查表，方便你直接对照：

5.4 排查手段：别再用“打印一下”挣扎了

很多人排查命令执行问题时，习惯在代码里打印一堆字符串，看得眼花缭乱也没找到问题。我分享几个高效的手段：

第一，strace是排查这类问题的好帮手。用strace -f -e execve,wait4 java YourMainClass可以追踪你的 Java 进程到底调用了哪些系统调用，尤其是execve的参数是什么样的。你一眼就能看清传给外部程序的实际参数，根本不用猜。Windows 上可以用 Process Monitor 实现类似的效果。

第二，给ProcessBuilder的命令参数打结构化日志，而不是打拼接好的字符串。最容易排查的方式是把命令列表打印出来：

System.out.println("CMD: " + pb.command());

List的toString()会带上方括号和逗号，你能直观看到每个参数的边界。如果参数里有空格也能清清楚楚，不会把多个参数混成一团。

第三，临时用/bin/echo替换目标程序，看参数是怎么传的。比如你想排查外部程序收到的参数，先把命令换成echo，执行完你就知道参数数组是什么样的了。这个技巧在排查第三方工具行为时特别实用，不用真的去调外部程序。

5.5 兜底方案：旧代码一时改不完怎么办

我知道不是所有项目都有机会立刻全面重构。如果是遗留系统，老代码动起来牵扯面很大，短期内改不完,那你也别再往里面加新的拼接字符串代码了。至少做到以下几点：

第一，所有外部输入都做严格的白名单校验。比如 IP、端口、文件名，先验证格式再拼接，坚决拒绝含空格和;|&$等字符的输入。第二，命令本身写死，不让用户输入影响命令内容。第三，使用受控的 shell 脚本封装，用户输入通过参数传进去，而不是直接拼到命令里。第四，在代码注释里标明 TODO：用 ProcessBuilder 替换，给后来的人留个清楚的标记。

这不是完美方案，但至少能降低风险面。凡是涉及安全的问题，别总想着“等有空了再改”，很多事故就是在“等有空了”的过程中发生的。

我个人在实际操作中的体会是：拼字符串跑命令这问题，早发现早治疗，越早改成参数数组模式，后面流的泪越少。你可以把这条规则直接写进团队 code review 的检查清单里，凡是见到Runtime.exec()拼字符串，一律打回重写。听起来有点冷酷，但我是真见过因为这行代码出事之后，全组人熬夜排查、回滚、修复，最后发现根因就是一行字符串拼接。那种憋屈，我不想你再经历一遍。