开启Spring Cloud Bootstrap后@RefreshScope配置刷新失效问题咨询

引入spring-cloud-starter-bootstrap依赖后，Spring Cloud会自动关闭Spring Boot 2.4+版本默认的ConfigData配置加载机制，切换为传统Bootstrap上下文模式，此时/actuator/refresh端点的处理逻辑从ConfigDataContextRefresher切换为LegacyContextRefresher。出现仅返回["spring.cloud.bootstrap.enabled"]、被@RefreshScope修饰的Bean不刷新的问题，本质是以下两类配置错误导致的：

• LegacyContextRefresher未能正确从Config Server拉取业务配置，仅识别到自身Bootstrap上下文内置的可刷新属性，因此返回列表仅包含spring.cloud.bootstrap.enabled
• 配置源归属划分错误，LegacyContextRefresher默认仅跟踪Bootstrap上下文中加载的配置项，业务配置如果仍放在主上下文的ConfigData加载路径下，不会被纳入刷新范围，导致业务Bean无法感知配置变更。

• 修正配置加载文件路径
  将所有Config Client的连接配置（包括Config Server地址、拉取的配置文件规则、Profile匹配规则）从application.yml迁移到bootstrap.yml中，确保LegacyContextRefresher启动时可以正确读取连接参数，从Config Server拉取到对应业务配置。同时删除原配置中残留的spring.config.import: "configserver:"类ConfigData导入声明，避免两种配置加载机制发生属性源归属冲突。
• 放开刷新扫描范围限制
  在bootstrap配置中添加如下参数，调整LegacyContextRefresher的可刷新属性扫描规则，使其可以跟踪主上下文内加载的业务配置变更：

  spring:
    cloud:
      refresh:
        refreshable: "*"
  

• 检查Bean注解注册逻辑
  确保被@RefreshScope修饰的控制器或业务类没有被额外添加@Configuration注解，避免Bean被提前初始化为不可代理的实例，导致刷新动作无法触发Bean的销毁与重建流程。
• 确认端点路由准确性
  保证POST刷新请求直接发送到业务应用自身的actuator端点，没有被反向代理或端口映射规则转发到Config Server实例上。如果Config Server和业务应用存在端口复用，需要为业务应用配置独立的服务端口与actuator暴露端口，避免路由匹配错位。

完成上述配置后再次发送刷新请求，接口返回的属性列表应当包含所有拉取到的业务配置key，不再仅返回spring.cloud.bootstrap.enabled，此时调用被@RefreshScope修饰的接口，即可看到最新配置已经生效。

内容的提问来源于stack exchange，提问作者Jakub Moravec