cmd.run()仅返回执行结果而不捕获输出，cmd.output()自动捕获stdout但stderr仍输出到终端；需同时捕获两路输出时应分别设置stdout/stderr为bytes.buffer并调用run()。
cmd.Run() 和 cmd.Output() 的核心区别在哪
用 cmd.Run() 只能知道命令是否成功退出，拿不到 stdout/stderr 内容；而 cmd.Output() 会自动捕获 stdout，但 stderr 仍会直接打印到终端——这常导致日志混乱或误判失败原因。
-
cmd.Run()：适合只关心执行结果（如启停服务），不需读取输出 -
cmd.Output()：适合命令预期成功且 stdout 是主数据（如git rev-parse HEAD），但 stderr 未被捕获，错误时可能静默失败 - 真正需要同时处理两路输出时，必须手动设置
cmd.Stdout和cmd.Stderr为bytes.Buffer或其他io.Writer
如何安全捕获 stdout 和 stderr 并区分它们
别依赖 cmd.CombinedOutput()——它把两路流混在一起，无法判断哪行是 error、哪行是正常输出。正确做法是分别绑定缓冲区，再按需解析。
- 用两个
bytes.Buffer实例，分别赋给cmd.Stdout和cmd.Stderr - 调用
cmd.Run()后，再从两个 buffer 中读取字符串：stdoutBuf.String()、stderrBuf.String() - 注意：如果命令输出很大，
bytes.Buffer会吃内存；高频/大输出场景建议用io.Pipe配合 goroutine 流式处理 - 示例关键片段：
stdoutBuf := &bytes.Buffer{}<br>stderrBuf := &bytes.Buffer{}<br>cmd.Stdout = stdoutBuf<br>cmd.Stderr = stderrBuf<br>err := cmd.Run()<br>// err 不为 nil 时，stderrBuf.String() 往往含真实错误信息
exec.Command() 启动的进程没结束，程序就退出了怎么办
常见于后台命令（如 tail -f、python -m http.server）被父进程忽略生命周期管理，导致子进程变成孤儿或被系统回收。
- 默认情况下，Go 进程退出时，子进程不一定终止——取决于操作系统信号传递和进程组设置
- 加
cmd.SysProcAttr = &syscall.SysProcAttr{Setpgid: true}可让子进程独立成组，避免意外继承信号 - 更稳妥的是显式控制生命周期：用
cmd.Process.Kill()或cmd.Process.Signal(syscall.SIGTERM)在 defer 或 context cancel 时清理 - 若需等待子进程自然退出，别漏掉
cmd.Wait()，否则可能残留僵尸进程（尤其在循环启动多命令时）
跨平台命令路径和参数空格问题怎么避坑
Windows 下用 exec.Command("cmd", "/c", "echo hello")，Linux/macOS 用 exec.Command("sh", "-c", "echo hello")——硬写字符串拼接极易出错；更麻烦的是带空格的路径或参数，比如 "C:Program Filescurlcurl.exe"。
立即学习“go语言免费学习笔记（深入）”；
- 永远不要用
exec.Command("sh", "-c", "some command with $VAR")拼接用户输入，有 shell 注入风险 - 路径含空格时，
exec.Command第一个参数必须是完整可执行文件路径，后续参数单独传，Go 会自动处理转义，例如：exec.Command("C:\Program Files\curl\curl.exe", "-s", "https://api.example.com") - 需要 shell 功能（管道、重定向）时，封装一层函数统一处理平台差异，而不是每个地方 if/else 判定
- 用
exec.LookPath()查找命令位置，比硬编码"ls"或"dir"更健壮
最常被跳过的其实是错误码语义：非零退出码不等于 panic，也不等于 error != nil 就一定失败——有些工具（如 grep）用退出码表达业务逻辑，得自己检查 cmd.ProcessState.ExitCode()。
