引入 Nacos 后很容易把“注册中心”和“配置中心”混在一起讨论。这个项目明确当前只使用 Nacos Discovery，不使用 Nacos Config 管业务配置。
一、Nacos 承担什么
服务启动时向 Nacos 注册实例，并通过服务发现找到下游服务。lb://service-provider 这类调用依赖这份实例列表。
二、Nacos 不承担什么
项目显式关闭：
spring:
cloud:
nacos:
config:
enabled: false
业务配置仍在本地 Profile 中，修改后需要重新打包重启。
三、为什么这个边界有价值
只做服务发现时，配置链路更简单：不用处理配置导入顺序、命名空间、灰度配置和动态刷新。排查启动问题时，也不会同时怀疑远程配置和本地配置。
四、公共认证和服务地址分开
Nacos 认证放在公共 Profile，服务地址按 dev、prod 环境维护。这样账号规则一致，环境拓扑仍可不同。
五、经验总结
Nacos Config 当然可以做，但要等确实需要动态配置、多环境集中管理时再引入。架构组件不是越多越好，职责边界清楚更重要。