为什么在业务层接口和实现类都可以注入，而大部分人选择接口而不选择实现类思考？

在进行业务层代码编写时候，需要调用别的service的方法，我选择了serviceImpl注入，但是看到代码风格，决定换成service。就诞生了以下这个问题：
为什么选择接口而不选择实现类？

疑惑：

• 一部分人说是为了解耦。
  Autowired 注解是通过service类型进行注入。
  Resource 注解时通过service名称进行注入。
  当接口有多个实现的时候，我注入的时候选择了serviceImpl1
  Autowired ServiceImpl serviceImpl1; 通过Qualifier去指定serviceImpl1实现类。
  使用Resource 直接注入serviceImpl1实现类。
  发生改变需要修改。
  当接口只有一个实现的时候 ，使用Autowired或者Resource注入实现类或者接口，当发生改变的时候，同样发生改变需要修改。

我认为这里说的解耦和注入哪个是没有关系的。
因为这两个注解的作用就是为了解耦，和怎么注入 注入什么没有关系。使用注解是将注入的对象交给容器去管理(依赖注入)，省去了我们new的过程。
因为当你选择注入service的时候，存在接口实现类，所以采用了JDK的代理方式，实际上你注入的依然是实现类。
而你选择注入serviceImpl的时候 这不是一个接口，所以采用cglib的方式进行代理，注入的是serviceImpl。
那么问题来了，既然注入的都一样，我是不是选择哪个都可以。

• 还有人认为是为了事务。
  选择注入service，因为代理的原因，注入的其实是serviceImpl，但是容器中service已经被管理，那么当有事务发生的时候，AOP事务生效。
  而使用serviceImpl的时候，同样也会被容器管理吗？事务会生效吗？

本人脑子已经木了，欢迎各路神通踊跃发言，求各路神仙救救孩子吧！！！

大佬回答：

首先说明，注入的对象确实为实现类的对象。（并不是实现类的代理对象，注入并不涉及代理）
如果只是单纯注入是可以用实现类接收注入对象的，但是往往开发中会对实现类做增强，如事务，日志等，实现增强的AOP技术是通过动态代理实现的，而spring默认是JDK动态代理，对实现类对象做增强得到的增强类与实现类是兄弟关系，所以不能用实现类接收增强类对象，只能用接口接收。如使用动态代理的话你尝试就会报错，不过应该不会需要这么做，使用接口本来就是解耦的，你直接用实现类接收注入对象岂不是失去了注入的意义。（为什么不直接new一个呢？）