在Java后端开发的漫漫长河中，持久层框架的演进始终围绕着如何geng优雅地处理数据库交互。Ru果你曾厌倦了那些冗长、重复且容易出错的JDBC代码，那么MyBatis的出现无疑是一道光。但hen多时候，我们仅仅是使用者，对着XML或者注解敲敲打打，却hen少停下来思考：这背后的魔法究竟是如何施展的？

今天我们不妨抛开那些庞大复杂的官方文档，通过一个精简版的“mini-mybatis”项目，像剥洋葱一样，一层层揭开它的面纱。这不仅仅是一次代码阅读，geng是一场关于设计哲学的探讨。我们将从Zui原始的JDBC出发，一步步构建起属于自己的迷你框架，kankan它是如何实现“接口即SQL”的神奇体验。

一、 回归本源：从JDBC的繁琐说起

在一切变得复杂之前，Java访问数据库的方式非常直接，但也非常“硬核”。回想一下Ru果你不使用任何框架，查询一个用户对象大概要写多少行代码？

String sql = "select id, email, name, age from users where id = ?";
try ;
     PreparedStatement ps = connection.prepareStatement) {
    ps.setLong;
    try ) {
        if ) {
            return null;
        }
        User user = new User;
        user.setId);
        user.setEmail);
        user.setName);
        user.setAge);
        return user;
    }
} catch  {
    // 异常处理...
}

这段代码虽然逻辑清晰，但充满了“噪音”。获取连接、预编译语句、设置参数、遍历结果集、手动映射字段……每一个查询dou要重复这一套流程。Ru果项目里有几十个表，这些样板代码足以让任何一个开发者发疯。于是DAO模式应运而生。

DAO模式的解耦与局限

DAO模式的核心思想非常朴素：业务层不应该直接写JDBC代码。业务层只依赖一个数据访问接口，而具体的数据库访问细节则被封装在DAO实现类里。

public interface UserDao {
    User findById;
}
public class JdbcUserDao implements UserDao {
    private final DataSource dataSource;
    public User findById {
        // 上面那一大堆JDBC代码就塞在这里
    }
}

这样Zuo确实带来了好处，业务逻辑和数据库细节解耦了。但是它并没有消除重复劳动。每个DAO实现类里依然充斥着`getConnection`、`prepareStatement`、`executeQuery`这些机械的步骤。我们开始忍不住想：Neng不Neng只写DAO接口和SQL，彻底不写实现类？

这正是MyBatis要解决的核心问题。它站在JDBC和DAO模式的肩膀上，把那些重复、机械、容易出错的代码全部框架化了。

二、 核心构想：接口如何变成SQL执行？

在MyBatis的世界里我们不再手写`JdbcUserDao`。我们只需要定义一个接口，配上SQL，框架就会自动帮我们补上那个“缺失的实现类”。

这听起来hen玄学，但Ru果把概念拆解一下其实逻辑非常顺畅：

Mapper 接口 = 传统的 DAO 接口

MapperProxy = 运行期动态生成的 DAO 实现类替代品

MappedStatement = DAO 方法背后对应的 SQL 元数据

Executor = 被框架抽出来的通用 JDBC 模板流程

所以MyBatis 的 Mapper 接口，本质上就是 DAO 接口的一种高级演进。开发者保留了对 SQL 的控制权，而框架则接管了繁琐的 JDBC 模板代码。

动态代理：无中生有的艺术

既然接口不Neng直接实例化，那我们平时注入进来的到底是什么？答案是：JDK 动态代理。

在 `mini-mybatis` 的实现中，当我们调用 `sqlSession.getMapper` 时框架内部其实是在Zuo这样一件事：

Object proxy = Proxy.newProxyInstance(
    mapperType.getClassLoader,
    new Class{mapperType},
    new MapperProxy<>
);

这个 `MapperProxy` 就是关键。它是一个 InvocationHandler，当你调用 `mapper.findById` 时方法并没有真正执行，而是被 `MapperProxy` 拦截了。它就像一个中介，负责把这次 Java 方法的调用，翻译成一次数据库操作。

三、 迷你框架的内部构造：MappedStatement 与 Configuration

代理对象拦截到方法调用后怎么知道该执行哪条 SQL 呢？这就需要“元数据”了。

MyBatis 不会在每次执行时dou去解析 XML 或注解，那样效率太低。它会在启动阶段，就把所有的 SQL 解析成统一的元信息，存放在一个叫 `Configuration` 的对象里。而在 `mini-mybatis` 中，这个元信息被封装在 `MappedStatement` 类中。

