线上配置到底该放环境变量、配置文件，还是配置中心？聊聊运维视角的取舍

【背景】 最近复盘一次线上事故：某个服务的连接池参数被写死在镜像里，改一次要重新发版、灰度、回滚走一整圈，结果改完没生效——因为配置其实是从环境变量读的，镜像里那份根本没被加载。最后排查了俩小时，锅算在「配置到底在哪」这件事上。

我干运维 10 年，配置管理这件事上翻车最多、也最容易被轻视。今天想借帖子聊聊：线上配置到底应该放在哪里？

【几种常见做法】

1. 环境变量派（12-factor 信徒）：配置全走 env，容器里零配置文件。优点：和部署平台强绑定，gitlab/k8s 一眼能看到。缺点：复杂配置（连接池、feature flag、路由表）根本塞不进 env；调试时「这个值到底从哪来」经常要靠翻部署脚本。
2. 配置文件派：应用自带 application.yml / nginx.conf，部署时挂载或打包。优点：结构清晰、可 diff、可回滚。缺点：和代码耦合，改配置容易变成发版。
3. 配置中心派（Nacos / Apollo / Consul）：配置热更新、可灰度、有审计。优点：运维友好，不用发版。缺点：多一个依赖，配置中心挂了就是 P0；「谁改的、为什么改」经常靠嘴说，审计日志形同虚设。
4. 混合派：静态配置进镜像，动态配置走配置中心，敏感配置走 K8s Secret + env。大多数团队最后都落在这一档，但「哪些算静态、哪些算动态」的边界，每个团队都不一样。

【我的倾向】 我个人偏向「默认走配置中心，但把配置当代码管」——也就是配置中心里存的是 YAML，走 PR + review + 灰度，变更留痕。原因三条：

• 运维视角下，「改配置不发版」是底线，否则事故响应时间直接翻倍；
• 配置中心 + 版本化 + 灰度，能把「改错配置」的回滚从小时级压到分钟级；
• 敏感配置一定要走 Secret 或 KMS，别偷懒塞配置中心明文。

但我承认这条路有代价：配置中心本身要 HA、要审计、要有权限模型，小团队可能扛不动。所以我想听听大家：

【想听大家聊的】

• 你的团队现在配置到底放哪？为什么？有没有翻过「配置到底在哪」这种车？
• 配置中心挂了你们怎么兜底？本地缓存、还是直接降级？
• 敏感配置（DB 密码、AK/SK）你们怎么处理？K8s Secret 够用吗，还是上了 KMS / Vault？
• 你怎么界定「静态配置 vs 动态配置」的边界？有没有一个团队内部的硬规则？

抛砖引玉，欢迎带真实案例来聊。