应使用 exec.CommandContext 配合 context.WithTimeout 实现超时控制，它会自动终止子进程并返回 context.DeadlineExceeded 错误，避免手动杀进程的竞态问题，且比手写 select 更安全可靠。
exec.Command 启动的进程不自动继承超时
Go 的 exec.Command 本身不支持直接传入超时参数，调用 cmd.Run() 或 cmd.Output() 会一直阻塞，直到子进程退出——哪怕它卡死、夯住、无限循环。这不是 bug，是设计如此：超时控制必须由上层显式实现。
常见错误现象：exec.Command("sleep", "300").Run() 在没加任何保护的情况下，会真等 5 分钟才返回，期间 goroutine 被锁死，无法响应取消或上下文 deadline。
- 正确做法永远是把
exec.Command和context.WithTimeout配合使用 - 不要试图用
time.AfterFunc+cmd.Process.Kill()手动杀进程，竞态风险高（进程可能已退出，Kill 报os: process already finished） - 必须用
cmd.Start()+cmd.Wait()配合select等待，或直接用exec.CommandContext
用 exec.CommandContext 替代 exec.Command
exec.CommandContext 是 Go 1.7+ 引入的标准方案，它把 context 的 cancel 和 timeout 逻辑内建进命令生命周期里，比手撸 select 安全得多。
使用场景：所有需要硬性限制外部命令执行时长的地方，比如调用第三方 CLI 工具、执行 shell 脚本、集成系统诊断命令等。
立即学习“go语言免费学习笔记（深入）”；
-
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)—— 必须提前创建带 timeout 的 ctx - 用
exec.CommandContext(ctx, "ping", "-c", "3", "example.com")替代exec.Command - 调用
cmd.Output()或cmd.Run()后，若超时，返回的 error 会是context.DeadlineExceeded，不是 syscall 错误 - 超时发生时，子进程会被自动 SIGKILL（Unix）或 TerminateProcess（Windows），无需手动清理
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
cmd := exec.CommandContext(ctx, "sh", "-c", "sleep 5; echo done")
out, err := cmd.Output()
if err != nil {
if errors.Is(err, context.DeadlineExceeded) {
log.Println("command timed out")
} else {
log.Printf("command failed: %v", err)
}
return
}
log.Printf("output: %s", out)
超时后子进程可能残留的坑
即使用了 CommandContext，在某些边缘场景下，子进程仍可能变成僵尸或孤儿——尤其是当子进程 fork 出孙进程且未正确处理信号时（比如 shell -c 启动的脚本里又起了后台任务）。
参数差异：cmd.SysProcAttr 在 Unix 系统上可配合 Setpgid: true 和 Setctty: true 控制进程组，避免子进程逃逸。
- 默认情况下，shell 启动的后台进程（如
sleep 10 &）不受父进程超时影响，会继续运行 - 加
cmd.SysProcAttr = &syscall.SysProcAttr{Setpgid: true}，再配合syscall.Kill(-cmd.Process.Pid, syscall.SIGKILL)可杀整个进程组（但CommandContext默认不这么做） - 更稳妥的做法是避免在命令中用
&、nohup、disown等脱离控制的写法 - Windows 下无进程组概念，但要注意
CreateNoWindow: true和HideWindow: true不影响超时行为
Output / Run / CombinedOutput 的行为差异影响超时判断
这三个方法都支持 CommandContext，但错误路径不同，直接影响你能否准确区分“超时”和“命令失败”。
性能影响：三者都会将 stdout/stderr 全部读入内存，对大输出（如 tar -cf - /）有 O(N) 内存开销，超时前就可能 OOM；若只需判断是否成功，用 cmd.Run() 更轻量。
-
cmd.Run()：只关心退出状态，不捕获输出；超时返回context.DeadlineExceeded，命令非零退出返回*exec.ExitError -
cmd.Output()：返回 stdout；若命令失败（非零退出），error 是*exec.ExitError，不是超时；只有真超时才返回context.DeadlineExceeded -
cmd.CombinedOutput()：同Output()，但合并 stderr 到 stdout；适合调试，但日志混在一起后难定位问题源头 - 注意：
errors.Is(err, context.DeadlineExceeded)是唯一可靠的超时判断方式，别用字符串匹配"timeout"
超时控制看似简单，真正麻烦的是子进程派生行为和信号传递的不可见性。别假设 shell 脚本能被干净杀死，尤其当它调用了其他工具链时。
