蓝绿部署在Go服务中依赖可观察、可控制、可切换的生命周期能力与外部路由配合实现，而非热替换二进制；关键在于就绪检查真实反映依赖状态、优雅关闭覆盖所有连接与任务、路由切换由K8s或网关完成，Go只需正确暴露健康状态与版本标签。
蓝绿部署在 Go 服务中不是靠“热替换二进制”实现的，而是靠服务自身可观察、可控制、可切换的生命周期能力，配合外部路由（K8s Service、API 网关或 DNS）完成流量切换。关键不在于 Go 能不能 reload，而在于它是否准备好被切换、是否拒绝未就绪流量、是否扛得住中断信号。
健康检查端点必须真实反映就绪状态
很多团队把 /health 写成只返回 {"status": "up"}，这会让 Kubernetes 的 readinessProbe 或 Nginx 的健康检查误判——新 Pod 还没连上数据库、缓存没预热、gRPC 连接池为空，流量已经涌进来。
- 必须检查核心依赖：数据库连接、Redis 可写、下游 gRPC 服务
HealthCheck返回SERVING - 避免在 handler 里做耗时操作；建议用异步心跳+本地缓存状态，比如启动时起 goroutine 定期探测，
/health只读缓存 - K8s 中若设置
initialDelaySeconds: 5但服务启动要 8 秒，照样会 kill 掉 Pod；应配minReadySeconds: 10+ 启动后主动 sleep 2 秒再开放就绪
启动后延迟上报就绪，别急着抢流量
Go 服务常在 main() 里一口气初始化 DB、Redis、gRPC client、加载配置，这些操作耗时不可控。如果 readiness 探针一上来就成功，K8s 会立刻把流量导过去，结果第一个请求就触发 panic。
- 在 HTTP server 启动后加
time.Sleep(2 * time.Second)，给初始化留出缓冲窗口 - 更稳妥的做法是：定义一个
readychannel，在所有初始化完成、第一个健康检查通过后再 close 它；/healthhandler 阻塞等待该 channel - 不要依赖 “进程起来了就等于能干活”，Go 的并发初始化容易掩盖竞态，比如 config 加载和 DB 初始化顺序错乱
优雅关闭必须覆盖所有活跃连接与后台任务
切流量后旧环境要下线，但直接 kill -15 很可能中断正在执行的事务、丢弃队列里的消息、让 gRPC 流式响应半途而废。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- HTTP 服务必须调用
srv.Shutdown(ctx)，且 context 带超时（建议 10–30 秒），不能只用srv.Close() - 监听
os.Interrupt和syscall.SIGTERM，收到信号后先关闭 listener，再等待 pending 请求结束 - 后台 goroutine（如消息消费、指标上报）需接收
context.Context并在 Done() 时退出；不要用全局 flag 或无缓冲 channel 控制停止 - K8s
preStophook 里加sleep 15是权宜之计，本质是掩盖了 shutdown 逻辑不完整的问题
路由切换本身不依赖 Go，但 Go 必须配合网关或 K8s 的语义
Go 代码里不需要写“切换到绿环境”的逻辑，但它得让外部系统能准确识别当前实例属于哪个版本、是否可路由、是否该被剔除。
- K8s 场景下：用
version: v2标签区分蓝绿 Deployment，Service 的selector切换即生效；Go 服务只需确保 label 一致、健康接口稳定 - API 网关场景下（如 Kong/Traefik）：新版服务启动时监听不同 port 或 host，网关 upstream 指向新地址；Go 不需要改代码，但要避免硬编码 host/port，改用环境变量注入
- 别在 Go 里自己搞“双路由注册”来模拟蓝绿——gorilla/mux 的原子 router 替换只适用于内部功能灰度，无法解决跨进程、跨节点的流量隔离问题
最容易被忽略的是数据库兼容性：蓝绿环境共用一套数据库时，v2 版本的 migration 不能删字段、改类型，否则 v1 实例会 panic；所有 DDL 必须向前兼容，或者用 golang-migrate 的 up/down 分环境脚本隔离变更。这不是 Go 的事，但它是蓝绿能否真正零停机的底线。
