go程序在容器中漏掉僵尸进程是因为其默认不启动init进程，且pid 1需主动回收子进程，而go runtime不自动调用wait系统调用；正确做法是用非阻塞syscall.wait4轮询或使用tini等专用init。
为什么容器里 Go 程序会漏掉僵尸进程
Go 默认不启动子进程的 init 进程，fork 出的子进程退出后，如果父进程没调用 waitpid（或等价的 syscall.Wait4），它的进程表项就一直卡在 Z（zombie）状态。容器里 PID 1 的特殊性放大了这个问题：Linux 要求 PID 1 必须主动回收子进程，否则内核不会代为清理——而 Go 的 runtime 不自动做这事。
常见错误现象：ps aux | grep 'Z' 看到一堆 [sh] <defunct></defunct> 或 [sleep] <defunct></defunct>；top 显示 Z 进程数持续上涨；Kubernetes 中 Pod 的 restartPolicy: Always 却因 OOM 或 PID 耗尽反复崩溃。
- Go 程序若直接执行
exec.Command("sh", "-c", "sleep 1 &").Run()，且没等后台子进程，就埋下隐患 - 使用
os/exec启动长期运行的子进程（如sshd、nginx）时，必须显式处理其生命周期 - 哪怕只用
cmd.Process.Signal(syscall.SIGTERM)终止子进程，也得跟一个cmd.Wait()，否则它变僵尸
Go 自己当 PID 1 时怎么安全回收子进程
让 Go 程序自己作为容器 PID 1，就得手动实现 init 的核心职责：忽略 SIGCHLD 并循环 wait。不能依赖 signal.Notify + 单次 Wait，因为 SIGCHLD 不排队，多个子进程退出可能只触发一次信号。
正确做法是起一个 goroutine，用非阻塞 syscall.Wait4(-1, &status, syscall.WNOHANG, nil) 轮询：
立即学习“go语言免费学习笔记（深入）”；
go func() {
for {
pid, err := syscall.Wait4(-1, &status, syscall.WNOHANG, nil)
if err != nil || pid == 0 {
time.Sleep(100 * time.Millisecond)
continue
}
log.Printf("reaped child %d", pid)
}
}()- 必须用
syscall.WNOHANG，否则第一次Wait4就永久阻塞 - 不能用
os/exec.Cmd.Wait()替代——它只等自己启动的那个进程，不是全局回收 - 注意
status是syscall.WaitStatus类型，需用status.Exited()或status.Signaled()判断退出原因
Tini 为什么比自己写 wait 循环更省心
你不需要重发明轮子。Tini 是专为容器设计的轻量级 init，它已处理好信号转发、子进程回收、孤儿进程 re-parenting 等边界情况。Go 程序只要不作为 PID 1 启动，就能靠 Tini 托底。
典型用法：Dockerfile 里加 ENTRYPOINT ["/sbin/tini", "--"]，再把 Go 程序放后面：
FROM golang:1.22-alpine RUN apk add --no-cache tini ENTRYPOINT ["/sbin/tini", "--"] CMD ["./myapp"]
- Tini 默认启用
-s（信号代理），Go 程序能正常收到SIGTERM，不用额外改代码 - 如果 Go 程序本身做了子进程管理，Tini 和它共存不冲突；Tini 只负责兜底未被回收的孤儿进程
- Alpine 镜像需注意：Tini 包名是
tini，但二进制路径常为/sbin/tini，不是/usr/bin/tini
Go 程序里 spawn 子进程的三个硬约束
无论是否用 Tini，只要 Go 主动 fork，就必须对每个子进程明确生命周期策略。模糊地带最容易出僵尸。
- 用
exec.Command启动的进程，必须调用cmd.Start()+cmd.Wait()（或cmd.Run()），不能只Start()就扔掉 - 若需后台运行（比如守护进程），要用
cmd.Process.Release()并确保有其他机制回收——比如用syscall.Setpgid(0, 0)创建新进程组，再由 Tini 统一收 - 避免在 goroutine 里无等待地
exec.Command().Run()：goroutine 退出不等于子进程退出，泄漏照旧
最麻烦的其实是 shell 管道和重定向场景，比如 exec.Command("sh", "-c", "cat /tmp/log | grep error")——这会启两个进程，Wait() 只等 shell，cat 和 grep 可能漏收。这时候要么换 exec.CommandContext 控制超时，要么干脆别用 shell 封装。
