上线前挑配置的刺
假设配置一定会出事，逐项找出默认值、密钥和环境差异的坑
你是负责上线的 SRE，任务是挑刺而不是确认。审查下面的配置和环境变量清单：1）找出所有依赖默认值才能工作的项，并把默认值写出来；2）标出密钥、连接串、超时、重试、并发上限中任一环境不一致就会出事的项；3）列出「本地能跑、线上会挂」的具体路径；4）给一份上线前逐项打勾的检查清单，按风险排序。不要评价格式，不要假设平台会兜底。 [配置文件/环境变量清单/部署环境]
使用建议
重点看没写出来的值：默认超时、默认重试次数和空字符串密钥，往往比写错的值更危险。
适合什么场景
- 新服务要接第一波生产流量，而配置是从 staging 直接复制过来的。
- 服务要迁到新区域，需要知道哪些设置正在悄悄依赖旧环境。
不适合的场景
- 只是打开一个有明确默认值的功能开关：做全量审查属于过度反应。
- 配置由平台模板统一注入且不可修改：把时间花在应用行为上更值。
示例
输入
DATABASE_URL=postgres://app@db:5432/app REDIS_URL=redis://cache:6379 REQUEST_TIMEOUT= RETRY=3 LOG_LEVEL=debug
你会得到
先报 `REQUEST_TIMEOUT` 为空：多数客户端会解析失败，或者干脆落到无超时，这属于上线即挂，不是警告。生产环境里 `LOG_LEVEL=debug` 可能把 PII 写进日志，`RETRY=3` 在非幂等写接口上会放大重复下单。检查清单按「启动失败 > 数据错误 > 成本/噪声」排序，并写出每个键在目标环境的期望值。
常见误用
- 只让它「检查有没有问题」却不给部署环境：它无法判断 `redis://cache` 在线上是否能解析。
- 把检查清单当一次性任务：没有指定谁在哪个环节打勾，清单就不会被真正执行。
可以这样改
- 加「假设这是金融业务，任何默认值都必须显式写出」，审查会从风格转向失效模式。
- 要求「每项给出错时的用户可见现象」，能快速分辨致命项和只是难排查的项。