依赖注入失效的根因通常藏在UnsatisfiedDependencyException后的Caused by链中，需依次排查Bean未被管理、依赖匹配不明确、生命周期/上下文隔离及循环依赖四类场景。
看到依赖注入失效，别急着改代码。Spring Boot 启动时抛出的 UnsatisfiedDependencyException 本质是个“信封”，真正的问题藏在它后面的 Caused by 链里——比如 NoSuchBeanDefinitionException、BeanCurrentlyInCreationException 或 NullPointerException。顺着这个链往下看，基本就能锁定根因。
先确认 Bean 是否被 Spring 管理
这是最常见也最容易忽略的一环。注入失败，往往是因为目标类压根没进容器。
- 检查类上有没有加
@Component、@Service、@Repository或@Controller这类注解；如果是配置类，确认用了@Configuration和@Bean - 核对组件扫描范围：Spring Boot 默认只扫描主启动类所在包及其子包；如果目标类在外部包，必须显式配置
@ComponentScan(basePackages = "xxx") - 运行时验证：在任意 Bean 中注入
ApplicationContext，调用getBeanDefinitionNames()打印所有已注册 Bean 名称，看看你要的类型是否在列表里
查清依赖匹配是否明确
Spring 能找到 Bean，但不确定该选哪一个，也会报注入失败。
sc-java-to-ts-interface
下载
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
- 接口有多个实现类时（如
PaymentService有两个实现），必须用@Qualifier("beanName")或@Primary明确指定 - 注意类型匹配细节：构造器注入要求参数类型严格一致；字段注入支持泛型擦除后的宽匹配，但容易掩盖歧义
- 检查代理类型是否对得上：比如你注入的是接口，但某个实现类被
@Scope("prototype")或 AOP 增强后生成了 CGLIB 代理，而另一处又按具体类注入，就会不匹配
留意生命周期与上下文隔离问题
有些对象不是由 Spring 创建的，自然无法享受依赖注入。
-
ConstraintValidator就是典型：Hibernate Validator 自己 new 出来的实例，绕过 Spring 容器；解决办法是配置SpringConstraintValidatorFactory - 手动
new的对象、线程池中创建的 Runnable、或通过反射调用的类，都不会被自动注入 - Web 层的
@ControllerAdvice或过滤器若未加@Component，也可能不在 Web 上下文中生效
警惕循环依赖和作用域冲突
这类问题通常伴随更具体的异常提示，比如 BeanCurrentlyInCreationException。
- 两个 Bean 构造器互相引用，Spring 默认不支持（除非开启
spring.main.allow-circular-references=true） - 单例 Bean 注入原型 Bean 是允许的，但每次取到的都是新实例；反过来，原型 Bean 注入单例 Bean 会导致单例被多次初始化，可能引发状态混乱
- 使用
@Lazy可以打破构造器级循环，但要清楚它只是延迟加载，并不消除依赖关系本身
不复杂但容易忽略：90% 的注入失败，其实就卡在这四类场景里。先看堆栈末尾的 Caused by，再对照这几点快速过一遍，比反复重启试错快得多。
