comparable 接口不参与 spring boot 配置文件解析，配置加载顺序由 propertysource 机制和加载时机决定；真正的优先级控制依赖 @order、ordered 或 @priority，由 annotationawareordercomparator 处理。
Comparable 接口本身不参与 Spring Boot 配置文件的解析过程，也不直接用于配置项（如 application.yml 或 application.properties）的加载顺序控制。Spring Boot 解析配置文件是基于 PropertySource 机制和 Environment 抽象完成的，整个过程与对象是否实现 Comparable 无关。
Spring Boot 中真正的“Priority 排序”机制
Spring Boot 使用 @Order、Ordered 接口或 @Priority 注解来控制 Bean 初始化、拦截器、过滤器、Runner 等组件的执行顺序，底层统一由 AnnotationAwareOrderComparator 处理。它不依赖 Comparable，而是：
- 优先读取
@Order(value = X)的整数值（越小越靠前） - 若未标注 @Order，则检查类是否实现
Ordered接口并调用getOrder() - 若两者都没有，则默认返回
Ordered.LOWEST_PRECEDENCE（即最后执行） -
@Priority是 JSR-330 标准注解，Spring 兼容支持，语义等同于 @Order
为什么 Comparable 在配置解析中不生效
配置文件解析发生在容器启动早期，由 ConfigurationPropertySourcesProcessor 和 PropertySourcesLoader 等非 Bean 组件完成。这些类操作的是 PropertySource> 实例列表，其顺序由加载时机（如 classpath 路径、profile 激活顺序、spring.config.import 声明顺序）决定，而非对象的 compareTo 方法。
即使你自定义了一个配置类并让它实现 Comparable，Spring 不会调用它的 compareTo 来排列配置源 —— 因为这不是设计目标，也没有对应扩展点。
想让自定义配置项按 Priority 排序？正确做法
如果你希望一组配置项（比如多个 @ConfigurationProperties 对象）在业务逻辑中按优先级处理，可按以下方式设计：
- 定义一个普通 POJO 类（如
FeatureFlag），包含priority字段 - 不实现 Comparable，而是在使用时用
Comparator.comparing(FeatureFlag::getPriority)显式排序 - 若需全局统一排序逻辑，可创建
FeatureFlagComparator implements Comparator<featureflag></featureflag> - 注入多个同类型 Bean 后，用
Collections.sort(flagList, new FeatureFlagComparator())或流式处理：flagList.stream().sorted(comparator).collect(...)
例外：自定义 PropertySource 时的注意事项
极少数场景下，你可能手动注册 PropertySource（例如从数据库加载配置）。此时若需控制加载顺序，应通过 ConfigurableEnvironment.getPropertySources().addFirst()/addLast() 显式插入位置，而不是靠 Comparable —— 因为 MutablePropertySources 内部是 List 结构，不进行自动比较排序。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
