Go程序在Docker中收不到SIGQUIT信号是因为PID 1进程不自动转发信号且容器缺乏控制终端；应使用--init参数启动容器，并显式注册SIGQUIT处理器调用pprof.WriteTo输出堆栈。
Go程序在Docker里收不到SIGQUIT信号？
默认情况下，docker run 启动的容器中，主进程（PID 1）不会自动转发信号——哪怕你用 kill -SIGQUIT <container-pid>，Go 的 runtime/pprof 也不会触发堆栈打印。根本原因：Linux 中 PID 1 进程对信号处理有特殊规则，且 Docker 默认不启用信号代理。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 启动容器时加
--init参数（推荐），它会注入tini作为 init 进程，自动转发 SIGQUIT 到 Go 主进程 - 或改用
docker run --sig-proxy=true（仅适用于docker attach场景，不适用于后台容器） - 避免自己写 shell wrapper 脚本做 PID 1：比如
#!/bin/sh exec ./myapp仍无法正确传递 SIGQUIT，除非显式 trap + forward
Go里怎么让SIGQUIT真正打出 goroutine 堆栈？
Go 默认只在收到 SIGQUIT 且进程是前台控制终端（controlling terminal）时才输出堆栈——而容器里通常没有 /dev/tty，导致静默失败。这不是 bug，是设计行为。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确保 Go 程序未重定向
os.Stdin/os.Stdout到/dev/null或管道；否则signal.Notify可能监听成功，但pprof.Lookup("goroutine").WriteTo无输出目标 - 不要依赖默认行为，显式注册 handler：
signal.Notify(sigCh, syscall.SIGQUIT) go func() { <-sigCh pprof.Lookup("goroutine").WriteTo(os.Stdout, 1) }() - 若需带时间戳或写入文件，注意
os.Stdout在容器里可能被重定向，优先用os.Stderr或绝对路径如/tmp/goroutines.log
用 docker kill -s QUIT 为什么没反应？
docker kill -s QUIT <container> 发送的是 SIGQUIT 给容器 PID 1，但 Go 程序若没设为 PID 1（比如用了 ENTRYPOINT ["sh", "-c", "./app"]），实际收信号的是 sh，不是 Go 进程。
常见错误现象：
- 容器日志空，
docker logs没堆栈，但进程还在运行 -
docker top <container>显示多个进程，确认 Go 是否真为 PID 1 - 使用
ENTRYPOINT ["./myapp"]（数组形式、不经过 shell）才能保证 Go 是 PID 1 - 若必须用 shell 启动，需在脚本里用
exec ./myapp替换当前进程，否则信号无法穿透
pprof 堆栈里看不到用户代码？只显示 runtime 和 net/http？
这是典型 goroutine 泄漏或阻塞场景：大量 goroutine 卡在系统调用（如 select{}、net.Conn.Read、sync.Mutex.Lock）上，而你的业务逻辑早已返回。堆栈真实，但“看不见代码”是因为执行点不在用户函数里。
排查重点：
- 检查是否漏掉
defer cancel()导致context.WithTimeoutgoroutine 泄漏 - HTTP handler 中启动 goroutine 但没做 done channel 控制，易堆积
- 用
pprof.Lookup("goroutine").WriteTo(..., 2)查完整堆栈（第二个参数为 2 表示 show full stack，含 runtime 内部帧） - 对比
goroutine和heappprof：如果 goroutine 数持续上涨但 heap 不涨，基本可定位为协程泄漏而非内存问题
容器里信号和堆栈不是黑盒，但每层抽象（Docker、shell、Go runtime）都可能吃掉一次 SIGQUIT。最容易被忽略的，是以为发了信号就一定有输出——其实得同时满足：信号传到 Go 进程 + Go 进程有可写 stdout/stderr + goroutine 正在执行用户代码或处于可采样状态。
