当前位置：首页 > ds >正文

手写MyBatis第44弹：解密MyBatis四大核心组件拦截之道

ds 2025/9/1 11:53:16

🥂(❁´◡`❁)您的点赞👍➕评论📝➕收藏⭐是作者创作的最大动力🤞

💖📕🎉🔥 支持我：点赞👍+收藏⭐️+留言📝欢迎留言讨论

🔥🔥🔥（源码 + 调试运行 + 问题答疑）

🔥🔥🔥 有兴趣可以联系我。

我们常常在当下感到时间慢，觉得未来遥远，但一旦回头看，时间已经悄然流逝。对于未来，尽管如此，也应该保持一种从容的态度，相信未来仍有许多可能性等待着我们。

博客正文

一、MyBatis插件的目标与价值

二、插件的作用点：为何是这四大组件？

三、插件的核心机制：动态代理与责任链

四、深层思考与最佳实践

总结

Mermaid图：MyBatis插件责任链与动态代理交互流

深入剖析MyBatis插件机制：原理、应用与手写实践
解密MyBatis四大核心组件拦截之道——插件开发终极指南
不止于日志和分页：手把手教你打造自己的MyBatis插件
MyBatis插件黑魔法：动态代理与责任链模式的艺术
从源码视角看MyBatis插件：为何只能拦截那4个对象？

在当今的企业级应用开发中，MyBatis因其高度的灵活性、直观的SQL映射以及优秀的性能，成为了持久层框架的热门选择。而MyBatis的插件（Interceptor）机制更是为其功能扩展提供了无限可能，允许开发者在SQL执行的生命周期中插入自定义逻辑。无论是通用的分页查询、性能监控、SQL日志打印，还是业务相关的数据权限控制、字段加解密，插件都能优雅地实现。本文将深入剖析MyBatis插件的核心机制、功能原理，并解答一些常见的深层问题。

一、MyBatis插件的目标与价值

MyBatis插件的核心目标在于无侵入性地增强或改变框架核心组件的行为。这种设计遵循了“开放-封闭原则”，意味着我们可以在不修改MyBatis源码的情况下，对其固有行为进行扩展和定制。

常见应用场景：
- SQL日志记录: 精准记录每条执行的SQL语句及其参数，便于调试和审计。
- 性能监控: 统计SQL的执行时间，及时发现慢查询。
- 分页查询: 自动为查询语句添加分页逻辑（如MySQL的LIMIT），简化开发。
- 数据权限过滤: 在SQL执行前自动追加WHERE条件，实现行级数据权限控制。
- 字段加解密: 在参数设置和结果集映射时，对敏感字段进行自动加解密。
- 全局唯一ID赋值: 在插入操作前，为实体类自动生成并填充唯一ID。

这些功能的实现，都依赖于插件对MyBatis核心运行流程的拦截能力。

二、插件的作用点：为何是这四大组件？

MyBatis插件并非万能，它的拦截目标被精确地定义在四大核心组件上：

Executor：执行器，是MyBatis的核心，负责整个SQL执行过程的调度。它拦截的点包括update, query, commit, rollback等方法，非常适合做全局缓存、性能监控等。
StatementHandler：语句处理器，负责与JDBC的Statement对象交互，包括创建Statement、参数化预编译SQL（parameterize）、执行SQL（query/update）等。这里是修改SQL语句、分页、设置超时时间的最佳位置。
ParameterHandler：参数处理器，负责将用户传入的参数设置到JDBC的PreparedStatement中。拦截它可以实现参数的自定义处理，如加密、类型转换等。
ResultSetHandler：结果集处理器，负责将JDBC返回的ResultSet映射成Java对象。拦截它可以实现结果集的解密、自定义映射、延迟加载增强等。

那么，为什么MyBatis只允许拦截这4个组件呢？

这并非技术上的限制，而是MyBatis架构设计上的一种有意的约束和规范。MyBatis的SQL执行流程被精心地分解为了几个职责分明的阶段，每个阶段都由一个特定的组件负责。这4个组件串联起了从参数处理到结果集映射的完整链条，是流程中最关键、最稳定的抽象层。

允许拦截任意内部组件会使框架变得脆弱和不稳定。内部组件的接口和实现可能因版本迭代而发生变化，而插件的大量使用会使得框架的演进变得异常困难。将拦截点固定在这4个稳定接口上，既为扩展提供了足够的灵活性，又保证了框架核心的封装性和演进能力。这是一种权衡后的设计决策。

三、插件的核心机制：动态代理与责任链

理解插件机制，关键在于掌握两个核心设计模式：动态代理和责任链模式。

1. 动态代理（Dynamic Proxy）

这是实现拦截的技术手段。MyBatis并不是直接将这些组件实例传递给插件，而是通过Plugin类（实现了InvocationHandler接口）为这些目标组件创建代理对象。

当你在interceptor方法中通过Interceptor.pluginAll(target)来包装目标对象时，MyBatis会遍历所有已配置的插件，并调用其plugin方法。通常，我们会使用MyBatis提供的Plugin.wrap(target, this)方法来创建代理。这个方法会判断当前插件声明的注解（@Intercepts）要拦截的接口和方法是否与目标对象匹配。如果匹配，就为其创建一个JDK动态代理对象。

此后，任何对目标对象方法的调用，都会先被代理对象截获，转而执行代理的invoke方法，从而有机会插入插件的逻辑。

2. 责任链模式（Chain of Responsibility）

这是组织多个插件的设计模式。一个目标组件可能会被多个插件所拦截。MyBatis通过责任链模式将它们串联起来。

假设我们配置了插件A、B、C。MyBatis初始化时，会按配置顺序为原始组件（Original）层层包裹上代理：

最终组件 = Plugin(C).wrap( Plugin(B).wrap( Plugin(A).wrap(Original) ) )

最终的代理对象结构如下图所示（请见后面的Mermaid图）。当调用方法时，请求的传递流程是： 调用者 -> 代理C -> 插件C.intercept() -> 代理B -> 插件B.intercept() -> 代理A -> 插件A.intercept() -> 原始对象.originalMethod()

每个插件的intercept方法中，都需要调用Invocation.proceed()来将调用传递到链中的下一个节点，直到最终触发原始对象的方法。

四、深层思考与最佳实践

1. 插件执行顺序如何控制？

插件的执行顺序完全由其在MyBatis配置文件（mybatis-config.xml）中的配置顺序决定。先配置的插件，会被包裹在责任链的最外层；后配置的插件，则在最内层。这意味着，后配置的插件会先被执行，但其proceed()调用会触发外层插件的逻辑。

例如，配置顺序为A、B、C，则执行顺序是：C.intercept -> B.intercept -> A.intercept -> Original.method -> A收尾 -> B收尾 -> C收尾。这非常类似于一个嵌套的洋葱结构。

2. 如何防止插件无限循环代理？

这是一个非常关键的问题。假设在插件A的intercept方法中，又去调用了Method.invoke(target, args)，而这个target是代理对象本身，就会形成递归调用，导致栈溢出。

MyBatis通过责任链的传递机制和Invocation类来避免这一点。在插件中，我们应该永远只调用invocation.proceed()，而不是直接调用method.invoke(target, args)。

Invocation对象封装了当前的调用信息。它的proceed()方法会智能地将调用传递给责任链中的下一个节点（即内层的代理或最终的原始对象），而不是简单地反射调用最初传入的target。这样就保证了调用链能正确地一步步向内核推进，而不会发生循环。

总结

MyBatis的插件机制是其框架扩展性的基石。它通过将拦截点限定在4大核心组件上，在灵活性和稳定性之间取得了平衡。其底层依托于动态代理技术实现方法拦截，并通过责任链模式优雅地组织多个插件。理解这一机制，不仅能让我们更好地使用第三方插件，更能 empower 我们开发出强大、符合自身业务需求的定制化功能，真正发挥出MyBatis的全部潜力。