Nacos 只做服务发现的配置边界

引入 Nacos 后很容易把“注册中心”和“配置中心”混在一起讨论。这个项目明确当前只使用 Nacos Discovery，不使用 Nacos Config 管业务配置。

一、Nacos 承担什么

服务启动时向 Nacos 注册实例，并通过服务发现找到下游服务。lb://service-provider 这类调用依赖这份实例列表。

二、Nacos 不承担什么

项目显式关闭：

spring:
  cloud:
    nacos:
      config:
        enabled: false

https://github.com/springvortex/spring-cloud-alibaba/blob/main/service-provider/src/main/resources/config/application-nacos.yaml

业务配置仍在本地 Profile 中，修改后需要重新打包重启。

三、为什么这个边界有价值

只做服务发现时，配置链路更简单：不用处理配置导入顺序、命名空间、灰度配置和动态刷新。排查启动问题时，也不会同时怀疑远程配置和本地配置。

四、公共认证和服务地址分开

Nacos 认证放在公共 Profile，服务地址按 dev、prod 环境维护。这样账号规则一致，环境拓扑仍可不同。

五、经验总结

Nacos Config 当然可以做，但要等确实需要动态配置、多环境集中管理时再引入。架构组件不是越多越好，职责边界清楚更重要。