第二步：在配置列表的最上方，可以看到除了Public之外，多了几个刚才创建的Namepsace。分别在DEV和TEST空间下为alibaba-nacos-config-client应用创建配置内容：
第三步：在alibaba-nacos-config-client应用的配置文件中，增加Namespace的指定配置，比如：spring.cloud.nacos.config.namespace=83eed625-d166-4619-b923-93df2088883a。
这里需要注意namespace的配置不是使用名称，而是使用Namespace的ID。
第四步：启动应用，通过访问localhost:8001/test接口，验证一下返回内容是否正确。这种方式下，目前版本的日志并不会输出与Namespace相关的信息，所以还无法以此作为加载内容的判断依据。
深入思考上面我们分别利用Nacos配置管理功能中的几个不同纬度来实现多环境的配置管理。从结果上而言，不论用哪一种方式，都能够胜任需求，但是哪一种最好呢？
第一种：通过Data ID与profile实现。
优点：这种方式与Spring Cloud Config的实现非常像，用过Spring Cloud Config的用户，可以毫无违和感的过渡过来，由于命名规则类似，所以要从Spring Cloud Config中做迁移也非常简单。
缺点：这种方式在项目与环境多的时候，配置内容就会显得非常混乱。配置列表中会看到各种不同应用，不同环境的配置交织在一起，非常不利于管理。
建议：项目不多时使用，或者可以结合Group对项目根据业务或者组织架构做一些拆分规划。
第二种：通过Group实现。
优点：通过Group按环境讲各个应用的配置隔离开。可以非常方便的利用Data ID和Group的搜索功能，分别从应用纬度和环境纬度来查看配置。
缺点：由于会占用Group纬度，所以需要对Group的使用做好规划，毕竟与业务上的一些配置分组起冲突等问题。
建议：这种方式虽然结构上比上一种更好一些，但是依然可能会有一些混乱，主要是在Group的管理上要做好规划和控制。
第三种：通过Namespace实现。
优点：官方建议的方式，通过Namespace来区分不同的环境，释放了Group的自由度，这样可以让Group的使用专注于做业务层面的分组管理。同时，Nacos控制页面上对于Namespace也做了分组展示，不需要搜索，就可以隔离开不同的环境配置，非常易用。
缺点：没有啥缺点，可能就是多引入一个概念，需要用户去理解吧。
建议：直接用这种方式长远上来说会比较省心。虽然可能对小团队而言，项目不多，第一第二方式也够了，但是万一后面做大了呢？
注意：不论用哪一种方式实现。对于指定环境的配置（spring.profiles.active=DEV、spring.cloud.nacos.config.group=DEV_GROUP、spring.cloud.nacos.config.namespace=83eed625-d166-4619-b923-93df2088883a），都不要配置在应用的bootstrap.properties中。而是在发布脚本的启动命令中，用-Dspring.profiles.active=DEV的方式来动态指定，会更加灵活！。
参考资料Nacos官方文档
代码示例本文示例读者可以通过查看下面仓库的中的alibaba-nacos-config-client项目：
Github：https://github.com/dyc87112/SpringCloud-Learning/
Gitee：https://gitee.com/didispace/SpringCloud-Learning/
如果您对这些感兴趣，欢迎star、follow、收藏、转发给予支持！
以下专题教程也许您会有兴趣Spring Boot基础教程
Spring Cloud基础教程