背景 同一镜像如果因环境不同而重新构建，就很难证明测试与生产运行的是同一个产物。应把部署配置与不可变应用分离。 核心判断 镜像只包含程序和非敏感静态资源，环境参数在启动时注入。 配置加载后统一校验，必要值缺失应直接失败。 记录镜像 digest 和配置版本，回滚时同时检查二者兼容性。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 FROM gcr.io/distroless/static-debian12 COPY app /app ENTRYPOINT ["/app"] 边界与误区 示例假定 Go 等静态二进制可在该运行镜像中执行；动态链接、CA、时区和文件权限需单独确认。不要把密钥 COPY 进镜像层。 验证方式 同一个 digest 分别在测试与生产配置下启动，核对生效值和日志脱敏。验证配置缺失、不可写目录以及运行用户权限。 小结 镜像只包含程序和安全默认值，环境差异通过运行时配置注入并在启动时校验。
背景 同一份程序在本地正常、容器里却连错数据库，常见原因不是网络，而是配置优先级不明确。读取配置应该是可复现的过程，不是各模块自行查环境变量。 核心判断 固定默认值、配置文件、环境变量、显式启动参数的覆盖顺序。 区分未设置与明确设置为空，布尔参数不能拿零值当作未传入。 合并完成后统一校验地址、超时和容量，启动日志只输出非敏感有效值。 最小示例 下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。 type Config struct { Addr string Timeout time.Duration Debug bool } func Load() (Config, error) { cfg := Config{Addr: ":8080", Timeout: 5 * time.Second} if err := applyEnv(&cfg); err != nil { return Config{}, err } if err := applyFlags(&cfg); err != nil { return Config{}, err } if cfg.Addr == "" || cfg.Timeout <= 0 { return Config{}, fmt.Errorf("invalid address or timeout") } return cfg, nil } 边界与误区 解析失败不能悄悄退回默认值；否则错误的超时配置会被伪装成启动成功。示例只展示合并入口，applyEnv、applyFlags 应实现转换、错误返回和显式参数检测。 验证方式 用表驱动测试覆盖多来源冲突、空值、非法 duration 和缺失密钥。每次发布记录配置来源，禁止把令牌和数据库密码打印到日志。 小结 配置来源变多后，最重要的是固定优先级并输出脱敏后的有效配置。