前言

在springboot里经常使用application.properties类似的properties作为配置文件，通过配置文件进行springboot项目的配置。

例如：

########################## application级别通用配置 ##########################
########################## Feign通用配置 ##########################
##### ribbon配置可以废除了 SpringBoot升级到2.6以后的 使用LoadBalance
## 从注册中心刷新servelist的时间 默认30秒，单位ms
ribbon.ServerListRefreshInterval=15000
## 请求连接的超时时间 默认1秒，单位ms
ribbon.ConnectTimeout=30000
## 请求处理的超时时间 默认1秒，单位ms
ribbon.ReadTimeout=30000
## 对所有操作请求都进行重试,不配置这个MaxAutoRetries不起作用 默认false
#ribbon.OkToRetryOnAllOperations=true
## 对当前实例的重试次数 默认0
ribbon.MaxAutoRetries=0
## 切换实例的重试次数 默认1
ribbon.MaxAutoRetriesNextServer=0

##### nacos(注册中心和配置中心)地址
spring.cloud.nacos.server-addr=${nacos.server-addr}
#spring.cloud.nacos.username=${nacos.username}
#spring.cloud.nacos.password=${nacos.password}

在springboot项目里，这是非常常见的， 在springcloud的微服务项目，每个微服务也是使用spingboot作为基础脚手架来搭建项目的， 有些项目使用了application.yml或者bootstrap.yml，发现配置项无效。

这里的问题，是由于没有引入支持bootstrap.yml的包进来， 可以在项目里引入

        
            org.springframework.cloud
            spring-cloud-starter-bootstrap
        

引入以上的包即可后bootstrap.yml中的配置即可生效

在springboot的环境配置信息中，其配置信息的优先级如下

启动参数 > properties中的配置 > yml中的配置 > configuration Center的配置。

​

结束语

这个坑是不经意中遇到的，springcloud并不是一个完整的微服务的环境框架，而是一套技术框架加上一个搭建微服务的脚手架，

通过java的包依赖机制，加上使用maven和grandle构建工具而实现通过java完成微服务的实现，所以在很多的技术手段都是通过代码或者配置方式之一的耦合方式实现的。 这样势必会在业务代码中包含了不应该关心的东西，

这个坑如果在启动过程中使用yml的话，是不会踩到了， 当然如果是配置中心比如nacos里的yml格式文件，只要配置中心的配置被加载了，也不会受到影响， 否则，自己在项目里添加的application.yml和bootstrap.yml就是不能加载。 加上了spring-cloud-starter-bootstrap才行， java的模块化是实现上的模块化，springcloud架构下的云生态同样也是实技术化上的模块化，并不是体系上的模块化，这点也就是springcloud在未来的云生态下止步不前的原因。