cmd.Start()可能因文件不存在、权限不足等启动失败并返回*exec.Error，而cmd.Run()还包含子进程退出码非0的错误；参数含空格须分传，走shell需显式调/sh；PATH不一致、libc缺失、无超时等待等是常见坑点。
exec.Command 启动失败时，cmd.Start() 和 cmd.Run() 的区别必须分清
很多人以为 cmd.Run() 失败了才需要查错，其实 cmd.Start() 就可能 panic 或静默失败——比如可执行文件根本不存在、没权限、路径含空格且未用 exec.Command 正确拆分参数。
-
cmd.Start()只负责 fork 进程，不等它结束；失败时返回*exec.Error（如exec: "xxx": executable file not found in $PATH），不是os.PathError -
cmd.Run()=Start()+Wait()，错误可能是启动阶段的，也可能是子进程退出码非 0 导致的*exec.ExitError - 调试时优先用
cmd.Stderr = os.Stderr直接透传错误输出，比捕获err.Error()更可靠
命令参数带空格或特殊字符，exec.Command 不会自动 shell 解析
写 exec.Command("ls -la /tmp/with space") 是错的——这会尝试执行一个叫 "ls -la /tmp/with space" 的二进制，而不是调 ls 命令加三个参数。
- 正确写法是分开传：
exec.Command("ls", "-la", "/tmp/with space") - 真要走 shell（比如用管道、重定向、通配符），得显式调
/bin/sh：exec.Command("/bin/sh", "-c", "ls -la /tmp/with space | head -n1") - 注意
/bin/sh在 Alpine 容器里是ash，某些语法（如[[ ]]）不支持，出错信息可能只显示exit status 2，没更多上下文
exec.Command 找不到命令的常见原因和快速验证法
报 exec: "git": executable file not found in $PATH 不一定真是 PATH 问题，更可能是运行环境和你本地终端不一致。
- 检查 Go 进程的
os.Getenv("PATH")，别假设它和 shell 一样；容器中常为空或极简 - 用绝对路径绕过 PATH：
exec.Command("/usr/bin/git", "status")，能跑说明是 PATH 或环境问题 - 在目标环境里手动执行
which git或command -v git，结果可能和 Go 进程看到的不一致（比如用了不同 shell 的 profile） - CGO_ENABLED=0 编译的二进制在 Alpine 上可能缺 libc 依赖，导致
exec调用直接失败，错误却是 “no such file or directory”（实际是 so 文件找不到）
子进程卡住、没输出、超时不生效，其实是 cmd.Wait() 阻塞没设 timeout
cmd.Run() 默认无限等待，一旦子进程 hang 住（比如交互式命令、网络阻塞、死循环），整个 goroutine 就卡死，且无法靠 context 取消——除非你用 cmd.Process.Kill() 手动干掉。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
cmd.Start()+cmd.Wait()配合time.AfterFunc或context.WithTimeout控制生命周期 - 别依赖
cmd.ProcessState.Exited()判断是否结束，它只在Wait()返回后才有意义 - 如果需要实时读 stdout/stderr，用
cmd.StdoutPipe()和io.MultiReader组合，但记得在Wait()前 close pipe，否则可能 deadlock
真正难调的永远不是“命令怎么写”，而是“命令在什么环境、以什么权限、带着什么环境变量、有没有被信号中断、输出缓冲有没有刷完”。这些细节不打日志、不进容器看一眼，光看 Go 代码里的 err != nil 判断，基本等于盲人摸象。
