根本原因是exec.Command第一个参数必须是可执行文件的完整路径或确保命令在系统$PATH中且Go进程能继承该环境；正确写法是将命令名与参数拆分为独立字符串，如exec.Command("ls", "-l", "/tmp")，而非拼接为"ls -l"。
exec.Command 传参时为什么命令不执行或报错 “executable file not found”
根本原因是 exec.Command 第一个参数必须是可执行文件的**完整路径**，或确保该命令在系统 $PATH 中且 Go 进程能继承该环境。直接传 "ls -l" 这种带空格的字符串会失败——Go 把它当做一个整体命令名去查找。
- 正确写法：
exec.Command("ls", "-l", "/tmp")—— 命令名和参数拆成独立字符串 - 错误写法：
exec.Command("ls -l")或exec.Command("sh -c 'ls -l'")（除非你明确需要 shell 解析） - 若必须用 shell 特性（如管道、通配符），显式调用：
exec.Command("sh", "-c", "ls *.go | head -n 1") - Windows 下注意：
exec.Command("cmd", "/c", "dir")，不能用sh
如何捕获命令输出并判断是否成功
exec.Command 默认不自动捕获 stdout/stderr，也不阻塞等待结束。必须手动调用 cmd.Output() 或组合 cmd.StdoutPipe() + cmd.Start() + cmd.Wait()。
-
cmd.Output()最常用：返回[]byte和error；如果命令退出码非 0，error是*exec.ExitError类型，可用err.(*exec.ExitError).ExitCode()获取码值 - 不要只靠
err == nil判断成功——有些命令（如grep没匹配到）会正常退出但返回非零码，业务逻辑需检查退出码 - 想同时获取 stdout 和 stderr：设
cmd.Stdout = &bytes.Buffer{}和cmd.Stderr = &bytes.Buffer{}，再调cmd.Run()
执行耗时命令时如何避免阻塞和超时控制
Go 的 exec.Command 本身不支持超时，必须靠 context.WithTimeout 配合 cmd.Start() + cmd.Wait() 实现。
- 错误示范：
time.AfterFunc杀进程不可靠，可能残留子进程 - 正确做法：创建带 timeout 的
context.Context，传给cmd.SysProcAttr.Setpgid = true（Linux/macOS 下方便 kill 整个进程组），再用cmd.Start()启动，cmd.Wait()前 select 等待 context Done - 超时后务必调
cmd.Process.Kill()，否则子进程变成僵尸 - 注意：
cmd.Run()内部已调Wait()，无法与 context 直接配合，必须拆开
跨平台路径和参数拼接容易踩的坑
Windows 和 Unix-like 系统对路径分隔符、空格、引号处理差异大，硬拼字符串极易出错。
立即学习“go语言免费学习笔记（深入）”；
- 路径一律用
filepath.Join("bin", "mytool")，别手写"bin/mytool"或"bin\mytool" - 参数含空格或特殊字符（如
file name.txt）时，Go 会自动加引号传递给 OS，无需手动包裹双引号 - 避免用
fmt.Sprintf拼接命令行——这等于自己实现 shell 解析，极难保证安全和兼容性 - 敏感参数（如密码、token）不要打日志，
cmd.Args里可能泄露；必要时用cmd.Env传入环境变量替代
最麻烦的不是怎么调用 exec.Command，而是怎么让它在不同系统上稳定输出、不漏信号、不残留进程、不泄露敏感信息——这些细节不处理，上线后就是定时炸弹。
