spring boot自动配置失效的五大原因：包扫描路径过深导致mapper未被扫描；缺少对应starter依赖使自动配置类未加载；@mapperscan注解位置错误或未正确配置；配置属性不满足@conditionalonproperty条件；手动定义同类型bean覆盖了自动配置bean。
启动类包路径太深，Mapper或Service类扫不到
Spring Boot默认只扫描启动类所在包及其所有子包，如果你的Mapper接口放在com.example.dao，而启动类在com.example.web.config，那dao包根本不在扫描范围内，@Mapper注解形同虚设。
第一步：打开启动类（如Application.java），查看它的完整包声明，例如package com.example.boot;
第二步：确认目标类（如UserMapper.java）的包路径，必须是com.example.boot.mapper或com.example.boot.dao这类能被com.example.boot覆盖的路径；如果实际是com.example.infra.mapper，就必须调整。
第三步：要么把Mapper类挪进启动类子包下，要么显式配置扫描范围——在@SpringBootApplication上加scanBasePackages = {"com.example.boot", "com.example.infra"}。注意：不能写成scanBasePackages = "com.example.*"，【通配符不生效，必须写死具体包名】。
依赖缺失导致自动配置类压根没加载
自动配置不是凭空出现的，它依赖starter包触发。比如用了MyBatis但没加spring-boot-starter-data-jpa，JpaAutoConfiguration类根本不会进候选列表，更别说生效了。
方法一：检查pom.xml，确认已引入对应starter。用MyBatis？必须有spring-boot-starter-mybatis；连Redis？缺spring-boot-starter-data-redis就别想RedisTemplate自动装配。
方法二：运行mvn dependency:tree | grep -i mybatis，看是否真有starter依赖。如果只看到mybatis-core却没看到starter，说明你手动加了底层jar，【Spring Boot自动配置链就此断裂】。
@MapperScan没配对，或者配在了错的位置
当Mapper接口分散在多个非子包时，@MapperScan是刚需。但它必须出现在能被Spring容器识别的配置类上——最稳妥的位置是启动类本身。
在启动类上直接加：@MapperScan("com.example.mapper")。别放在某个@Configuration类里再@ComponentScan它，那属于嵌套扫描，Spring Boot不认。
如果项目用了分模块结构（如api、domain、infra），确保@MapperScan指定的路径是编译后实际存在的class路径，而不是源码里的module名。IDEA里右键target/classes，展开看mapper接口的.class文件是否真在com/example/mapper目录下。
配置属性不满足@ConditionalOnProperty条件
很多自动配置类靠配置项开关，比如DataSourceAutoConfiguration要求spring.datasource.url必须存在且非空。哪怕你写了spring.datasource.url=，后面没跟值，它也认为条件不成立。
打开application.yml，搜索spring.datasource，确认url、username、password三项都明确赋值，且url格式正确（jdbc:mysql://localhost:3306/test?useSSL=false）。
如果只是临时关闭数据源，别用注释掉url的方式，而是改用spring.datasource.enabled=false——这是部分自动配置支持的官方开关项。
手动定义了同类型Bean，挤掉了自动配置的Bean
Spring Boot默认“用户Bean优先”。你写了@Bean DataSource dataSource()，哪怕啥也没配，也会让DataSourceAutoConfiguration彻底失效，连Hikari连接池参数都进不来。
检查所有@Configuration类和启动类里的@Bean方法，搜DataSource、RedisConnectionFactory、MongoClient等关键词。如果真需要自定义，务必加上@Primary，否则容器会因类型冲突直接启动失败。
这一步操作起来很简单，直接把疑似冲突的@Bean方法暂时重命名或注释掉，再启动看是否恢复。如果恢复了，问题就锁定在这里。
