为什么 Mapper 接口不需要实现类？
如果你用过 Java 的 MyBatis 框架，可能会有一个疑问：在定义 Mapper 接口时，我们只需要写一个接口，而不需要提供实现类，MyBatis 就能神奇地帮我们执行数据库操作。这是怎么回事？难道接口不需要实现类也能运行吗？今天我们就从朴素的思路开始，一步步逼近答案，最终弄清楚这背后的原理。
朴素的第一步：接口不就是要实现吗？
在 Java 中，我们学到的基本概念是：接口（interface）只是定义了一组方法签名，没有具体实现。如果要使用它，必须通过实现类（implementing class）来提供方法的具体逻辑。比如：
public interface UserService {
void saveUser(String name);
}
public class UserServiceImpl implements UserService {
@Override
public void saveUser(String name) {
System.out.println("Saving user: " + name);
}
}
调用时，我们通过 UserServiceImpl 的实例来执行 saveUser 方法。这种方式直观、符合面向对象编程的基本逻辑。那么，为什么在 MyBatis 中，我们定义一个 Mapper 接口，比如：
public interface UserMapper {
@Select("SELECT * FROM users WHERE id = #{id}")
User getUserById(int id);
}
却不需要写 UserMapperImpl 这样的实现类？直接通过 SqlSession.getMapper(UserMapper.class) 就能拿到一个“能用”的对象？这看起来像是违反了 Java 的基本规则。让我们从这个朴素的疑问出发，逐步探索。
初步猜想：MyBatis 帮我们生成了实现类？
既然接口本身不能直接实例化，那么一个合理的猜想是：MyBatis 在背后偷偷帮我们生成了实现类。我们知道 Java 提供了动态代理（Dynamic Proxy）机制，可以在运行时生成接口的实现类。或许 MyBatis 用类似的方式，在程序运行时为 UserMapper 创建了一个代理对象？
这个想法有点道理。动态代理在 Java 中通过 java.lang.reflect.Proxy 类实现，可以为接口生成一个代理对象，拦截方法调用并执行自定义逻辑。比如：
UserService proxy = (UserService) Proxy.newProxyInstance(
UserService.class.getClassLoader(),
new Class<?>[]{UserService.class},
(proxyObj, method, args) -> {
System.out.println("Proxy saving user: " + args[0]);
return null;
}
);
proxy.saveUser("Alice");
运行后，代理对象会拦截 saveUser 的调用并执行我们定义的逻辑。MyBatis 的 Mapper 接口可能也是用了类似的技术？但这只是猜想，我们需要更具体的证据。
走进 MyBatis：动态代理的初步验证
让我们看看 MyBatis 的实际用法。当我们调用 SqlSession.getMapper(UserMapper.class) 时，MyBatis 返回一个对象，这个对象可以直接调用 getUserById 方法并执行 SQL 查询。这提示我们，MyBatis 确实在运行时为接口生成了一个“实现”。通过阅读 MyBatis 的文档和源码，可以确认：MyBatis 使用了 JDK 动态代理。
在 MyBatis 中，核心类 MapperProxy 负责实现动态代理。当你调用 getMapper 时，MyBatis 会：
- 检查
UserMapper是否是一个接口。 - 通过
Proxy.newProxyInstance创建一个代理对象。 - 将代理对象的调用转发给内部的逻辑处理。
但这只是表层答案。代理对象如何知道要执行哪条 SQL？如何将方法参数映射到 SQL 中的占位符？这需要我们再深入一步。
复杂的核心：Mapper 的注解与映射机制
现在我们逼近了问题的核心。Mapper 接口不需要实现类，因为 MyBatis 通过反射和映射配置在运行时动态生成了实现逻辑。具体来说：
-
注解解析
在UserMapper中，我们用@Select注解定义了 SQL 语句。MyBatis 在初始化时会扫描这些接口，通过反射读取方法上的注解，提取 SQL 和参数信息。比如：@Select("SELECT * FROM users WHERE id = #{id}") User getUserById(int id);MyBatis 解析后知道：调用
getUserById时，要执行这条 SQL，并将参数id绑定到#{id}。 -
XML 配置（可选）
如果不用注解，也可以通过 XML 文件定义 SQL，比如：<mapper namespace="com.example.UserMapper"> <select id="getUserById" resultType="com.example.User"> SELECT * FROM users WHERE id = #{id} </select> </mapper>MyBatis 会根据接口的全限定名和方法名，找到对应的 SQL。
-
动态代理的执行
当你调用userMapper.getUserById(1)时：- 代理对象拦截调用。
- 根据方法名和接口名，找到对应的 SQL（来自注解或 XML）。
- 通过反射获取方法参数（比如
1），绑定到 SQL。 - 执行查询，返回结果。
这意味着，Mapper 接口的“实现”不是传统的手写代码，而是由 MyBatis 在运行时通过代理和反射动态生成的。
最终方案：为什么不需要实现类？
到这一步，我们可以总结出完整的答案：Mapper 接口不需要实现类，因为 MyBatis 利用了 JDK 动态代理和反射机制，在运行时为接口生成了代理对象，并通过注解或 XML 配置提供了方法的具体执行逻辑。这种设计有几个关键优势：
- 简洁性：开发者只需关注接口定义和 SQL，无需编写繁琐的实现代码。
- 灵活性：通过注解或 XML，可以随时调整 SQL 逻辑，而无需修改 Java 代码。
- 解耦性：接口与底层数据库操作分离，符合面向接口编程的原则。
从朴素的“接口必须有实现类”到复杂的“动态代理 + 反射 + 配置”，我们逐步揭示了 MyBatis 的巧妙设计。这种方式不仅解决了问题，还提供了一种优雅的开发体验。
结语
从最初的疑问出发，我们通过猜想、验证和深入分析，最终明白了为什么 Mapper 接口不需要实现类。这背后是 Java 动态代理的强大能力，以及 MyBatis 对注解和配置的巧妙利用。下次使用 MyBatis 时，你可以更有信心地说：接口虽无实现，但运行时自有乾坤！
