路径错、参数乱、读不到输出、关不掉进程四大问题根源在于对Process.Start()行为边界的误判：路径必须用绝对路径或显式设WorkingDirectory，参数须分离FileName与Arguments，重定向需UseShellExecute=false，关闭应优先CloseMainWindow()再超时Kill。
路径错、参数乱、读不到输出、关不掉进程——这四类问题占了 C# 调用外部 EXE 的 90% 以上。根本原因不是语法不会，而是对 Process.Start() 的行为边界和系统级约束缺乏实操认知。
路径找不到？别信当前目录，也别拼 Assembly.Location
Windows 下 Process.Start("tool.exe") 失败，十有八九是路径解析失败。.NET 不按代码位置找，也不按发布目录找，它只认 Environment.CurrentDirectory（当前工作目录），而这个值可能被其他代码、调试器或宿主环境（如 IIS、dotnet watch）悄悄改掉。
- 绝对路径最可靠：
Process.Start(@"C:Toolsmytool.exe")或Process.Start("C:\Tools\mytool.exe") - 相对路径必须显式设
WorkingDirectory：new ProcessStartInfo { FileName = "tool.exe", WorkingDirectory = @"C:MyAppin" } - 别用
Application.StartupPath或Assembly.GetExecutingAssembly().Location拼路径——单文件发布后它们指向临时解压目录，每次运行都不一样 - 启动前加一层防护：
if (!File.Exists(fullPath)) throw new FileNotFoundException($"EXE not found: {fullPath}");，捕获Win32Exception错误码 2（“系统找不到指定文件”）
传参总出错？Arguments 是字符串，不是命令行拼接
把带空格的路径或含引号的 JSON 当作整个字符串塞进 FileName，比如 Process.Start("C:\a b\tool.exe -i "c:\x y\in.txt"")，会导致目标 EXE 的 args[0] 变成整个字符串，而不是分离的可执行路径和参数。
-
FileName只放 EXE 路径（支持绝对/相对），所有参数统一塞进Arguments字符串 - 路径含空格时不用手动加引号：
Arguments = @"-i C:x yin.txt"，.NET 内部会自动转义 - 参数本身含双引号（如 JSON）：用
JsonSerializer.Serialize()序列化，或手动替换"→"" - 避免用逗号、分号等非标准分隔符：
Arguments = "arg1,arg2"是错的；正确写法是Arguments = "arg1 arg2"
读不到 stdout？UseShellExecute = false 是硬门槛
UseShellExecute 默认为 true，此时你调用 process.StandardOutput.ReadToEnd() 会直接抛 InvalidOperationException：“此进程未被配置为重定向标准输出”。这不是编码问题，是开关没开。
- 必须设
UseShellExecute = false才能启用RedirectStandardOutput/RedirectStandardInput/RedirectStandardError - 启动后记得
process.WaitForExit()，否则可能读到空内容（子进程还没写完就结束了） - 输出量大时别用
ReadToEnd()阻塞主线程，改用BeginOutputReadLine()+OutputDataReceived事件逐行处理 - 老工具（如 cmd 下跑的批处理）常用 GBK 编码，需显式设
StandardOutputEncoding = Encoding.GetEncoding("GBK")
怎么安全关闭第三方进程？别直接 Kill
直接调用 process.Kill() 会强制终止，可能导致数据丢失、文件损坏或资源泄漏。多数正规 EXE 支持标准退出信号，应优先尝试软关闭。
- 先发退出信号：
process.CloseMainWindow()（模拟用户点击关闭按钮），然后WaitForExit(3000)等 3 秒 - 超时后再用
process.Kill()强制结束 - 若 EXE 无窗口（如服务型工具），改用其约定的退出方式：发送特定输入（
process.StandardInput.WriteLine("quit")）、写控制文件、或调用其提供的 IPC 接口 - 注意：
CloseMainWindow()对无窗口进程无效，且不保证立即返回，务必配合WaitForExit()判断结果
真正难的不是写对那几行代码，而是理解 Windows 进程模型和 .NET 的抽象层之间那层薄薄的、但不容忽视的缝隙——比如 WorkingDirectory 和 CurrentDirectory 的差异，比如 UseShellExecute 开关背后是 CreateProcessW 还是 ShellExecuteEx 的调用路径。这些细节不踩一遍坑，很难真正稳住。
