应优先使用start+wait而非run以实现实时日志、超时控制与进程管理；output会合并stdout/stderr且不可区分来源；lookpath不验证可执行性；信号需避免shell封装并注意跨平台差异。
os/exec.Run 会阻塞，但你可能真正需要的是 Start + Wait
很多同学一上来就用 Run，发现命令卡住、超时难控制、无法实时读输出——不是 Run 有问题，而是它默认同步执行完才返回，中间完全不可干预。
如果你要：实时捕获日志、手动 kill 进程、做超时控制、或并行跑多个命令，就得拆开用 Start 和 Wait。
-
Run=Start+Wait合体，适合“扔进去，等结果”的简单场景 -
Start立即返回，进程在后台跑；Wait阻塞直到结束，可配合context.WithTimeout实现超时 - 忘记调
Wait会导致子进程变成僵尸进程（尤其在循环中反复Start时） - 如果只关心退出码、不关心输出，
Run更简洁；否则优先选Start/Wait
stdout/stderr 没拿到？别直接用 Output，先看管道是否被复用
Output 看起来最省事，但它内部强制把 stdout 和 stderr 合并成一个 []byte，且无法区分哪行来自哪里。一旦命令报错但没输出到 stdout，你就收不到错误信息。
更常见的情况是：你用 Cmd.Stdout = &buffer，却忘了 Cmd.Stderr = &buffer 或设成 os.Stderr，导致 stderr 被丢弃或打印到终端，而你还在 buffer 里傻等。
- 想分开处理：分别设置
Cmd.Stdout和Cmd.Stderr为不同io.Writer（比如两个bytes.Buffer） - 想合并但保留来源标识：用
io.MultiWriter+ 自定义 writer 打标签 - 调试时临时把
Stderr设为os.Stderr，能立刻看到命令真实报错，避免“没反应=没执行”错觉 -
Output底层调的是Run，所以它也受制于阻塞和超时问题
命令找不到？PATH 不是你想的那样，LookPath 不等于“一定能执行”
写 exec.Command("curl", "-s", url) 在本地跑得好好的，部署到 Alpine 镜像就报 exec: "curl": executable file not found in $PATH——这不是 PATH 没配，是根本没装 curl。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
exec.LookPath 只查 PATH 下是否存在可执行文件，不验证权限、不检查动态库依赖、也不管容器里缺不缺依赖（比如 ffmpeg 缺 libx264 就算找到路径也会 exec 失败）。
- 生产环境别依赖
LookPath做存在性判断，改用exec.Command("sh", "-c", "command -v curl")更可靠 - 交叉编译时注意：Linux 下的二进制在 macOS 上
LookPath会成功，但Run必然失败（平台不匹配） - 绝对路径最稳：
exec.Command("/usr/bin/curl", ...)，但牺牲了可移植性；权衡点在于你是否控制运行环境 - 某些精简镜像（如
scratch）连/bin/sh都没有，此时连sh -c都执行不了
信号传不进去？Process.Signal 不是万能的，子进程可能已忽略或被 shell 接管
用 cmd.Process.Signal(os.Interrupt) 想发 Ctrl+C 给子进程，结果没反应——大概率是因为你启动的是 shell 命令（比如 exec.Command("sh", "-c", "sleep 100")），信号发给了 sh，而没透传给 sleep。
另一个坑是：Go 启动的进程默认不继承父进程的 signal handler，子进程收到信号后行为取决于它自己怎么写（比如 Python 脚本没注册 SIGINT handler 就直接退出，而 Node.js 默认会捕获）。
- 避免 shell 封装：尽量用
exec.Command("sleep", "100")而非exec.Command("sh", "-c", "sleep 100")，确保信号直达目标进程 - 需要透传信号时，考虑用
syscall.Setpgid创建新进程组，再向整个组发信号（需syscall包，Linux/macOS 行为有差异） -
cmd.Process.Kill()是kill -9，无法被拦截，适合强杀；但要注意：它只杀直系子进程，不递归杀子子孙孙（比如子进程 fork 出的 daemon） - Windows 下
Signal支持有限，os.Interrupt和os.Kill是仅有的两个可用信号
真正麻烦的永远不是“怎么发信号”，而是“发了之后谁来响应、响应成什么样”。子进程的信号语义、Go 的进程模型、操作系统对信号的转发规则——这三层叠在一起，debug 时得一层层剥开看。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
