关于SpringCloud的bootstrap阶段PropertySources的建议

**你的特性请求和某个问题有关吗？请描述**

- SpringCloud项目一般会将父上下文bootstrap阶段相关的配置约定在本地`bootstrap.yml/properties`文件中（例如`spring.application.name`、远程配置地址/开关等），而将远程配置PropertySource放置在子上下文环境中。我认同这种机制能很好的隔离用户和环境配置，用户在远程的配置不会影响到某些预设配置（如服务ID、注册中心地址等）。
- 而Apollo在启用eagerLoad之后，无论什么阶段都会将ApolloPropertySources前置，在SpringCloud项目中会打破上述机制。即使在bootstrap阶段，`spring.application.name`等配置值仍会优先从Apollo远程配置中获取，极易因用户的不当配置引发预期之外的问题，如调用链路中断（`spring.application.name`常被用于各种组件的唯一标识，如eureka服务的appId；这种是应当在项目建立时就固定的约定）。
- SpringCloud config方式和Apollo方式propertySources的区别见末尾。

**清晰简洁地描述一下你希望的解决方案**

- 希望与SpringCloud项目集成时可以遵循远程配置约定。在bootstrap环境中不加载`ApolloPropertySources`或者使用推荐的扩展方式引入`ApolloPropertySources `（在`spring.factories`中扩展`org.springframework.cloud.bootstrap.BootstrapConfiguration`）。

**清晰简洁地描述一下这个特性的备选方案**

- 我当前的处理方式是在自定义的`EnvironmentPostProcessor`中通过提前占位的方式阻止bootstrap阶段的`ApolloBootstrapPropertySources`添加。如图所示：

**其它背景**

- Apollo SpringCloud父子阶段的propertySources:

- SpringCloud config父子阶段的propertySources: