生产环境禁用gin.Default()和router.Run()，须设ReleaseMode、自定义http.Server（含读写/空闲超时）、实现依赖感知的健康检查，并区分livenessProbe与readinessProbe。
直接上生产环境跑 router.Run() 是最常见也最危险的起点。Gin 默认开发模式会暴露调试信息、不设超时、无优雅关闭，健康检查端点如果只是写个 /health 返回 200，但服务实际卡在数据库连接或 goroutine 泄漏里，那这个检查就完全失效。
健康检查端点必须反映真实服务状态
只返回固定 JSON 的 /health 路由（比如 c.JSON(200, gin.H{"status": "OK"})）只能说明 Gin 进程活着，不能说明它能干活。生产中要检查关键依赖是否可用：
- 数据库连接池是否可获取连接（执行一条
SELECT 1） - Redis 是否响应（
redis.Ping()） - 关键外部 API 是否可连通（带超时的 HTTP head 请求）
- 本地磁盘空间是否充足（
statfs检查）
建议把检查逻辑封装成独立函数，避免阻塞主路由；用 context.WithTimeout 控制单次检查上限（如 2 秒），超时即认为异常。Kubernetes 的 livenessProbe 会反复调用这个接口，卡住或慢响应会导致容器被误杀。
部署时必须禁用调试模式并设置超时
Gin 默认是 gin.DebugMode，会输出详细错误堆栈、重定向日志等，不仅暴露内部信息，还可能拖慢请求。生产启动前必须显式设置：
if os.Getenv("GIN_MODE") == "release" {
gin.SetMode(gin.ReleaseMode)
}
同时，不要直接用 router.Run(":8080")。它底层用的是 http.ListenAndServe，没有读写超时控制。正确做法是构造 http.Server 实例：
srv := &http.Server{
Addr: cfg.Address,
Handler: r,
ReadTimeout: time.Second * 30,
WriteTimeout: time.Second * 30,
IdleTimeout: time.Second * 60,
}
其中 IdleTimeout 尤其重要——它防止长连接耗尽文件描述符，Nginx 反向代理默认 keepalive 75 秒，这里设为 60 秒能主动回收。
Docker 和 Kubernetes 中健康检查配置要点
镜像构建时别忘了暴露端口和设置非 root 用户：
FROM golang:1.23-alpine AS builder ... FROM alpine:latest RUN addgroup -g 1001 -f appgroup && adduser -S appuser -u 1001 USER appuser EXPOSE 8080 HEALTHCHECK --interval=10s --timeout=3s --start-period=30s --retries=3 \ CMD wget --quiet --tries=1 --spider http://localhost:8080/health || exit 1
Kubernetes Deployment 中的 livenessProbe 和 readinessProbe 要区分用途：
-
livenessProbe：失败就重启容器，路径用/health，但检查项要轻量（只查进程+DB ping） -
readinessProbe：失败则从 Service Endpoint 中剔除，可加更重检查（如 Redis + 外部依赖），避免流量打到未就绪实例 -
initialDelaySeconds必须大于应用冷启动时间（编译后二进制加载、配置解析、DB 连接池初始化）
很多团队把两者都指向同一个端点，结果 DB 临时抖动导致所有 Pod 被轮番重启，雪崩就从这儿开始。
健康检查不是加个路由就完事，它本质是服务可观测性的第一道闸门。真正难的不是写那几行 c.JSON，而是想清楚「什么才算服务真的 ready」，以及「什么情况必须 kill 它」——这两点一旦模糊，整个部署链路的稳定性就建立在流沙之上。
