ProcessBuilder 启动失败却无报错，主因是未捕获 start() 抛出的 IOException 或 InterruptedException；须拆分含空格路径、同步处理输入输出流、按系统适配命令。
ProcessBuilder 启动失败但没报错？检查 start() 之后是否忽略异常
Java 的 ProcessBuilder 默认不会在构造时校验命令是否存在或参数是否合法，真正抛异常是在调用 start() 时。常见现象是程序卡住、子进程没起来、waitFor() 永远不返回——其实是因为底层执行失败，但你没捕获 IOException 或 InterruptedException。
- 务必用 try-catch 包裹
start()，尤其注意IOException（如命令不存在、权限不足）和InterruptedException（线程被中断） - 不要只依赖
process.exitValue()判断成功；它在进程未结束时会直接抛IllegalThreadStateException - 想确认是否真启动了，先调
isAlive()（Java 9+）或观察getInputStream()是否可读
路径含空格或特殊字符时，command 列表必须拆开传，不能拼成字符串
这是最常踩的坑：把 ["/usr/local/bin/my tool", "--flag", "arg"] 错写成 ["/usr/local/bin/my tool --flag arg"]。后者会被整个当做一个可执行文件名去找，系统当然找不到。
-
ProcessBuilder构造函数接收List<string></string>或可变参数String...，每个元素必须是独立的 token - Windows 下路径如
C:Program FilesJavainjava.exe必须拆成"C:\Program Files\Java\bin\java.exe"单独一项，不能加引号 - 需要 shell 特性（比如管道、重定向、通配符展开）？别硬扛——显式调用
cmd /c或/bin/sh -c，并把整条命令作为最后一个参数传
子进程输出阻塞？别只读 InputStream，ErrorStream 也得同步处理
很多脚本或命令（尤其是 C/C++ 编写的）会把错误日志打到 stderr，而 Java 默认不合并流。如果子进程 stderr 缓冲区满了（通常 4KB–8KB），它就会挂起，连 stdout 也一并卡住——你看到的就是“程序没反应”。
- 必须同时消费
process.getInputStream()和process.getErrorStream()，哪怕只是丢弃：new Thread(() -> copyToOutputStream(is, System.out)).start(); - 避免用
Scanner或BufferedReader.readLine()等阻塞式读取，除非你确定数据量小且有明确结束标识 - 更稳妥的做法是用
CompletableFuture并行读两路流，或借助 Apache Commons Exec 的PumpStreamHandler
跨平台命令兼容性差？用 System.getProperty("os.name") 分支处理
同一段代码在 Linux/macOS 跑得好好的，Windows 上就报 Cannot run program "kill": error=2, No such file or directory——因为 kill 不是 Windows 命令。
立即学习“Java免费学习笔记（深入）”；
- 不要假设
ps、kill、which、bash在所有系统都存在；查文档确认替代命令（如 Windows 用tasklist/taskkill） - Java 自带的
Runtime.exec()兼容性更差，ProcessBuilder至少能统一构造逻辑，但命令本身仍需适配 - 敏感操作（如杀进程、查端口占用）优先考虑 Java 原生 API（如
ManagementFactory.getOperatingSystemMXBean()查进程），而非 shell 命令
真正难的不是怎么启动一个进程，而是怎么让它不卡、不丢日志、不因系统差异崩掉——这些细节藏在流处理时机、错误分支覆盖、路径分词规则里，漏掉任何一环，问题都会在生产环境凌晨三点出现。
