Spring Boot@ConditionalOnProperty多策略Bean异常及React 19 ESLint规则疑问

针对你遇到的@ConditionalOnProperty配合Repository加载不稳定的问题，从以下几个方向排查遗漏点：

• 检查注解的完整配置：确保每个Repository类上的@ConditionalOnProperty注解参数完整，比如Postgres实现类的注解应该是：

  @Repository
  @ConditionalOnProperty(prefix = "app", name = "storage", havingValue = "postgres", matchIfMissing = false)
  public class PostgresTreeRepository implements TreeRepository { ... }
  

  重点确认prefix是否正确（避免把app.storage直接写在name里导致属性匹配失败），以及havingValue的字符串大小写是否和配置文件完全一致。
• 组件扫描范围验证：确认两个Repository类所在的包被@SpringBootApplication或@ComponentScan覆盖，Spring无法扫描到类的话，注解逻辑根本不会触发。可以在启动日志里搜索Bean的类名，看是否有加载记录。
• 排查属性加载优先级：Spring的配置属性加载有优先级（比如命令行参数>环境变量>application.yml），检查是否有其他渠道的配置覆盖了app.storage=postgres的设置。可以在启动时添加--debug参数，查看属性加载的详细日志，确认最终生效的app.storage值。
• 避免条件注解冲突：如果Repository类上还存在其他条件注解（比如@ConditionalOnClass），检查是否存在依赖缺失的情况（比如Postgres驱动偶尔未正确引入），导致条件不满足。
• 检查重复Bean定义：确认是否有其他配置类、测试类或自动配置逻辑也定义了TreeRepository类型的Bean，导致Spring在注入时出现歧义或错误匹配。

即使使用React Compiler，相关ESLint规则依然具备语义相关性，原因如下：

• react-hooks/exhaustive-deps：该规则核心是提醒你useEffect/useCallback等hooks的依赖完整性，而非单纯的性能优化。即使Compiler能自动稳定一些引用，但若依赖逻辑上缺失，依然会导致业务逻辑错误，ESLint的提示能帮你规避这类逻辑bug。
• react/jsx-no-unstable-nested-components：虽然Compiler能对嵌套组件做优化，但把组件定义在父组件内部本身就不符合代码结构的最佳实践，且部分场景下Compiler的优化无法完全抵消不必要的组件创建开销，ESLint规则能引导你保持更清晰的代码组织。
• 覆盖Compiler未处理的场景：Compiler主要针对组件和内置hooks的引用稳定性做优化，但自定义hooks、非组件的函数引用等场景，依然需要依赖ESLint规则来提醒你保持引用稳定，避免潜在的渲染异常或性能问题。

内容的提问来源于stack exchange，提问作者Alejandro Campos