nosuchbeandefinitionexception主因是自动配置抢占bean注册时机：①@componetscan范围过大误扫autoconfigure包；②@conditionalonmissingbean使自动配置优先创建bean，导致自定义@bean被忽略；③缺少对应starter依赖，autoconfiguration类根本未加载。
刚写完一个SpringBoot项目，启动时报NoSuchBeanDefinitionException，控制台明明打印了@Bean创建日志，但@Autowired却找不到——这不是代码写错了，而是自动配置的条件判断在你没注意时悄悄接管了Bean生命周期。
搞清自动配置加载顺序，别让@Bean被“先手”覆盖
第一步：确认你的@Configuration类是否被@ComponentScan扫到，且扫描路径不包含spring-boot-autoconfigure包（如org.springframework.boot.autoconfigure）。如果@ComponentScan("com.example")写成@ComponentScan("com")，就会误扫自动配置类，引发类加载冲突或重复注册。
第二步：检查你的@Bean方法是否被@ConditionalOnMissingBean(DataSource.class)这类注解的自动配置类抢先占位。SpringBoot的DataSourceAutoConfiguration默认在用户@Bean之前执行，一旦它已创建了DataSource实例，你的@Bean即使存在也不会注册进容器——【@Bean方法必须早于自动配置类触发，否则会被忽略】。
第三步：用@SpringBootApplication(exclude = {DataSourceAutoConfiguration.class})临时排除干扰项，验证是否是自动配置抢跑了。这一步能快速定位问题根源，不是最终方案，但能帮你把“Bean消失”从玄学拉回可控范围。
配置属性没生效？先看它有没有被更高优先级的配置覆盖
方法一：检查application.yml中spring.datasource.hikari.maximum-pool-size是否被spring.jpa.properties.hikari.maximum-pool-size覆盖。HibernateJpaAutoConfiguration会读取spring.jpa.properties.hikari.*前缀的配置，并优先应用——【只要spring.jpa.properties.hikari.*存在任意一项，spring.datasource.hikari.*全失效】。
方法二：启用DEBUG日志，加logging.level.org.springframework.boot.autoconfigure=DEBUG。启动时搜索“Condition evaluated as true”和“Condition evaluated as false”，直接看到哪个@ConditionalOnProperty(name="spring.datasource.url")因缺配置而跳过，比猜快十倍。
方法三：访问/actuator/conditions端点（需引入spring-boot-starter-actuator），页面会列出所有自动配置类的评估结果，绿色✔代表生效，红色✘代表被跳过，点击展开能看到具体哪条条件不满足。
依赖引错导致自动配置根本没加载
如果你期望RedisTemplate自动装配，但启动后连RedisConnectionFactory都没出现，先执行mvn dependency:tree -Dincludes=org.springframework.boot:spring-boot-starter-data-redis。如果输出为空，说明starter根本没引入——自动配置不会凭空发生，【没有starter，就没有对应的AutoConfiguration类被扫描】。
常见陷阱：只加了spring-boot-starter-web，却忘了spring-boot-starter-data-jdbc。后者才是触发DataSourceAutoConfiguration的关键依赖；缺它，哪怕application.yml写了spring.datasource.url，自动配置也会静默跳过。
这一步操作起来很简单，直接把文件拖进去就行。
