Spring项目中@Autowired注入接口与注入实现类有什么区别？

核心结论 #

绝大多数常规业务场景下优先注入接口，仅特殊场景直接注入实现类。 #

适用场景说明 #

优先注入接口的场景（覆盖90%以上常规开发需求） #

• 完全符合你提到的声明与实现隔离的设计初衷：上层调用方只需要关心方法的输入输出契约，不需要感知具体实现逻辑。后续如果要替换实现（比如把本地实现换成远程调用实现、单元测试时替换成Mock实现），只需要调整实现类的@Service注解配置，上层注入的代码不需要做任何修改。
• 适配Spring AOP默认逻辑：Spring AOP默认使用JDK动态代理生成增强后的代理对象，JDK动态代理本身基于接口实现，注入接口不会出现类型不匹配的问题。
• 适配多实现场景：如果一个接口有多个实现类，配合@Qualifier或者@Primary注解可以灵活指定要注入的实现，完全符合面向接口编程的规范。
  示例代码：

// 接口定义
public interface UserService {
    User getById(Long id);
}

// 实现类定义
@Service
public class UserServiceImpl implements UserService {
    @Override
    public User getById(Long id) {
        // 具体业务逻辑
    }
}

// 上层调用注入
@RestController
public class UserController {
    // 直接注入接口即可
    @Autowired
    private UserService userService;
}

适合注入实现类的特殊场景 #

• 目标类没有对应接口，本身就是独立的功能实现，自然只能注入实现类本身。
• 明确该类永远不会有多个实现、不需要做AOP增强（或已经配置Spring全局使用CGLIB动态代理），且需要调用实现类中独有的、没有在接口中声明的方法时，可以直接注入实现类。

注意：该场景本质上违背了声明与实现隔离的设计原则，无特殊需求不建议使用。

二者核心差异 #

• 耦合度不同：注入接口耦合度最低，上层仅依赖抽象不依赖具体实现；注入实现类耦合度高，后续更换实现必须修改上层注入代码。
• 代理适配性不同：注入接口同时兼容JDK动态代理、CGLIB代理两种模式，不会出现类型异常；注入实现类只有在使用CGLIB代理时才不会报错，若使用默认的JDK动态代理，被增强后的对象是接口类型，无法强转成实现类类型，直接注入会抛出NoSuchBeanDefinitionException或ClassCastException。
• 扩展性不同：注入接口扩展性更强，新增同接口的实现类时上层调用代码无需调整；注入实现类扩展性差，新增实现必须同步修改上层注入代码。

内容的提问来源于stack exchange，提问作者fireball.1