go服务不实现蓝绿部署，仅需提供真实可信的就绪探针（/readyz），由k8s或argo rollouts控制切换；原生方案用双deployment+service selector切换，argo方案通过rollout资源定义，本地可用gvm+端口隔离模拟。
Go服务本身不实现蓝绿，只负责“准备好被切换”
蓝绿部署不是你在 main.go 里调用某个函数触发的——它由基础设施（Kubernetes + Argo Rollouts / Service / 网关）控制，Go 应用唯一要做的，是让自己的“就绪状态”真实可信。
- 必须暴露稳定可用的
/healthz或/readyz接口，返回 HTTP 200 且真正代表“能处理业务请求”（比如数据库连通、依赖服务响应正常） - 不能把
livenessProbe设成耗时操作（如全量缓存加载），否则 K8s 可能误判并重启 Pod -
readinessProbe必须配置，且失败时 K8s 才会把 Pod 从 Service 的 endpoints 中摘除——这是蓝绿切换前验证新版本是否真正就绪的关键机制 - 常见错误现象：
kubectl get rollout卡在Progressing，实际是 Go 服务没暴露 probe，或 probe 返回了 503/404
Kubernetes 原生蓝绿：用两个 Deployment + 一个 Service 切 selector
不依赖任何 CRD，纯 K8s 原生方式最轻量，适合中小团队快速落地。
- 蓝色环境跑
Deployment（label:app: user-svc, version: v1），绿色环境部署另一个Deployment（label:app: user-svc, version: v2） -
Service的selector初始指向version: v1；验证通过后，kubectl patch service user-svc -p '{"spec":{"selector":{"version":"v2"}}}' - 参数差异：
version标签名必须统一、拼写完全一致（v2≠ver2），否则 Service 找不到新 Pod，流量 503 - 性能影响：无运行时开销，但需双倍资源；注意
maxSurge和minReadySeconds不影响蓝绿，它们属于滚动更新范畴
Argo Rollouts 蓝绿：靠 YAML 驱动，Go 代码零改动
如果你已在用 Argo Rollouts，那 Go 服务完全不用改一行代码，所有逻辑都在 Rollout 资源定义里。
- 核心配置是
strategy: blueGreen，指定activeService和previewService两个 Service 名称 -
autoPromotionEnabled: false表示手动确认切流（生产推荐），true则自动完成，适合 CI 流水线高度可信场景 - 容易踩的坑：
previewService的selector必须与新版本 Pod 的 label 完全匹配；常因app: mygo-apivsapp: my-go-api这类拼写差异导致预览流量进不去 - 使用场景：已有 K8s 集群、CI/CD 已集成 Argo Rollouts，想把发布流程标准化、可审计、带自动分析能力
本地开发或非 K8s 环境：用 gvm + 端口隔离模拟蓝绿
没有 K8s？也不是云环境？可以用 gvm 搭建两套并行 Go 运行时，配合不同端口和配置模拟蓝绿行为。
- 蓝色环境用
gvm use go1.20.7 && gvm pkgset use blue-env，监听:8080；绿色环境用go1.21.0+green-env，监听:8081 - 用 Nginx 或
traefik做反向代理，通过 upstream 切换后端目标（localhost:8080→localhost:8081） - 关键点：每个环境必须有独立的
ENVIRONMENT=blue/ENVIRONMENT=green环境变量，数据库连接串、缓存前缀、日志路径都要区分 - 注意事项：HTTP 服务器不能都 bind
:8080，否则启动冲突；os.Signal优雅关闭必须实现，否则切换时可能丢请求
真正的难点不在“怎么切”，而在于“怎么确认能切”——健康检查是否反映真实依赖状态、数据库 schema 是否向前兼容、旧版本能否承受回滚后的突发流量。这些没法靠 YAML 或命令解决，得靠 Go 服务自己把探针逻辑写扎实。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
