Spring Boot依赖注入核心围绕@Autowired（默认byType）、Bean生命周期和注入方式选择展开：@Autowired按类型匹配，多实例需@Qualifier或@Primary；@Resource按名称优先；构造器注入推荐用于强制依赖；循环依赖仅单例+构造器时无法解决；注入失败常见于Bean未注册、扫描路径错误或Profile不匹配。
Spring Boot 依赖注入（DI）的核心其实就围绕 @Autowired、Bean 生命周期 和 注入方式的选择逻辑 展开，高效复习的关键是抓住“谁来注入”“怎么注入”“注入失败时怎么看”这三条主线。
搞懂 @Autowired 的默认行为和常见变体
@Autowired 默认按类型（byType）匹配，不是按名称（byName）。如果容器中存在多个同类型 Bean，就会报错——这是高频出错点。
- 加 @Qualifier("beanName") 指定名称，配合 @Primary 标记首选 Bean，可解歧义
- @Resource（JSR-250）默认按名称匹配，找不到再按类型；它不依赖 Spring，但 Spring 支持
- 构造器注入推荐用于强制依赖（不可 null），且天然支持 final 字段和不可变性
- 字段注入虽简洁，但不利于单元测试和对象完整性校验，官方文档已明确建议少用
厘清 Bean 的创建时机与注入顺序
Spring 容器启动时会先实例化所有单例 Bean（非懒加载），再执行依赖注入。但注入顺序受 @DependsOn、@Order 和接口实现类的注册顺序影响。
- 循环依赖仅在单例 + 构造器注入时无法解决（会直接抛 BeanCurrentlyInCreationException）
- Setter 或字段注入能借助三级缓存解决简单循环依赖，但属于设计缺陷，应主动避免
- @PostConstruct 方法在依赖注入完成后、Bean 初始化阶段执行，适合做检查或预热
快速定位注入失败的典型原因
启动报错提示 “NoSuchBeanDefinitionException” 或 “No qualifying bean of type” 时，优先排查以下几项：
- 目标类是否加了 @Component、@Service 等注解，且被组件扫描路径覆盖
- 配置类是否漏掉 @Configuration，或@Bean 方法是否用了 private 修饰（Spring 5.2+ 要求 public）
- 是否在非 Spring 管理对象（如 new 出来的类、Servlet、线程内）里直接调用 @Autowired 字段
- Profile 是否不匹配：@ConditionalOnProperty、@Profile("dev") 等导致 Bean 未注册
动手验证比死记更有效
写一个最小可运行示例，只含两个 Service 类、一个配置类和主启动类，刻意制造几种典型错误（比如删掉@Component、改private为public的@Bean、去掉@ComponentScan等），观察日志输出和异常堆栈。
- 启动时加 --debug 参数，Spring Boot 会打印自动配置报告，帮你确认哪些 Bean 实际生效了
- 用 @Autowired(required = false) 测试可选注入，理解 null 安全边界
- 在 IDE 中 Ctrl+Click 进入 @Autowired，看其源码注释，里面明确写了“by type, then by name”的策略
