MyBatis-Plus中ServiceImpl继承导致自动注入失效问题解析

问题现象

在使用MyBatis-Plus 3.5.6版本时，开发者发现当Service实现类继承ServiceImpl<M, T>基类时，类中使用@Resource或@Autowired注解注入的依赖对象会变为null，导致NullPointerException。而当移除对ServiceImpl的继承后，依赖注入则能正常工作。

问题本质

这个问题的根本原因在于Java的动态代理机制与final关键字的相互作用：

1. Spring框架在管理Bean时，会为需要代理的类创建动态代理对象
2. 当类被标记为final时，无法为其创建子类代理
3. MyBatis-Plus的ServiceImpl基类需要被Spring代理以实现事务管理等功能
4. 如果实现类中有final字段或final类，会导致代理创建失败，进而影响依赖注入

解决方案

解决此问题的方法很简单：

1. 移除final修饰符：检查Service实现类及其注入字段，确保没有使用final修饰
2. 使用接口注入：推荐通过接口而非具体实现类来声明依赖
3. 使用setter注入：替代字段注入，可以避免一些代理相关的问题

最佳实践

在使用MyBatis-Plus的Service层时，建议遵循以下实践：

1. 避免在Service实现类中使用final修饰符
2. 对于需要注入的依赖，优先使用setter方法注入而非字段注入
3. 保持Service类的简洁性，将复杂逻辑委托给其他组件
4. 定期检查Spring容器的启动日志，确保所有Bean都正确初始化

深入理解

Spring框架的依赖注入和AOP代理是密切相关的。当Spring容器初始化一个Bean时：

1. 容器首先创建原始对象实例
2. 然后检查是否需要为其创建代理（如需要事务管理、缓存、安全等）
3. 如果需要代理，则创建代理对象包装原始对象
4. 代理对象会拦截方法调用，在必要时添加横切逻辑

当遇到final元素时，这个流程会被打断，因为：

• final类不能被继承，无法创建子类代理
• final方法不能被重写，代理无法添加额外逻辑
• final字段只能被赋值一次，代理可能无法正确初始化

总结

MyBatis-Plus的ServiceImpl继承与Spring依赖注入的冲突问题，本质上是Java语言特性与框架机制交互产生的结果。通过理解动态代理的工作原理和final的限制，开发者可以更好地组织代码结构，避免这类问题的发生。记住，在Spring生态中，保持Bean的可代理性是一个重要的设计原则。