exec.Command("ls -la")报错是因为Go将整个字符串当作命令名查找，正确写法是exec.Command("ls", "-la")；需shell特性时才显式调用/bin/sh -c，并严格防注入。
Go 调用外部命令不是“写一行 shell 就行”，而是必须显式拆分命令与参数，且默认不经过 shell —— 这是绝大多数错误的根源。
exec.Command("ls -la") 为什么总报 “no such file or directory”
这个错误几乎从不表示 ls 不存在，而是 Go 把整个字符串 "ls -la" 当作一个可执行文件名去查 PATH。它不会做任何空格分割或 shell 解析。
-
exec.Command("ls -la")→ 错误：系统找名为"ls -la"的二进制，找不到 -
exec.Command("ls", "-la")→ 正确：第一个参数是命令名，其余是独立参数 - 带空格的参数（如路径）要原样传入：
exec.Command("cp", "file with space.txt", "/tmp/")，Go 不会帮你切分或转义 - 通配符（
*.go）、花括号展开（{1..3}）、变量（$HOME）全都不会生效 ——find和ls自己支持 glob 是另一回事，但那是命令自身行为，不是 Go 帮你做的
需要管道、重定向或变量时，必须显式调用 /bin/sh -c
Go 的 exec.Command 天然绕过 shell，所以你要自己决定是否引入它。别为了省事在所有地方都加 /bin/sh -c，有安全和性能代价。
- 正确启动 shell：
exec.Command("/bin/sh", "-c", "ls *.go | head -n1")——-c后面是一个完整字符串，由 shell 解析 - 绝对不要拼接用户输入到
-c字符串里："ls " + userInput是严重命令注入漏洞 - 安全插值写法：
exec.Command("/bin/sh", "-c", "ls -l $1", "sh", userDir)—— 第四个参数是$0（shell 名），第五个起才是$1、$2 -
/bin/sh比/bin/bash更便携；精简镜像（如scratch）可能连/bin/sh都没有，此时此方案直接失效
Run()、Output()、Start()+Wait() 到底怎么选
选错会导致超时失控、内存爆炸、日志丢失或僵尸进程 —— 它们不是“写法不同”，而是语义完全不同。
立即学习“go语言免费学习笔记（深入）”；
-
Run()：只关心退出码，不读输出。适合git pull、systemctl restart这类“执行即忘”操作 -
Output()：自动捕获 stdout（合并 stderr 到 error 中），适合短输出（如hostname、date）。但它把全部输出 load 到内存，tail -f或大日志会 OOM -
Start() + Wait()：唯一能实时读流、设超时、手动 kill、避免僵尸进程的方式。必须配context.WithTimeout，且每次Start()后都要Wait()，否则子进程滞留 - 想分开捕获 stdout/stderr？不能用
Output()，得分别设Cmd.Stdout和Cmd.Stderr为不同io.Writer（如两个bytes.Buffer）
环境变量、工作目录、PATH 问题经常被忽略
子进程不继承你“以为它该有的”上下文 —— 尤其在容器、systemd 或交叉编译环境下，表现会突变。
-
exec.Command("npm", "run", "build")在本地 OK，Alpine 镜像里失败？不是 PATH 没配，是根本没装npm。用exec.Command("sh", "-c", "command -v npm")替代LookPath更可靠 - 工作目录默认是当前进程启动时的路径，不是源码所在目录。需显式设置：
cmd.Dir = "/path/to/project" - 环境变量默认继承父进程，但容器中常为空。自定义时别覆盖整个
os.Environ()，而是追加：cmd.Env = append(os.Environ(), "DEBUG=1") - 交叉编译要注意：Linux 二进制在 macOS 上
LookPath可能成功（找到路径），但Run()必然失败（平台不匹配）
最易被绕过的点是：你以为命令“执行了”，其实它卡在 stdin 等待输入，或者 stderr 被丢进黑洞，而你还在 buffer 里等 stdout —— 动手前先确认 I/O 管道是否按预期连接。
