直接上生产环境跑gin.Default()会出事，因其默认开启调试模式、冗余日志、无超时控制且不隔离权限，易引发安全漏洞与稳定性风险；必须改用gin.New()手动配置中间件、显式设置gin.ReleaseMode、配全HTTP Server超时与优雅关闭机制，并确保配置加载支持环境变量覆盖及健康检查端点独立。
直接上生产环境跑 gin.Default() 会出事。Gin 默认开启调试模式、日志冗余、无超时控制、不隔离用户权限，这些在开发阶段无所谓，但一进生产就会暴露为安全漏洞或稳定性风险。
禁用调试模式并设置运行时模式
Gin 的 gin.DebugMode 和 gin.ReleaseMode 不只是开关日志那么简单——它会影响 panic 恢复行为、错误堆栈输出、中间件默认加载项（比如 gin.Logger() 在 Release 模式下仍存在，但输出更精简）。
- 必须显式调用
gin.SetMode(gin.ReleaseMode)，不能依赖环境变量自动切换（GIN_MODE=release在容器中容易被覆盖或忽略） - 检查是否误用了
gin.Default()：它内部会自动加Logger()和Recovery()，但在生产中你往往需要自定义这两者（比如对接结构化日志系统、过滤敏感错误信息） - 建议改用
gin.New()手动挂载中间件，把控制权收回来
HTTP Server 超时与优雅关闭必须配全
没设超时的 http.Server 在网络抖动或客户端异常断连时，goroutine 会长期 hang 住，最终耗尽连接数。K8s 的 readiness probe 失败后也不会主动 kill 进程，导致滚动更新卡死。
-
ReadTimeout和WriteTimeout建议设为 30 秒以内（如30 * time.Second），避免慢请求拖垮整个实例 -
IdleTimeout必须设置（如60 * time.Second），否则 keep-alive 连接可能无限期占用资源 - 优雅关闭要监听
SIGTERM（K8s 默认发送），且srv.Shutdown()的 context timeout 应略大于最长业务处理时间，但不要超过 10 秒，否则 K8s 强杀前留不出缓冲
Docker 镜像构建必须用多阶段 + 非 root 用户
单阶段构建的镜像不仅体积大（>1GB），还自带 Go 编译器和 shell，攻击面极大；root 用户运行则一旦被 RCE 就等于交出宿主机权限。
- 构建阶段用
golang:1.21-alpine，运行阶段只 copy 二进制和 configs，基础镜像用alpine:3.18或scrach（如果没依赖 libc） - 编译时加
CGO_ENABLED=0 GOOS=linux，避免动态链接；加-ldflags="-w -s"剥离符号表和调试信息 - 必须用
adduser创建非 root 用户，并通过USER指令切换，不能只靠docker run --user覆盖（K8s PodSecurityPolicy 可能禁止该参数）
配置加载必须支持环境变量覆盖与 fallback 路径
硬编码配置路径或只读取本地文件，在 K8s ConfigMap/Secret 挂载、云平台环境变量注入场景下会直接失败。
- 用
viper时，调用viper.AutomaticEnv()后，再加viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))，这样server.port就能被SERVICE_PORT覆盖 -
viper.AddConfigPath()至少加三个路径："./configs"（本地开发）、"."（容器内默认）、"/etc/myapp/"（K8s volumeMount 推荐位置） - 所有关键字段（如数据库地址、Redis 密码）必须设
viper.SetDefault()，防止环境变量漏配导致 panic
最容易被忽略的是：健康检查端点（如 /healthz）必须独立于主路由树，且不做任何中间件拦截（比如鉴权、日志），否则 readiness probe 失败会引发连锁雪崩。这个细节在压力突增时才暴露，但修复成本远高于初期加一行 router.Any("/healthz", func(c *gin.Context) { c.Status(200) })。
