容器中看不到init进程是因为pid命名空间隔离使go主进程成为pid 1，它不承担传统init职责；go需自行处理信号、清理子进程，并通过cgroup限制pid数及适配gomaxprocs。
Go 应用在容器里为什么看不到 init 进程？
因为容器默认使用 pid namespace 隔离，进程 PID 从 1 开始重新编号，init（即容器主进程）永远是 PID 1 —— 它不是系统 init，只是你启动的 Go 程序。Go 运行时不会自动 fork 出传统意义上的子 init 进程来接管孤儿进程，所以子 goroutine 或 exec.Command 启动的子进程一旦父进程退出，就直接被 kernel 收养到 PID 1（也就是你的 Go 主进程），但不会触发 signal 处理或自动清理。
常见错误现象：ps aux 里只看到一个进程；用 kill -9 1 直接干掉整个容器；子进程变成僵尸进程却没人 wait。
- Go 程序必须自己监听
os.Interrupt和syscall.SIGTERM，并主动调用os.Exit()或优雅退出逻辑 - 如果用
exec.Command启动外部命令，建议设置cmd.SysProcAttr = &syscall.SysProcAttr{Setpgid: true}，避免信号被错误传递 - 不要依赖
fork+exec后的子进程自行处理 SIGTERM —— 容器内没有 init 进程帮你转发信号
如何限制 Go 进程能创建的子进程数？
靠 Go 本身做不到。PID 数量限制由 Linux cgroups v1 的 pids.max 或 cgroups v2 的 pids.max 控制，Go 运行时不提供 API 暴露该限制，也无 runtime.SetMaxProcs 类似机制。它只管 goroutine 调度，不管 OS 进程数量。
使用场景：防止因 bug 导致无限 fork（比如循环调用 exec.Command）耗尽宿主机 PID 资源。
立即学习“go语言免费学习笔记（深入）”；
- Docker 启动时加
--pids-limit=100（cgroup v1）或--cgroup-parent配合 v2 手动设pids.max - Kubernetes 中通过
pod.spec.containers[].resources.limits.pids（需 kubelet v1.28+ 且启用SupportPodPidsLimit特性门） - 检查是否生效：进容器执行
cat /sys/fs/cgroup/pids.max，值为max表示未限制，数字则为上限
为什么 Go 的 runtime.NumCPU() 在容器里经常不准？
因为 runtime.NumCPU() 默认读取 /proc/sys/kernel/osrelease 和 /sys/devices/system/cpu/online，而这些路径在容器中未被 cgroup CPU quota 隔离 —— 它返回的是宿主机总 CPU 核心数，不是容器实际能用的。
性能影响：GOMAXPROCS 自动设为宿主机核数，导致大量 goroutine 在少量 CPU 上争抢，调度开销上升，甚至触发 GC 频繁停顿。
- 启动前手动设
GOMAXPROCS：比如GOMAXPROCS=2 ./myapp - 更稳妥的做法是在代码里读取 cgroup 限制：
os.ReadFile("/sys/fs/cgroup/cpu.max")（v2）或解析/sys/fs/cgroup/cpu/cpu.cfs_quota_us（v1） - 注意：Docker 默认不挂载
/sys/fs/cgroup到容器，需加--mount type=bind,source=/sys/fs/cgroup,target=/sys/fs/cgroup,readonly
容器中 Go 程序收到 SIGTERM 后不退出？
典型原因是没注册信号处理器，或者用了 signal.Notify 但没正确阻塞等待、没调用 os.Exit()，又或者子 goroutine 卡在阻塞 IO（如未设 timeout 的 HTTP 请求）导致 main goroutine 无法退出。
容易踩的坑：signal.Notify 只负责接收，不自动终止程序；goroutine 泄漏会让 main 一直等；http.Server.Shutdown 必须配超时，否则可能 hang 住。
- 务必用
signal.Notify(c, syscall.SIGTERM, syscall.SIGINT)+阻塞等待 - HTTP server 关闭前设 context.WithTimeout，例如
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second) - 检查是否有 goroutine 在死循环里 sleep 或 channel receive —— 它们不会响应信号，得靠外部通知或 context 取消
- 用
pprof/goroutine在退出前 dump 一次，确认无活跃 goroutine
复杂点在于：信号处理、资源释放、goroutine 协作、cgroup 限制这几层是解耦的，但运行时表现会互相掩盖。比如你以为是信号没收到，其实是 shutdown 卡在 DNS 查询里 —— 先看 strace -p $(pidof myapp) 再排查。
