先确认环境变量是否真正注入进程，再用os.LookupEnv区分“未设置”与“值为空”，关键变量缺失时log.Fatal；CI/Docker/K8s中须显式注入，禁用.gitlab-ci.yml或Dockerfile硬编码，.env仅限本地开发且需.gitignore保护。
os.Getenv("ENV") 读不到怎么办
直接调用 os.Getenv("ENV") 返回空字符串，不是代码写错了，而是环境变量根本没设进去。CI 流水线里尤其常见：GitLab CI 的 .gitlab-ci.yml 没显式定义 ENV，GitHub Actions 的 env: 块漏了，或者 Docker run 时忘了加 -e ENV=prod。
验证方式很简单：go run main.go && echo $ENV（本地）或在 CI 脚本开头加 echo "ENV=$ENV"。别依赖 fallback 逻辑掩盖缺失——fallback 只是兜底，不是默认。
- CI 配置必须显式注入：GitHub Actions 中用
env: {ENV: ${{ secrets.ENVIRONMENT }}；GitLab CI 用variables: {ENV: "staging"} - Docker 启动时禁止只写
docker run mysvc，必须带-e ENV=prod或通过--env-file加载 - 本地开发别靠
.env文件自动加载——godotenv.Load()不会覆盖已存在的ENV，如果系统已有ENV=dev，再 Load.env也改不了
敏感配置为什么不能写进 YAML
因为 YAML 文件常被提交到 Git，而 database.url、redis.password 这类字段一旦进仓库，就等于把钥匙挂在门上。更危险的是，不同环境的 YAML 文件结构一致，config.dev.yaml 和 config.prod.yaml 只差一行 URL，但 CI 自动部署时拉的是 prod 分支，却可能因分支合并错误混入 dev 配置。
真正该放进 YAML 的只有非敏感、可版本化、无安全风险的参数：比如 http.timeout: 5s、retry.max_attempts: 3、feature.flag.enable_cache: true。
立即学习“go语言免费学习笔记（深入）”；
- 所有连接地址、密钥、token 必须走环境变量：
os.Getenv("DB_URL")、os.Getenv("JWT_SECRET") - 启动时做校验：如果
ENV == "prod"且DB_URL包含"localhost"或"127.0.0.1"，直接log.Fatal("refusing to run prod with local DB") - CI 构建阶段禁止
godotenv.Load(".env.prod")—— 它会把敏感值塞进镜像层，哪怕后续删掉文件，历史层仍可被提取
go build -ldflags 注入 BuildEnv 的坑
-ldflags "-X 'main.BuildEnv=prod'" 看似轻量，但有两个硬性限制：目标变量必须是可导出的 var，且类型只能是 string。写成 buildEnv string（小写）或 BuildEnv int 都会静默失败，构建不报错，运行时还是默认值。
它适合做编译期标记（如 Prometheus 的 build_info{env="prod"}），但不适合替代运行时环境判断——因为值在二进制里就固化了，容器启动时再改 ENV 环境变量也无效。
- 声明必须是：
var BuildEnv = "dev"（首字母大写 + string 类型） - 别用它控制数据库连接逻辑：要连哪个库，必须由
os.Getenv("DB_URL")决定，而不是BuildEnv - 多个注入用空格分隔：
-ldflags "-X 'main.BuildEnv=prod' -X 'main.BuildTime=$(date -u +%Y-%m-%dT%H:%M:%SZ)'"，单引号不能省，否则 shell 会提前展开
Docker 镜像不变性与环境变量绑定
一个镜像打出来就该永远不变，环境差异全靠启动时注入的环境变量驱动。但很多人在 Dockerfile 里写 ENV ENV=prod 或 COPY config/config.prod.yaml ./config.yaml，这直接破坏了不可变性——你得为每个环境 build 一个镜像，CI 流水线爆炸，镜像仓库迅速臃肿。
正确做法是镜像里只放通用二进制和非敏感配置模板，所有差异化内容延迟到 docker run 或 Kubernetes Pod spec 里注入。
- Dockerfile 里删掉所有
ENV ENV=xxx，也不COPY任何带环境后缀的配置文件 - Kubernetes 中用
envFrom: [configMapRef: {name: svc-config}, secretRef: {name: svc-secrets}]，而非把值写死在 deployment.yaml 里 - 本地调试用
docker run -e ENV=dev -e DB_URL=...，CI 用 pipeline variables 注入，保持入口一致
最易被忽略的一点：Kubernetes 的 ConfigMap/Secret 更新后，Pod 不会自动 reload，必须配合 Reloader 或用 volume mount + inotify 监听，否则你以为更新了配置，其实服务还在用旧值。
