一句话结论：iBATIS 是早期的 SQL 映射框架（以 iBATIS 2.x 最典型），而 MyBatis 是其后续演进与社区接力版本（以 MyBatis 3.x 为主流），两者核心理念一致：SQL 由你掌控，框架负责“参数绑定 + 结果映射 + 会话/事务管理”。🙂
1）本质差异：同一赛道，不同代际
iBATIS（2.x）：更偏“配置驱动”，XML 更重，生态与插件体系相对早期，适配旧项目多。
MyBatis（3.x）：在保持“SQL 映射”优势的同时，增强了 Mapper 接口化、注解能力、插件拦截器、类型处理、缓存与与主流容器集成的工程体验，更符合现代 Java 工程化交付。
2）对比说明表（面向选型/迁移决策）
| 维度 | iBATIS 2.x | MyBatis 3.x | 业务影响（务实解读） |
|---|---|---|---|
| 编程模型 | 以SqlMapClient为中心 | 以 SqlSession + Mapper 接口为中心 | MyBatis 更利于分层与测试，DAO 更“轻” |
| 映射文件 | SQL Map XML（标签与结构较旧） | Mapper XML（结构更清晰）+ 注解可选 | 团队协作与维护成本更低 |
| 动态 SQL | 早期动态标签 | 更成熟的动态 SQL 体系（if/choose/trim/foreach 等） | 复杂查询可读性更强 |
| 参数与结果映射 | ResultMap/parameterMap 较依赖配置习惯 | ResultMap 更体系化，类型处理更完整 | 少踩类型坑、可控性更强 |
| 插件机制 | 能力有限 | Interceptor 插件链可拦截执行过程 | 方便做审计、分页、脱敏、灰度等 |
| 缓存 | 基础缓存能力 | 一级缓存 + 可配置二级缓存（并可扩展） | 需要谨慎使用，避免脏读/一致性问题 |
| 生态集成 | 时代较早，集成方式偏“手工” | 与 Spring 等集成成熟（常见于企业项目） | 上手快、标准化落地更顺 |
3）同一个查询：两种写法的“工程气质”差异
A. iBATIS 2.x 风格（典型思路：ID 驱动调用）
<select id="User.getById" parameterClass="int" resultClass="com.demo.User"> SELECT id, username, age FROM user WHERE id = #id# </select>解释（逐段讲清楚）：
<select id="User.getById">：用字符串 ID 标识语句，调用端通常以该 ID 去执行。parameterClass="int"：声明入参类型，属于“配置式约束”。resultClass="com.demo.User"：把结果行映射为一个 JavaBean。WHERE id = #id#：#...#表示占位参数绑定（由框架替你安全绑定，避免手拼 SQL）。
B. MyBatis 3.x 风格（典型思路：Mapper 接口 + XML）
Mapper 接口：
public interface UserMapper { User selectById(int id); }解释：
UserMapper：接口就是“能力边界”，对外像服务契约。selectById(int id)：方法签名即你对调用方的“交付承诺”，更利于重构与单测。
对应 XML：
<select id="selectById" parameterType="int" resultType="com.demo.User"> SELECT id, username, age FROM user WHERE id = #{id} </select>解释：
id="selectById"：与接口方法名对齐，减少“字符串到处飞”。parameterType="int"：入参类型声明（也可省略，让框架推断）。resultType="com.demo.User"：结果类型映射（复杂场景建议用<resultMap>）。#{id}：MyBatis 参数占位（预编译绑定语义），可读性与安全性更好。
4）工作流程图（把执行链路讲透）🧠
flowchart LR A[业务层调用] --> B[DAO/Mapper 接口] B --> C[SqlSession/会话管理] C --> D[执行器 Executor] D --> E[参数绑定 ParameterHandler] E --> F[JDBC PreparedStatement] F --> G[ResultSet] G --> H[结果映射 ResultMap/TypeHandler] H --> I[返回对象/列表]5）迁移与选型建议（直说，不绕弯）
如果你维护的是老系统：优先把 SQL 与映射稳定住，再逐步迁移到 MyBatis 3.x 的 Mapper 模式；迁移的 ROI 往往体现在“可维护性、可测试性、规范化”上。
如果是新项目：直接用 MyBatis 3.x（或 MyBatis-Plus 等上层封装，但核心原理仍是 MyBatis），把 SQL 资产沉淀在 Mapper 层，形成可复用的数据访问契约。🙂
无论哪一个：把 SQL 规范、ResultMap 约定、事务边界写进团队标准，比“框架选谁”更决定长期质量。
如果你愿意把你当前项目的 iBATIS 配置片段（sql-map-config或某个select/resultMap）贴一小段，我可以按“最小改动、最大收益”的策略，给你一份具体的 MyBatis 迁移落地清单（包括目录结构、命名、映射拆分、风险点与回滚点）。
