依赖注入失效的根因通常藏在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，但不确定该选哪一个，也会报注入失败。

• 接口有多个实现类时（如 PaymentService 有两个实现），必须用 @Qualifier("beanName") 或 @Primary 明确指定
• 注意类型匹配细节：构造器注入要求参数类型严格一致；字段注入支持泛型擦除后的宽匹配，但容易掩盖歧义
• 检查代理类型是否对得上：比如你注入的是接口，但某个实现类被 @Scope("prototype") 或 AOP 增强后生成了 CGLIB 代理，而另一处又按具体类注入，就会不匹配

留意生命周期与上下文隔离问题

有些对象不是由 Spring 创建的，自然无法享受依赖注入。

sc-java-to-ts-interface

将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。

下载

• 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，再对照这几点快速过一遍，比反复重启试错快得多。