根本原因是容器 pid namespace 中 go 程序未显式 wait 子进程，导致僵死进程积压；需对每个 exec.command.start() 配对 cmd.wait() 或用 cmd.run()，tini 仅回收孤儿进程，无法替代代码级 wait。
Go 应用在容器里为什么会有僵死进程
根本原因是：容器 PID namespace 下，init 进程（即 PID 1）不自动回收子进程的退出状态，而 Go 默认不启动 init 功能的子进程托管机制。一旦 Go 程序 fork 出子进程（比如调用 exec.Command），又没显式 wait，子进程退出后就变成僵死进程（zombie），且永远卡在容器里。
常见错误现象：ps aux | grep 'Z' 能看到大量 Z 状态进程；top 显示 zombie 数持续上涨；容器运行几天后 /proc/PID/status 里 Threads 不变但 children 积压。
- 不是所有
exec.Command都会出问题——只在子进程实际退出、父进程又没调用cmd.Wait()或cmd.Process.Wait()时才积累僵尸 - 使用
cmd.Run()是安全的，它内部会阻塞并 wait；但cmd.Start()+ 忘记cmd.Wait()就危险 - Docker 默认用
docker-init（tini）作为 PID 1，能回收孤儿进程，但前提是你的 Go 进程本身不成为“孤儿制造者”——比如反复 fork+不 wait，tini 也救不了
Go 里正确回收子进程的三种方式
核心原则：每个 Start() 都必须配对一个显式 wait；每个 Cmd 实例生命周期内，只能调用一次 Wait() 或 Process.Wait()，重复调用会 panic。
-
cmd.Run()：适合同步执行、不需要后续控制的场景；等价于cmd.Start()+cmd.Wait()，最省心 -
cmd.Start()+go func() { cmd.Wait() }()：适合异步启动后需后台回收，但要注意 goroutine 泄漏风险——如果命令永远不退出，goroutine 就一直挂着 - 用
signal.Notify捕获SIGCHLD并轮询syscall.Wait4(-1, ...)：仅在需要统一管理大量短命子进程（如 worker pool）时考虑，Go 标准库不封装该逻辑，容易写错信号掩码和 errno 判断
示例（推荐写法）：
立即学习“go语言免费学习笔记（深入）”；
cmd := exec.Command("sh", "-c", "sleep 2 && echo done")
if err := cmd.Run(); err != nil {
log.Printf("cmd failed: %v", err)
}
// 安全，无僵尸
容器环境下 PID 1 的特殊性与 tini 的作用边界
tini（Docker 默认的 --init）只负责回收「孤儿进程」，也就是当子进程的父进程已退出、它被 kernel 重新挂到 PID 1 下之后，tini 才会 wait 它。但它**不替代你代码里的 wait 调用**。
- 如果你的 Go 程序长期运行，且不断
Start()子进程却不Wait()，这些子进程始终以 Go 进程为父进程，不会变成孤儿，tini 完全看不见它们 - 用
docker run --init只是加了一层兜底，不能当成不写Wait()的理由 - Alpine 镜像默认没有 tini；若自己用
FROM scratch，更得靠代码自身处理
验证方法：进容器执行 cat /proc/1/cmdline，看到 tini 才说明生效；否则就是裸 Go 进程直接当 PID 1。
调试僵死进程的最小排查路径
别一上来就翻源码或重写进程模型。先确认是不是真有僵尸、以及谁在造它。
- 进容器执行
ps -eo pid,ppid,stat,comm | grep 'Z'——看 Z 进程的PPID是不是你的 Go 主进程 PID - 查 Go 代码里所有
exec.Command调用点，重点标出含Start()但没配Wait()的分支（包括 error 分支里漏掉的） - 加日志：在
cmd.Start()前打log.Printf("starting %v", cmd.Args)，在cmd.Wait()后打log.Printf("done %v", cmd.Args)，观察哪些没输出 “done” - 注意
cmd.Process.Pid在Start()后才有效；cmd.Wait()返回前子进程一定已终止，但僵尸状态要等到 wait 调用后才真正释放
最难察觉的是：子进程启动失败（比如文件不存在），cmd.Start() 报错，但你只处理了错误，忘了这其实也意味着子进程已“结束生命周期”，此时仍需调用 cmd.Process.Wait() 来清理——否则也会僵死。
