gin_mode环境变量直接控制gin框架运行模式，值为debug、release或test，优先级高于代码中gin.setmode()，需在router.run()前生效；宝塔部署时需显式透传该变量。
Go 环境变量 GIN_MODE 直接控制运行模式
Gin 框架内置 GIN_MODE 环境变量，它不依赖配置文件或代码硬编码，启动时读取即生效。值为 debug、release 或 test 三种，分别对应不同日志输出、错误堆栈、中间件行为。你改环境变量，Gin 就自动切模式，不需要动代码。
常见错误是以为要改 gin.SetMode() 才生效——其实它只是兜底写法，优先级低于环境变量。如果你在代码里写了 gin.SetMode(gin.ReleaseMode)，但系统环境里又设置了 GIN_MODE=debug，最终还是 debug 模式。
-
GIN_MODE=debug：默认值，打印详细日志、显示错误堆栈、启用gin.Recovery()的 panic 捕获并返回 HTML 错误页 -
GIN_MODE=release：关闭调试信息，错误只记录日志不返回给客户端，gin.Recovery()不渲染 HTML，适合生产 -
GIN_MODE=test：专为测试设计，禁用日志输出（避免干扰 test 输出），内部使用httptest.NewRecorder()更友好
用 flag + Viper 实现自定义环境配置加载
仅靠 GIN_MODE 不够——它只管框架行为，不管理数据库地址、Redis 配置、API 密钥等业务参数。这时候需要配合命令行参数和配置文件，比如用 flag.String("env", "dev", "运行环境") 传入 dev/prod，再让 Viper 加载对应 config.dev.yaml 或 config.prod.yaml。
关键点在于：环境标识（如 dev）和 Gin 框架模式（debug/release）是两件事，可以映射但不能混用。例如生产环境通常设 GIN_MODE=release，但你的 config.prod.yaml 可能还包含 log_level: warn、redis.addr: redis-prod:6379 等。
- 不要把所有配置塞进
GIN_MODE，它只负责框架层行为 - Viper 的
viper.SetConfigName(fmt.Sprintf("config.%s", env))是加载多环境配置的核心 - 命令行 flag（如
-env=prod）优先级高于配置文件，适合部署时覆盖
宝塔面板部署时 GIN_MODE 不生效的典型原因
你在宝塔终端里 echo $GIN_MODE 能看到值，但 Go 程序启动后还是 debug 模式？大概率是宝塔后台用 www 用户执行程序，而该用户 shell 环境里没继承 GIN_MODE。
验证方式：切到 www 用户执行 sudo -u www bash -c 'echo $GIN_MODE'，如果为空，说明环境变量没透传过去。
- 正确做法是在 systemd service 文件里显式写死：
Environment="GIN_MODE=release" - 或者在宝塔「计划任务」或「网站」反向代理启动脚本中，用
GIN_MODE=release /www/wwwroot/myapp/myapp方式调用 - 别依赖
/etc/profile.d/xxx.sh—— 它只影响交互式 shell，不影响 systemd 或 Nginx 子进程
router.Run() 前后设置模式的实际效果差异
gin.SetMode(gin.ReleaseMode) 必须在 gin.Default() 或 gin.New() 之后、router.Run() 之前调用才有效。放错位置会导致部分中间件（比如 gin.Logger()）已按旧模式初始化，后续再设无效。
更稳妥的做法是：完全放弃代码内设模式，统一用环境变量 + 启动命令控制。例如宝塔部署时，用以下命令启动：
GIN_MODE=release ./myapp -env=prod -port=8080
这样既明确，又避免因函数调用顺序出错导致模式未生效。复杂点在于：你要确保所有子进程（比如 exec.Command 启动的外部命令）也继承该变量，否则日志或调用链可能仍打 debug 内容。
