@SpringBootApplication必须放在含main方法的主类上，否则@EnableAutoConfiguration和@ComponentScan失效，导致Bean未加载、接口404或NPE；它不可随意挪位或拆解，是启动逻辑的核心开关。
为什么@SpringBootApplication不能随便挪位置？
它不是装饰性注解，而是启动逻辑的“开关”——只有加在主类上，@EnableAutoConfiguration才能基于类路径扫描依赖、@ComponentScan才能从该类所在包开始递归扫描组件。一旦把 @SpringBootApplication 放到非启动类里（比如配置类或工具类），自动配置失效、@Service/@Repository 不被加载，应用启动后 Bean 为空，接口 404 或 NPE 就成了常态。
- 必须放在含
main方法的类上，且该类建议命名为XXXApplication - 如果项目结构是
com.example.order，而Application类在com.example根包下，@ComponentScan默认能扫到所有子包；但若它被误放到com.example.config，则com.example.service就可能漏扫 - 不推荐用
@SpringBootApplication(scanBasePackages = "...")强行补救——这掩盖了包结构设计问题，也容易和@ComponentScan冲突
@EnableAutoConfiguration 是怎么“猜中你想要的”？
它本质是一套条件化装配机制：读取 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports（Spring Boot 2.7+ 新格式），再根据 classpath 是否存在某个类（如 TomcatServletWebServerFactory）、是否缺失某个 Bean、环境变量值等，决定是否导入某段自动配置。
- 加了
spring-boot-starter-web→ 自动配好内嵌 Tomcat + Spring MVC；但没加spring-boot-starter-data-jpa→JpaRepositoriesAutoConfiguration直接跳过，不会报错也不会创建 JPA 相关 Bean - 常见踩坑：排除配置写错类名，比如写成
DataSourceAutoConfiguration.class没问题，但写成DataSourceConfiguration.class就无效（后者不是自动配置类） - 调试时可加
--debug启动参数，控制台会输出“CONDITIONS EVALUATION REPORT”，看清哪些自动配置被匹配/跳过
@Configuration 和 @SpringBootConfiguration 有啥区别？
@SpringBootConfiguration 就是 @Configuration 的语义增强版，仅多了一层标记作用——告诉 Spring：“这个配置类是 Spring Boot 体系内的”，方便后续扩展（比如未来可能对它做特殊处理）。实际效果完全一致，@Bean 方法照样注册，@Import 照样生效。
- 你完全可以自己写一个
@Configuration类放在任意位置，只要它被扫描到，就能定义 Bean；不需要也不应该给它加@SpringBootConfiguration -
@SpringBootApplication自带的@SpringBootConfiguration只服务于其自身作为“主配置类”的角色，不传导、不继承 - 别为了“看起来更 Spring Boot”而在普通配置类上硬加
@SpringBootConfiguration——多余，还可能干扰某些第三方扫描逻辑
手动拆开 @SpringBootApplication 会出什么问题？
有人想“更可控”，于是把 @SpringBootApplication 拆成 @Configuration + @EnableAutoConfiguration + @ComponentScan 三个独立注解写在主类上。语法上没错，但隐性风险不小。
- Spring Boot 版本升级时，
@SpringBootApplication可能新增默认属性（如excludeName、proxyBeanMethods），手动拆开会丢失这些演进能力 -
@EnableAutoConfiguration默认启用@AutoConfigurationPackage，它依赖@SpringBootConfiguration的元数据定位包路径；手动组合时若顺序或层级不对，可能导致自动配置包注册失败 - IDE（如 IntelliJ）和 Spring Boot DevTools 对
@SpringBootApplication有专门识别逻辑，拆开后热部署、配置提示等功能可能降级
真正需要定制时，优先用 @SpringBootApplication(exclude = {...}) 或 @ComponentScan(basePackages = "...") 扩展属性，而不是肢解它——封装的存在，本来就是为了省去你操心边界条件。
