配置中心的差别不只在于能不能存 KV，还在配置隔离、变更通知、权限、灰度和回滚。注册发现方案见注册中心项目对比。
本文只比较开源且支持多语言 SDK 或语言无关 API 的方案，不列绑定单一应用框架的组件。
方案对比
| 方案 | 多语言接入 | 配置能力 | 主要取舍 |
|---|---|---|---|
| Nacos | Java / Go 官方 SDK；其他语言有社区 SDK 和 HTTP API | 动态配置、监听、历史和灰度 | 配置和注册共用同一控制面 |
| Apollo | Java / .NET 原生 SDK；另有多语言 SDK 和 HTTP API | 应用 / 环境隔离、权限、发布、灰度、回滚 | 需要运维 Apollo 服务与 MySQL |
| Consul KV | HTTP API / Consul Template，语言无关 | KV、Watch 和模板化配置分发 | 适合轻量配置；不提供完整的应用级发布治理 |
| ZooKeeper | Java / C 官方绑定；Go / Python 社区客户端 | ZNode、Watch，可自行实现配置分发 | 原语型方案，发布、审计和回滚流程需自行实现 |
| Kubernetes ConfigMap / Secret | 挂载文件、环境变量或 Kubernetes API，语言无关 | 配置作为 Kubernetes 资源挂载或注入 | 进程不自动热加载；治理依赖部署流程 |
| Polaris（北极星） | Java、Go、C++、PHP SDK | 动态配置、版本和灰度发布 | 平台能力和接入方式需要一并评估 |
| etcd | gRPC / HTTP JSON API，语言无关 | 一致性 KV、Watch 和事务，可自行实现配置分发 | 环境模型、权限、发布、历史回滚和客户端要自己实现 |
怎么选
| 需求 | 优先评估 |
|---|---|
| 已经用 Nacos，想复用配置能力 | Nacos |
| 需要配置控制台、权限、灰度和回滚 | Apollo |
| 配置随 Kubernetes 工作负载发布 | ConfigMap / Secret |
| 已有 Polaris 服务治理平台 | Polaris |
| 已有 Consul，管理轻量参数配置 | Consul KV |
| 已有 ZooKeeper，需要共享配置与 Watch | ZooKeeper |
| 自建控制面，能接受自己实现配置治理 | etcd |
ConfigMap 挂载为卷时，内容会在 kubelet 后续同步时更新；进程环境变量不会随 ConfigMap 更新，需要替换 Pod；挂载文件变化后也要由应用主动重读。Kubernetes 更新示例。密钥应使用 Secret，并配置好集群加密与访问控制。
无论选哪种方案，都要先确定配置服务不可用时的启动策略、客户端缓存策略和无法热更新配置的发布方式。