根本原因是环境变量未注入，Golang不自动加载.env文件；本地靠export或shell预设，线上需在systemd/Docker/K8s中显式声明，漏配将导致空值静默失败。
用 os.Getenv 读配置时，为什么本地能跑线上却空值？
根本原因是环境变量没注入，不是代码写错了。Golang 本身不自动加载 .env 文件，os.Getenv 只读操作系统级环境变量。
本地开发常用 export ENV=dev 或 shell 脚本预设；生产环境（比如 systemd、Docker、K8s）必须显式声明，漏掉就返回空字符串——这常导致数据库连不上、密钥缺失等静默失败。
- 本地调试可临时用
env ENV=prod go run main.go模拟生产环境 - Docker 中务必在
Dockerfile里用ENV ENV=prod，或运行时加-e ENV=prod - Kubernetes 需在
Deployment的env字段中定义，不能只靠 ConfigMap 挂载文件
要不要引入 viper？它真能解决环境差异问题吗？
viper 能统一读取不同来源的配置（环境变量、JSON/YAML 文件、远程 etcd），但默认行为反而容易埋坑：它会自动合并多个来源，且优先级不直观。
典型陷阱是本地有 config.yaml 设了 port: 8080，同时又设置了环境变量 PORT=9000，但没调用 viper.AutomaticEnv() 或没设置前缀，结果还是读到 8080。
立即学习“go语言免费学习笔记（深入）”；
- 必须显式调用
viper.AutomaticEnv()才启用环境变量覆盖 - 用
viper.SetEnvPrefix("APP")后，APP_PORT才对应port字段，否则不匹配 - 生产环境禁用
viper.ReadInConfig()（避免误读本地配置文件），只依赖环境变量
build tags 能隔离本地与生产逻辑吗？
可以，但仅限编译期硬切，适合开关日志级别、禁用 mock 数据库等简单场景。它不是运行时配置方案，也不能替代环境变量。
当用户提及 GitHub URL，或要求分析、审查、探索或理解任意 GitHub 项目、仓库或代码库时，请使用此技能。触发条件包括以下短语：“分析这个项目”、“看看这个仓库”、“analyze this repo”、“what does this project do”，或消息中包含任何 github.com URL。
例如用 //go:build prod 标记生产专用初始化代码，本地 go build 默认不包含；但若忘记加 -tags prod，就会漏掉关键逻辑（如证书校验、监控上报）。
- 标签名建议小写、无下划线，如
prod、dev，避免GOOS冲突 - 多个标签用逗号连接：
go build -tags="prod,with_metrics" - 不要用 build tags 处理数据库地址、密钥等敏感信息——它们会留在二进制里，有泄露风险
本地用 SQLite、生产用 PostgreSQL，怎么避免 import 冲突？
直接在 main.go 里写 import _ "github.com/mattn/go-sqlite3" 和 import _ "github.com/lib/pq" 会导致两个驱动都注册，可能引发 sql: unknown driver "sqlite3" 这类奇怪错误（尤其跨平台构建时）。
正确做法是按环境拆包：把数据库初始化逻辑封装进 db/dev.go（含 sqlite3 导入）和 db/prod.go（含 pq 导入），再用 build tags 控制编译。
/* db/dev.go */ //go:build dev package db <p>import ( _ "github.com/mattn/go-sqlite3" )</p>
/* db/prod.go */ //go:build prod package db <p>import ( _ "github.com/lib/pq" )</p>
这样既能保证编译产物干净，又能防止本地误连生产 DB。
最易被忽略的是：build tags 必须放在文件顶部紧贴 package 声明之前，中间不能有空行或注释，否则无效。
