Nacos 配置模型与多环境

一套配置代码要跑开发、测试、生产三套环境，靠的就是 namespace/group/dataId 三键组合。本章讲怎么用这三个键组织配置，以及切换环境时只需改什么。

三键再回顾

每个键管一层，组合起来唯一确定一份配置：

键	职责	默认值	典型取值
namespace	环境/租户级隔离	public	dev、test、prod
group	同环境内的业务分组	DEFAULT_GROUP	pay-group
dataId	具体某份配置	无	order-service.properties

环境隔离：一个 namespace 一套环境

最常见的实践是 dev/test/prod 各建一个命名空间，三套配置完全隔离：prod 的配置不会漏到 dev，dev 随便改也不影响生产。

客户端连哪个环境，只由 namespace 一个配置项决定（以下配置需放入 Spring Cloud 工程）：

# application.properties（或 bootstrap.properties）
spring.cloud.nacos.config.server-addr=localhost:8848
spring.cloud.nacos.config.namespace=dev
spring.cloud.nacos.config.group=DEFAULT_GROUP
spring.cloud.nacos.config.file-extension=properties

切到生产时，只需把 namespace 改成 prod，其余不变，重新部署或刷新即可：

spring.cloud.nacos.config.namespace=prod   # 只改这一行，就从 dev 切到 prod

group 分组：同环境内按业务分

一个环境里往往有多个业务线，想在同一 namespace 下再做隔离时用 group。例如公共基础配置放 DEFAULT_GROUP，支付相关放 pay-group，交易相关放 trade-group。客户端通过 group 参数指定要读哪一组：

spring.cloud.nacos.config.group=pay-group

注意 group 同样作用于服务注册与发现（服务也有 groupName），两边保持一致才不会互相找不到。

dataId：同命名空间下唯一

定位一份配置要三键齐备：namespace 相同、group 相同的前提下，dataId 必须唯一；对同一 dataId 再次发布就是覆盖更新（历史版本仍可回滚）。所以"同名配置放不同 namespace"互不干扰，"同 namespace 不同 group"也互不干扰。

三种粒度怎么选

按"谁在什么维度上需要隔离"来选择用哪个键：

隔离诉求	用哪个键	举例
环境不同（开发/测试/生产）	namespace	各环境一个命名空间
业务域/团队不同	group	trade-group、pay-group
单份配置不同	dataId	order-service.properties

经验法则：环境差异优先走 namespace（安全、直观）；同环境里少数应用的差异化再考虑 dataId 里的 profile 段；group 数量别开太多，保持分组可数。

多环境落地示例

三个环境共用一套客户端配置模板，只有 namespace 不同；每个环境里的配置内容各自演化，互不可见。服务注册侧同理，把 discovery 的 namespace 指向同一环境值，注册与配置就天然对齐：

spring.cloud.nacos.discovery.namespace=dev   # 与 config.namespace 保持一致

小结

配置多环境的本质就是三键的排列组合：namespace 管环境、group 管业务、dataId 管单份配置。开发阶段把 namespace 规划清楚，上线后就只剩"改一行 namespace"这种低成本切换。