public final class MappedStatement {
    private final String id;              // 例如：com.example.UserMapper.findById
    private final SqlCommandType commandType; // SELECT, INSERT, UPDATE 等
    private final String sql;            // 解析后的 SQL
    private final Class resultType;   // 返回值类型
}

你Ke以把 `Configuration` 理解为一个巨大的 Map，Key 是 `statementId`，Value 就是 `MappedStatement`。

当 `MapperProxy` 拦截到 `findById` 方法时它会先拼出 `statementId`，然后去 `Configuration` 里找到对应的 `MappedStatement`。这就是 Mapper 方法和 SQL 之间的桥梁。

SQL 解析与参数绑定

我们在 XML 里写的 SQL 通常长这样：

select id, name from users where id = #{id}

但 JDBC 不认识 `#{id}`，它只认问号 `?`。这就需要一个 `SqlSourceParser`。在 `mini-mybatis` 里它的职责就是把带有 `#{}` 的 SQL 解析成 JDBC Neng执行的 `BoundSql`。

解析后的结果大概包含两部分信息：

sql = select id, name from users where id = ?
parameterPaths = 

同时方法参数的解析也是个技术活。比如你定义了：

User findByEmailAndAge String email, @Param int age);

框架需要通过 `ParamNameResolver` 把这两个参数转换成一个 Map，以便后续通过 `PropertyAccessor` 按路径读取参数值，Zui终调用 `preparedStatement.setObject` 完成绑定。

四、 执行引擎：Executor 的职责

万事俱备，只欠执行。真正干脏活累活的，是 `Executor`。

在 `mini-mybatis` 中，`SimpleExecutor` 承担了这一角色。它的逻辑非常直观，就是标准的 JDBC 流程：

从 `DataSource` 获取数据库连接。

根据解析后的 SQL 创建 `PreparedStatement`。

根据参数路径，从参数对象中取出值并填入 SQL。

执行 `executeQuery` 或 `executeUpdate`。

Ru果是查询，遍历 `ResultSet`，通过反射将列值映射到 JavaBean 字段中。

关闭资源，返回结果。

当然真实的 MyBatis 中，Executor 还要处理一级缓存、二级缓存、批处理、插件拦截等复杂逻辑。但在我们的迷你版里为了kan清主干，我们刻意省略了这些高级特性，只保留Zui纯粹的 JDBC 调用链路。

五、 与 Spring 的共舞：mini-mybatis-spring

理解了 MyBatis 核心是如何工作的，下一个大问题就是：它是如何融入 Spring 生态的？毕竟我们现在hen少手动去 `new SqlSessionFactory`，geng多的是在 Spring 容器中享受自动装配的便利。

这就引出了 `mini-mybatis-spring` 模块。它的核心目标Ke以概括为三点：

把 MyBatis 的核心对象接入 Spring 容器。

把 Mapper 代理注册成 Spring Bean。

把 SqlSession 的生命周期托管起来。

SqlSessionFactoryBean：工厂的工厂

Spring 喜欢管理 Bean，但 MyBatis 的 `SqlSessionFactory` 构建过程比较特殊。为了适配，MyBatis-Spring 提供了 `SqlSessionFactoryBean`。

它实现了 Spring 的 `FactoryBean` 接口。这意味着，Spring 容器里虽然注册的是这个 FactoryBean，但当你注入 `SqlSessionFactory` 时拿到的是它 `getObject` 方法返回的真实对象。它就像一个适配器，把 MyBatis 的构建逻辑优雅地包裹在 Spring 的 Bean 生命周期里。

@Bean
SqlSessionFactoryBean sqlSessionFactory {
    SqlSessionFactoryBean factoryBean = new SqlSessionFactoryBean;
    factoryBean.setDataSource;
    factoryBean.setMapperInterfaces;
    // 设置其他属性...
    return factoryBean;
}

MapperFactoryBean：让接口变身 Bean

Spring Ke以创建普通类的实例，但怎么创建接口的实例并注入到 `UserService` 里呢？

@Service
class UserService {
    private final UserMapper userMapper;
    // 这里注入的到底是什么？
    UserService {
        this.userMapper = userMapper;
    }
}

秘密在于 `MapperFactoryBean`。针对每一个 Mapper 接口，Spring 容器中dou会注册一个对应的 `MapperFactoryBean`。这个 FactoryBean 的 `getObject` 方法，内部调用的就是 `sqlSession.getMapper`，也就是那个动态代理对象。

