exec.Command启动外部命令需分离命令与参数，如exec.Command("ls", "-la")；不可拼接为字符串，因不经过shell解析；须显式设置Dir、Env及超时控制。
exec.Command 启动外部命令的基本写法
Go 用 exec.Command 启动外部程序，本质是 fork + exec 的封装，不是 shell 解析器。传入的第一个参数是可执行文件路径（或 $PATH 中能查到的命令名），后续所有参数都直接透传给目标程序，**不会经过 shell 解析**。
常见错误是把带管道、重定向、变量展开的 shell 命令直接塞进去，比如：exec.Command("ls -la | grep main") —— 这会报 "ls -la | grep main: no such file or directory"，因为系统找不到叫这个完整名字的可执行文件。
- 正确做法：拆成单个命令，用
Cmd.Args或构造参数切片显式传递，例如：exec.Command("ls", "-la") - 需要 shell 功能（如管道、通配符）？得手动调用
/bin/sh并传-c参数，例如：exec.Command("/bin/sh", "-c", "ls -la | grep main") - Windows 下注意：不要硬编码
/bin/sh，可用runtime.GOOS == "windows"分支处理，或统一走cmd /c
获取命令输出和错误的三种常用方式
默认情况下 Cmd.Stdout 和 Cmd.Stderr 是 nil，命令输出会直接打印到父进程的终端。要捕获输出，必须提前设置。
-
Cmd.Output()：最简方式，自动调用Run()并返回[]byte和error；但如果命令非 0 退出，会返回 error 且stderr会混在 error 里（除非你重定向了 stderr） -
Cmd.CombinedOutput()：把 stdout 和 stderr 合并到一个字节切片，适合调试时“看一眼结果”，但无法区分哪部分是错误输出 - 手动设置
StdoutPipe()/StderrPipe()：最灵活，可分别读取、流式处理、或做超时控制；但要注意：必须在Start()前调用，且需显式Wait()等待结束
示例：out, err := exec.Command("date").Output() —— 成功时 err == nil，out 是类似 "Mon Jun 10 15:23:45 CST 2024\n" 的字节切片。
立即学习“go语言免费学习笔记（深入）”；
将任意网站转换为文件系统，自动抓取网站并将页面挂载为 Markdown 文件，可使用 grep、diff、cat 等标准 Unix 命令进行搜索、比较、读取和浏览。
命令超时、环境变量与工作目录的控制点
exec.Command 返回的 *exec.Cmd 是可配置对象，关键字段要在 Run() 或 Start() 前设置，否则无效。
- 超时：用
context.WithTimeout创建带截止时间的 context，再传给Cmd.Start()或Cmd.Run()；别只靠time.AfterFunc杀进程，容易漏掉子进程（尤其有子 shell 时） - 环境变量：
Cmd.Env是字符串切片，格式为"KEY=VALUE"；若想继承当前环境再叠加，可用os.Environ()拼接，例如：append(os.Environ(), "DEBUG=1") - 工作目录：
Cmd.Dir设定运行路径，必须是绝对路径或相对当前进程工作目录的有效路径；设错会导致 “no such file or directory”（尤其是执行脚本时找不到依赖文件）
注意：Cmd.Path 一般不用手动设，exec.Command 内部会用 exec.LookPath 查找；但如果你明确知道二进制位置（比如打包进 binary 的资源），可以赋值避免 PATH 查找开销。
exec.CommandContext 为什么比 Run() 更可靠
直接调用 Cmd.Run() 没有上下文控制能力，一旦命令卡死（比如交互式程序没输密码、网络请求 hang 住），整个 goroutine 就阻塞了。而 exec.CommandContext(ctx, ...) 把 context 生命周期和进程生命周期绑定：
- context 被 cancel 或超时时，Go 会向子进程发送
SIGKILL（Unix）或TerminateProcess（Windows） - 即使子进程 fork 了孙子进程，Go 1.19+ 也通过
Setpgid确保整个进程组被清理（前提是没显式设置SysProcAttr.Setpgid = false） - 务必检查
err是否为context.DeadlineExceeded或context.Canceled，而不是只看exit status 1这类通用错误
实际项目中，只要涉及用户可控输入、网络依赖、或不确定耗时的外部命令，都应该用 CommandContext，哪怕只是加个 30 秒兜底。
