go服务平滑下线必须先调用consul反注册（带超时重试）、再shutdown http/grpc等服务、最后清理资源；k8s中需通过prestop发sigterm，terminationgraceperiodseconds至少45秒。
直接 kill -9 或 os.exit(0) 必然导致请求丢失、连接中断、注册中心残留“幽灵实例”——平滑下线不是可选项，而是上线前就必须写死的逻辑。
Go 服务收到 SIGTERM 后如何触发 Consul 反注册 + HTTP Shutdown
Consul 不会自动感知进程退出；你必须在收到信号后主动调用反注册 API，并同步关闭 HTTP server。关键顺序不能错：先通知注册中心“我要下线”，再停止接收新请求，最后等存量请求结束。
-
signal.Notify只监听syscall.SIGTERM和syscall.SIGINT，K8s preStop 默认发 SIGTERM，本地调试用 Ctrl+C 是 SIGINT - 反注册必须带超时和重试（比如最多 3 次，每次间隔 200ms），避免网络抖动导致 deregister 失败却继续往下走
-
http.Server.Shutdown()要在 goroutine 里调用，否则主流程卡住，反注册之后的清理逻辑（如 DB.Close()）就执行不了 - 反注册成功后，建议 sleep 100–300ms，给 Consul 集群一点时间广播状态变更，降低消费者端缓存未刷新的概率
为什么仅 Shutdown HTTP Server 还不够
一个真实微服务通常不止跑 HTTP：可能还有 gRPC server、Kafka 消费者、定时任务 goroutine、长连接 WebSocket 管理器。它们各自有关闭语义，且不响应 http.Server.Shutdown()。
-
grpc.Server.GracefulStop()必须显式调用，Stop()会立即断连，等同于 kill -9 - Kafka 消费者（如 sarama）需调用
consumer.Close()，并确保它已停止ConsumePartition循环，否则可能重复消费或 panic - 后台 goroutine 应通过
context.Context控制生命周期，不要用全局 channel 或 flag —— Shutdown 前 cancel context，goroutine 内部检测ctx.Done()后自行退出 - DB 连接池（
*sql.DB）调用db.Close()是阻塞的，它会等所有 idle 连接归还，但不会等正在执行的 query，所以务必确保所有 handler 已进入 shutdown 流程，不再发起新 query
Consul 客户端注销失败时该怎么兜底
反注册失败 ≠ 不能关服务，但得留痕、降级、防雪崩。Consul 的 HTTP 注销接口（/v1/agent/service/deregister/{id}）可能因网络、ACL 权限、Leader 切换失败。
- 记录 error 日志，但不 panic；允许继续执行 Shutdown，否则进程 hang 住更危险
- 加一个 fallback 机制：如果 deregister 失败，主动往 Consul KV 写个标记（如
service/<id>/graceful_shutdown_failed</id>），运维可查 - 别依赖 Consul 的 TTL 自动剔除——默认是 30 秒，太慢；你的服务等待窗口应控制在 15–30 秒内，超时就强制退出
- 若服务同时注册了多个 Consul Agent（多数据中心场景），要遍历所有注册点分别 deregister，不能只清一个
K8s 环境下 preStop 与 Go 优雅退出的协作边界
在 K8s 里，lifecycle.preStop 是唯一可靠的“进程终止前钩子”。但它只是 shell 命令，不能直接调 Go 函数——必须靠信号桥接。
- preStop 应设为
kill -SIGTERM $(pidof your-binary)或直接kill 1（假设 Go 进程是 PID 1），而不是 sleep 30s 等待——那是在掩盖问题 - Go 主程序必须监听 SIGTERM 并完成整套 shutdown 流程；preStop 只负责发信号，不负责等结果
- 如果你用了 MSE 或类似治理平台的 sidecar，它会注入自己的 preStop，此时你的容器 preStop 应留空，否则两个 preStop 竞争，容易超时被 kubelet 强杀
- Pod terminationGracePeriodSeconds 至少设为 45 秒：30 秒留给 Go shutdown，15 秒留给 preStop 执行和 kernel TCP FIN 等待
最常被忽略的一点：HTTP handler 里没做 request.Context 超时控制，会导致 Shutdown() 等到超时也关不掉——不是 Go 下线逻辑有问题，而是业务代码把请求拖成了长尾。每个 handler 都该用 ctx, cancel := context.WithTimeout(r.Context(), 10*time.Second) 开头。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