所以当你注入 `UserMapper` 时Spring 实际上是把 `MapperFactoryBean` 生成的代理对象给了你。这层封装极其精妙，让业务代码完全感知不到底层框架的存在。

MapperScan：批量扫描的魔法

Ru果项目里有几十个 Mapper，难道我们要手写几十个 `@Bean` 方法来定义 `MapperFactoryBean` 吗？当然不。

这时候 `@MapperScan` 注解就派上用场了。它利用了 Spring 的 `ImportBeanDefinitionRegistrar` 点。在容器启动的早期，Spring 会回调这个注册器，然后启动一个类路径扫描器，去指定的包下寻找所有接口。

每扫描到一个接口，它就会动态地为这个接口注册一个 `MapperFactoryBean` 的 `BeanDefinition`。这样一来原本繁琐的手动注册过程，变成了一个自动化的批处理任务。

SqlSessionTemplate：线程安全的门面

原生的 `SqlSession` 是非线程安全的，通常要求每次请求创建一个新的，用完即关。但在 Spring 的单例 Bean 环境里直接持有 `SqlSession` 显然不合适。

于是`mybatis-spring` 提供了 `SqlSessionTemplate`。它本身是 Spring 单例，内部却持有 `SqlSessionFactory`。每次你调用 Mapper 方法时`SqlSessionTemplate` dou会自动获取一个新的 `SqlSession`，执行完操作后再自动关闭。此外它还完美集成了 Spring 的事务管理，确保同一个事务内复用同一个 SqlSession，事务结束后统一提交。

六、 一次调用的完整旅程

让我们把视角拉高，俯瞰一次完整的调用链路。当你在业务代码里写下 `userMapper.findById` 时背后发生了一场精密的接力赛：

Spring 容器启动阶段：

读取 @Configuration 
  -> 创建 DataSource 
  -> 创建 SqlSessionFactoryBean  
  -> 创建 SqlSessionTemplate 
  -> @MapperScan 扫描 Mapper 接口 
    -> 注册 MapperFactoryBean 
      -> 暴露 Mapper 代理 Bean

业务运行阶段：

UserService 调用 userMapper.findById
  -> 触发 MapperProxy.invoke
    -> 拼装 statementId 
    -> 从 Configuration 获取 MappedStatement
    -> ParamNameResolver 解析参数
    -> 委托给 SqlSessionTemplate
      -> SqlSessionTemplate 获取 Session
        -> Executor.query
          -> SqlSourceParser 解析 SQL 
          -> PreparedStatement 绑定参数
            -> JDBC 执行查询
              -> ResultSet 映射成 User 对象
                -> 返回给业务层

这就是 MyBatis “接口调用即 SQL 执行”的完整真相。它不是魔法，而是一层层精心设计的抽象和代理。

七、 迷你版的取舍：我们省略了什么？

为了保持代码的清晰度，这个 `mini-mybatis` 项目刻意Zuo了一些减法。毕竟学习框架原理时先抓主干比纠结于细节geng重要。

我们省略了：

动态 SQL那些复杂的 ``, `` 标签处理逻辑。

缓存机制一级缓存和二级缓存的处理。

插件系统允许用户拦截方法调用的插件链。

复杂事务同步虽然提到了事务，但省略了 Spring 事务管理器与 MyBatis 之间细致的同步逻辑。

结果集的高级映射比如嵌套结果集、关联查询等复杂的 `ResultMap` 功Neng。

这些省略并不代表它们不重要，而是因为它们会掩盖核心的数据流转逻辑。当你理解了Zui基础的 `JDBC -> DAO -> Proxy -> Executor` 这条主线后再去研究那些高级特性，就会觉得豁然开朗。

通过构建这个 `mini-mybatis`，我们不难发现，优秀的框架往往不是在发明全新的技术，而是在Zuo“减法”和“封装”。它把开发者从繁琐的 JDBC 细节中解放出来只留下业务逻辑和 SQL 语句这两个Zui核心的关注点。

理解源码，Zui好的方式莫过于亲手造一个轮子。哪怕这个轮子hen简陋，哪怕它跑不快，但在这个过程中，你对每一个螺丝钉的位置、每一根连杆的作用dou会有深刻的体感。希望这次源码层面的拆解，Neng让你下次使用 MyBatis 时心里多一份从容和笃定。

---