Process类需显式配置StartInfo：FileName仅设路径，Arguments单独传参；重定向IO须提前设置并异步读取防死锁；超时后Kill()无清理机会；跨平台注意UseShellExecute、shell命令和路径分隔符。
Process 类不是用来“启动任意程序就完事”的黑盒，它默认不等待子进程结束、不自动捕获输出、不处理权限和路径空格问题——直接 Start() 很可能跑飞或静默失败。
如何安全启动带参数的外部程序（比如 ping 或自定义 exe）
关键在构造参数：不能把整个命令行拼成一个字符串传给 FileName，否则空格会导致解析错误（例如 "C:Program FilesMyTool.exe" -i 127.0.0.1 会被拆成三个参数）。
-
StartInfo.FileName只填可执行文件路径（如"ping"或"C:\MyApp\tool.exe"） -
StartInfo.Arguments单独填参数（如"-n 3 127.0.0.1"），框架会自动做 shell 转义 - 路径含空格时，
FileName不用加引号 —— .NET 已内部处理；但若手动调用cmd /c，就得自己包引号
怎么拿到命令的输出（stdout / stderr）而不卡死
必须在 Start() 前设置 StartInfo.RedirectStandardOutput = true（同理 stderr），否则读取会抛 InvalidOperationException。但光重定向不够：如果子进程输出量大且你不及时读，它会在缓冲区满后阻塞。
- 不要先
WaitForExit()再读 —— 可能死锁（子进程等你读 stdout，你等它退出） - 推荐用
BeginOutputReadLine()+OutputDataReceived事件异步读，或用StandardOutput.ReadToEnd()（仅限小输出） - 如果同时重定向 stdout 和 stderr，记得也调
BeginErrorReadLine()，否则 stderr 未读满也会卡住
为什么 WaitForExit(5000) 返回 false，但进程其实已经结束了
常见原因是没调 Dispose() 或没释放句柄，导致 Process 对象残留、内核资源未清理，后续同名进程检测异常。更隐蔽的问题是：某些 GUI 程序（如 notepad.exe）启动后主窗口线程未就绪，HasExited 就可能延迟返回 true。
- 总是用
using (var p = new Process()) { ... }确保Dispose() - 不要依赖
HasExited判断“是否正在运行”，它只反映内核进程对象是否销毁；需结合Responding或窗口句柄检查 UI 进程状态 - 超时后若要强制结束，用
Kill()，但注意它不给子进程清理机会（比如不会触发finally或atexit）
跨平台要注意的坑（.NET 5+）
Process 在 Linux/macOS 上行为基本一致，但几个细节容易翻车：
-
StartInfo.UseShellExecute必须为false才能重定向 IO；设为true（默认值）会走 shell，无法捕获输出 - Linux 下没有
cmd，想执行复合命令（如ls | grep txt）得显式调/bin/sh并传-c参数 - 路径分隔符别硬写
"\"，用Path.Combine()或Path.Join() -
Process.Start("dotnet", "myapp.dll")在 Linux 上可能找不到dotnet—— 检查PATH或用绝对路径（如/usr/bin/dotnet）
最常被忽略的是：Process 实例一旦 Start() 过，就不能再改 StartInfo；重用对象前必须新建实例。还有，别在 ASP.NET Core 请求线程里长期 WaitForExit() —— 它会占住线程，压测时直接拖垮吞吐。
