Go进程收不到SIGTERM主因是容器启动方式错误导致信号未传递至PID 1：应避免shell封装，改用ENTRYPOINT["./app"]或CMD["./app"]，若需脚本则末行加exec；Go中需监听syscall.SIGTERM，shutdown前关闭listener并设超时，主动管理长连接，配合preStop调/shutdown接口与合理readinessProbe、maxSurge配置实现真正优雅退出。
Go 进程在 K8s Pod 中收不到 SIGTERM，不是代码漏监听，而是它根本没传到你进程上——90% 的“优雅退出失效”问题，根子在容器启动方式。
为什么 Go 主进程收不到 SIGTERM
绝大多数情况是：你的二进制被 shell 包了一层，比如 CMD ["sh", "-c", "./app"] 或没加 exec 的 entrypoint 脚本。K8s 发出的信号只打到 shell（PID 1），而 shell 默认不转发信号给子进程。
- 验证方法：
kubectl exec -it <pod> -- ps aux</pod>，确认./app的 PID 是 1；如果不是，说明信号路径断了 - Dockerfile 中应避免
CMD ["sh", "-c", "..."]，改用ENTRYPOINT ["./app"]或CMD ["./app"] - 若必须用脚本启动，最后一行务必写
exec ./app——用 Go 进程替换 shell，让其成为 PID 1
Go 里怎么正确监听和响应 SIGTERM
仅监听 os.Interrupt（Ctrl+C）不够，K8s 终止 Pod 时发的是 syscall.SIGTERM；且不能只调 server.Shutdown() 就完事，得控制超时、配合 readiness 探针、并处理长连接。
- 启动后立即监听：
signal.Notify(sigChan, syscall.SIGTERM, os.Interrupt) - 收到信号后，先关闭 listener（拒绝新请求），再调
http.Server.Shutdown()，传入context.WithTimeout(ctx, 45*time.Second) - 对 WebSocket/SSE 等 Upgrade 连接，
Shutdown()完全无感，需自己用sync.Map维护连接列表，主动conn.Close()并等待断开 - 日志打三段标记：
"SIGTERM received"→"HTTP server shutdown started"→"shutdown complete"，用kubectl logs -f观察是否完整输出
preStop 和 terminationGracePeriodSeconds 怎么配才不白设
preStop 不是可选项，它是 K8s 流量摘除的“第一道闸门”；terminationGracePeriodSeconds 是兜底时间，但前提是信号能传进去、Go 能响应。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
preStop必须是 HTTP 请求或短命令，建议 ≤5s；别在里面做 DB 连接池 drain 这类耗时操作 - 典型组合：
preStop调用一个本地/shutdown接口（该接口立刻返回 503 并触发 Go 层 shutdown 逻辑），同时readinessProbe.httpGet.path也指向这个/shutdown，确保 endpoint controller 下次 probe 就摘除 -
terminationGracePeriodSeconds建议 ≥60s（比Shutdown()的 context timeout 多留缓冲），否则 K8s 可能在你还在等连接关闭时就发SIGKILL
滚动更新时为什么新 Pod 还没就绪流量就切过去了
不是 K8s bug，是 readinessProbe 配置滞后 + maxSurge 设置不当导致的“空窗期”。Service 切流依赖 endpoint controller 的探针反馈，而探针周期、失败阈值、初始延迟都会影响摘除速度。
- 确保
readinessProbe.initialDelaySeconds尽可能小（如 3s），failureThreshold设为 1，避免“假就绪” -
maxSurge: 0是危险配置——会导致 rollout 卡住，新 Pod 启不来；推荐maxSurge: 1+maxUnavailable: 1（副本数 ≥3 时） - 用
kubectl rollout status deploy/<name></name>实时观察，别只盯READY列；关注UP-TO-DATE和AVAILABLE是否同步推进
真正卡住优雅发布的，往往不是 Go 代码写得不对，而是 Dockerfile 启动方式、preStop 响应逻辑、readinessProbe 周期、以及 maxSurge/maxUnavailable 四者没对齐——任何一个环节掉链子，都会让“平滑”变成“抖动”。
