我刚开始带团队做第一个大型JavaWeb项目时数据访问层用的就是MyBatis。当时只会照着网上的demo复制粘贴SQL写在XML里接口调一下就完事了。直到接手一个被本地缓存坑到线上数据错乱的订单系统才不得不把MyBatis翻了个底朝天。今天这篇内容就是我从“会用MyBatis”到“读懂MyBatis”过程的完整复盘覆盖核心架构、一级二级缓存机制、动态SQL、Spring Boot集成、源码级执行链路和自定义拦截器每个部分都会把原理、实操、踩坑一起讲明白。适合正在做JavaWeb项目、面试前想系统梳理MyBatis知识点、或者想进阶看源码的开发者。1. 为什么JavaWeb项目至今离不开MyBatis1.1 半自动化ORM的核心价值SQL可控与灵活并存很多人问JPA/Hibernate都那么成熟了为什么还有大量JavaWeb项目死守MyBatis。我的理解是MyBatis走的是一条“半自动化”路线它不替你生成SQL只帮你把SQL参数绑定、结果集映射、连接管理这些脏活累活做了。这句话听起来简单但在实际项目里意味着两件事。第一SQL完全掌握在自己手里。系统一旦上了规模慢查询优化、分库分表、多表关联复杂查询这些都是日常操作。Hibernate的HQL和自动生成的SQL遇到极端复杂的报表查询时经常需要绕过ORM写原生SQL你反而要同时维护两套逻辑。MyBatis没有这个问题XML里写的每一行SQL你都知道它在数据库里会怎么执行甚至能直接把SQL复制到Navicat里跑一遍验证结果这种可控性对排查线上性能问题太重要了。第二学习曲线更平缓。JavaWeb项目的团队水平参差不齐招进来的新人可能刚毕业只写过JDBC。MyBatis的XML配置和mapper接口相对于Hibernate的映射关系、缓存策略、延迟加载体系来说上手快得多。团队协作时代码审查也更容易因为SQL就在XML里躺着一眼能看出有没有问题。1.2 MyBatis的三层核心结构SqlSessionFactory、SqlSession、Mapper代理MyBatis的整体架构可以拆成三个层SqlSessionFactory、SqlSession、Mapper。理解这三层各自的职责和生命周期基本就理解了MyBatis的设计哲学。SqlSessionFactory是重量级对象它负责读取MyBatis配置文件并构建整个运行环境。一个系统的生命周期里通常只需要创建一个SqlSessionFactory因为它内部持有数据源、缓存配置、映射关系等几乎全部核心组件创建成本很高反复创建浪费资源不说还会引入一堆难以排查的怪问题。SqlSession是每次会话的入口代表一次与数据库的交互过程。每执行一次数据库操作就应该开启一个新的SqlSession用完立即关闭。它内部封装了Executor执行器、事务管理等机制。需要注意SqlSession不是线程安全的绝不能让多个线程共享同一个SqlSession否则会出现数据错乱。正确做法是每个线程拿到自己的SqlSession用完就关。Mapper接口则是MyBatis最具特色的设计开发者只需要定义一个接口不需要写实现类MyBatis会在运行时通过JDK动态代理生成MapperProxy实现。当你调用接口方法时代理对象会根据方法名和返回值类型找到绑定好的SQL语句并执行。这里有个学习时的关键点为什么Mapper接口的方法名必须和XML中statement的id一致因为MyBatis的绑定机制就是通过命名空间加方法名定位SQL不一致就会报Invalid bound statement (not found)。用生活里的类比SqlSessionFactory是一家餐厅的后厨和管理制度SqlSession是接待你这桌客人的服务员Mapper接口则是菜单上的菜名。你说出菜名调用接口方法服务员SqlSession去后厨Executor下单后厨按菜单XML里的SQL做菜最后端上来的是你点的菜映射好的结果对象。2. 从零搭建MyBatis环境IDEA配置与核心配置参数2.1 基于Maven的JavaWeb项目结构规划我建议新项目直接使用Maven或Gradle管理依赖不要手动往WEB-INF/lib里扔jar包否则版本冲突会让你怀疑人生。创建一个基础的JavaWeb项目时推荐用下面的目录结构src/main/java └─ com.example.project ├─ controller ├─ service ├─ dao存放Mapper接口 ├─ entity实体类 └─ common通用工具、拦截器、配置类 src/main/resources ├─ mapper存放XML映射文件 ├─ mybatis-config.xml └─ jdbc.properties src/main/webapp └─ WEB-INF这个结构里有一个容易踩的坑很多IDEA新手发现自己在resources/mapper里放了XML文件运行时MyBatis却找不到。原因是在Maven项目中IDEA默认不会把src/main/java下的XML文件打包到classes目录但src/main/resources下的资源是正常的。如果你的Mapper XML放在java目录下又没有配置build资源的include规则编译后XML不会出现在target/classes里运行时必然报Statement找不到。另一个高频问题是使用IDEA运行Tomcat时修改代码后没有执行mvn compile导致新写的Mapper接口和XML没有同步到target。记住改完代码后先编译再重启Tomcat别偷懒用旧classes硬跑。2.2 mybatis-config.xml核心配置参数详解mybatis-config.xml是MyBatis运行时的总配置文件。初学者最容易忽略的是settings这一块这里有几个参数强烈建议配上settings !-- 日志打印实现推荐SLF4J或STDOUT -- setting namelogImpl valueSLF4J/ !-- 自动将数据库下划线列名映射为驼峰属性名 -- setting namemapUnderscoreToCamelCase valuetrue/ !-- 查询结果为null时也返回对象不包装成null -- setting namecallSettersOnNulls valuetrue/ /settingsmapUnderscoreToCamelCase是我极力推荐的一个开关。数据库字段一般叫user_name实体类属性叫userName打开这个配置后MyBatis会自动完成映射省去在resultMap里写一堆result columnuser_name propertyuserName/的麻烦。没开的话要么手动映射要么你会发现查询结果里的属性全是null却找不到原因。logImpl配置打印SQL是排查问题的利器。填STDOUT_LOGGING可以直接在控制台看到完整的Preparing、Parameters、Total语句但这种方式在生产环境慎用因为它是直接输出到控制台的。更推荐接入SLF4J或LOG4J2把日志级别调到DEBUG然后通过日志框架控制输出。environments节点里的数据源配置流量不大时可以用Druid或HikariCP。HikariCP默认自带性能很好Druid的优势是自带监控面板可以看SQL执行次数、慢查询等。对刚入门的项目用Spring Boot默认的HikariCP足够不必额外堆配置。2.3 第一个Mapper接口与XML映射文件写一个最简单的用户查询public interface UserMapper { User findById(Param(id) Long id); }对应的XMLmapper namespacecom.example.project.dao.UserMapper select idfindById resultTypecom.example.project.entity.User SELECT id, user_name, email FROM user WHERE id #{id} /select /mapper这里有个概念需要想清楚namespace必须和Mapper接口的全限定名一致select标签的id必须和接口方法名一致resultType是返回结果的类型。#{id}是预编译占位符MyBatis会把它替换成?然后通过PreparedStatement设置参数能有效防范SQL注入。#{}和${}的区别是MyBatis面试必问题。${}是字符串直接拼接比如${orderByColumn}会把变量值直接内联进SQL如果变量来自用户输入等于把数据库暴露在注入风险之下。尽量只把#{}用于参数值排序字段、表名这类需要动态拼接的标识符必须做白名单校验不能直接塞${}。3. MyBatis缓存机制从一级缓存到二级缓存彻底搞清楚缓存这块是MyBatis学习路上的分水岭也是面试里出现频率极高的考点。很多人没用过二级缓存但面试官一上来就问“MyBatis一级缓存和二级缓存的区别”腼腆一笑就暴露了基础不牢。3.1 一级缓存SqlSession级别的本地缓存一级缓存是MyBatis默认开启的作用范围是同一个SqlSession。也就是说在同一个会话里执行两次相同的查询第二次会直接从缓存中取结果不会重复访问数据库。一级缓存的实现原理非常简单——Executor内部维护了一个LocalCache本质是PerpetualCache类内部就是一个HashMapKey由Sql语句、参数、环境信息等组成Value是查询结果对象。但这里藏着两个极其容易踩的坑。第一个坑缓存只在同一个SqlSession内共享。很多新手在Service里每次调用Mapper前都新建SqlSession这导致一级缓存形同虚设因为每次查询都使用不同的会话永远无法命中缓存。SSM框架中通常由SqlSessionTemplate或Spring管理的SqlSession来代理执行默认不会跨方法共享一级缓存。第二个坑一旦在同一个SqlSession中执行了增删改操作一级缓存会被清空。MyBatis判断的依据是isFlushCache默认增删改都会flush缓存。这是为了防止缓存数据和数据库不一致。但如果你有“先查后改再查”的场景第二次查询必然重新走数据库这在业务上是符合预期的。还有一个容易被忽视的场景查询条件不同一级缓存必然不命中。一级缓存的Key里包含完整SQL语句和参数值WHERE id 1和WHERE id 2是不同的Key自然不会命中。3.2 二级缓存跨SqlSession的缓存配置不当反噬系统二级缓存是Mapper级别的缓存作用于同一个namespace下的所有SqlSession。它的存在是为了解决一级缓存只能在单会话内生效的问题。开启二级缓存需要两步第一步在mybatis-config.xml中启用全局开关settings setting namecacheEnabled valuetrue/ /settings第二步在对应的Mapper XML中添加cache evictionLRU flushInterval60000 size512 readOnlyfalse/这里每个参数都有讲究。eviction是缓存回收策略推荐用LRU最近最少使用它会把最久没被访问的缓存对象移除适合查询频率有明显分布的场景。flushInterval是缓存刷新间隔单位是毫秒表示每隔多久自动清空缓存。size是缓存最多能存储的对象数量不能设得太大否则内存压力剧增。readOnly设为true时缓存返回的是对象的相同引用性能更好但没有隔离性如果调用方修改了对象缓存中的数据也变了设为false时缓存会通过序列化返回对象的拷贝相对安全但开销更大。开启二级缓存后还要注意一个硬性条件被缓存的对象必须实现Serializable接口。因为MyBatis在readOnlyfalse模式下会对缓存对象做序列化和反序列化来保证深拷贝。如果你的实体类没有实现Serializable运行时会直接报NotSerializableException。二级缓存最大的坑在于多表关联操作。比如订单表Order和订单明细表OrderItem分开两个MapperOrderMapper的查询结果被二级缓存缓存了此时另一个请求通过OrderItemMapper修改了一条明细OrderMapper的缓存并不知道这条数据变了于是再次查询Order时返回的是修改前的旧数据产生了脏读。解决手段有两个一是把关联查询放到同一个Mapper中让它们共用同一个namespace缓存二是执行相关表的更新操作后手动调用SqlSession.clearCache()但这么做的代价是缓存失效频率高命中率下降。3.3 缓存面试高频点与源码定位面试中追问缓存时通常会引导到源码层面。一级缓存的逻辑在BaseExecutor.query()方法中核心代码如下CacheKey key createCacheKey(ms, parameter, rowBounds, boundSql); return queryFromDatabase(ms, parameter, rowBounds, resultHandler, key, boundSql);createCacheKey的构成包含MappedStatement的id、SQL语句、参数、分页参数等。二级缓存在CachingExecutor.query()中代码逻辑是先走到TransactionalCacheManager检查二级缓存是否命中未命中才转发给delegate通常是BaseExecutor执行执行完再把结果存入二级缓存。另外一个高频考点是为什么MyBatis默认一级缓存开着却不建议在Spring Boot项目里依赖它因为Spring集成后SqlSession的创建和关闭由Spring容器管理每次Mapper方法调用都可能是一个新会话一级缓存基本起不到作用。真正能提效的是合理使用二级缓存或引入外部缓存如Redis。4. 动态SQL与高级结果映射实战4.1 动态SQL五大核心标签if、where、set、foreach、trim动态SQL是MyBatis最吸引人的特性之一。没有它的时候最笨的写法是在Service层用if判断再手动拼接SQL这种代码不仅丑陋而且极易出现语法错误和SQL注入。MyBatis引入了类似JSTL的标签来动态生成SQL本质上是一个基于OGNL表达式的文本替换引擎。if是最基础的判断select idfindUserByCondition resultTypeUser SELECT * FROM user WHERE 1 1 if testname ! null and name ! AND user_name LIKE CONCAT(%, #{name}, %) /if if testemail ! null AND email #{email} /if /select注意这里的老写法WHERE 1 1目的是防止if都不成立时SQL语法错误。但更优雅的方案是直接用where标签它会自动判断是否需要输出WHERE还能自动去掉条件开头的AND或ORselect idfindUserByCondition resultTypeUser SELECT * FROM user where if testname ! null and name ! AND user_name LIKE CONCAT(%, #{name}, %) /if if testemail ! null AND email #{email} /if /where /selectset标签用于更新语句自动处理SET子句末尾的逗号update idupdateUser UPDATE user set if testname ! nulluser_name #{name},/if if testemail ! nullemail #{email},/if /set WHERE id #{id} /updateforeach最常用的场景是批量插入和IN查询。批量插入时有一条重要的经验每次插入的SQL不能太长MySQL客户端默认max_allowed_packet是4MB如果你一次性foreach几千条很容易超出限制。我一般建议每批次200到500条分批执行。批量插入的写法insert idbatchInsert INSERT INTO user (user_name, email) VALUES foreach collectionlist itemitem separator, (#{item.userName}, #{item.email}) /foreach /insertchoose标签类似于Java的switch当多个条件里只需要命中一个时使用choose when testsortType nameORDER BY user_name/when when testsortType emailORDER BY email/when otherwiseORDER BY id/otherwise /choose4.2 resultMap高级映射处理一对一、一对多的核心武器当查询结果涉及多表关联时resultType会自动映射但只能映射同名字段。一对一关系比如订单表关联用户表一对多关系比如订单表关联订单明细表这种场景必须使用resultMap来定义映射关系。一对一使用associationresultMap idOrderWithUserMap typeOrder id columnid propertyid/ result columnorder_no propertyorderNo/ result columntotal_amount propertytotalAmount/ association propertyuser javaTypeUser id columnuser_id propertyid/ result columnuser_name propertyuserName/ /association /resultMap一对多使用collectionresultMap idOrderWithItemsMap typeOrder id columnid propertyid/ result columnorder_no propertyorderNo/ collection propertyitems ofTypeOrderItem id columnitem_id propertyid/ result columnproduct_name propertyproductName/ result columnquantity propertyquantity/ /collection /resultMap这里有一个非常经典的坑使用collection时如果关联的“多”方为空默认查询结果是null对象塞进list而不是空list。也就是说你期望order.getItems().size()是0实际却可能因为某一行结果里关联字段全是null导致items里出现一个所有属性都是null的对象。解决办法是给集合字段设置collection propertyitems ... notNullColumnitem_id让MyBatis只在item_id非空时才创建对象。这是我在实际项目里排查了半天的教训。另一个建议是不要把所有关联都通过resultMap嵌套查询。复杂的嵌套会生成笛卡尔积结果数据量大时查询结果集会膨胀得非常厉害。比如一个订单对应100条明细你要查100个订单的关联明细结果集就是10000行网络传输和内存开销都会暴涨。这种情况更适合的思路是拆分为两次查询再在Service层组装或者使用嵌套select子查询但子查询也面临着名的N1性能问题。归根结底没有任何方案是银弹都要根据真实数据量和访问模式来选择。4.3 完整项目案例用户分页查询的JavaWeb分层实现分页是JavaWeb项目最常见的需求之一这里建议使用PageHelper插件。引入PageHelper后分页居然变得异常简单PageHelper.startPage(pageNum, pageSize); ListUser userList userMapper.findUserList(); PageInfoUser pageInfo new PageInfo(userList);背后的原理是PageHelper通过MyBatis拦截器在执行查询前拦截SQL拼接上LIMIT ?再查询总数量。但这里有一个隐含的坑PageHelper.startPage()只对紧随其后的第一个查询生效。如果你在调用startPage()之后、查询之前又执行了其他数据库操作比如校验数据分页就会应用到错误的SQL上。这个细节特别容易在复杂业务逻辑中出现一旦分页结果不对排查起来很费劲。Service层要注意的是Mapper层返回的是数据库实体Controller直接返回实体往往会把多余字段暴露给前端尤其是password、phone等敏感信息。正确做法是Controller层返回一个VO通过BeanUtils.copyProperties或MapStruct进行属性复制。这也符合分层设计的思路entity负责持久化VO负责对外展示不要混用。5. Spring Boot MyBatis集成实践与常见问题排查5.1 依赖引入与自动配置原理Spring Boot集成MyBatis极大简化了配置只要引入mybatis-spring-boot-starter再配置好数据源就能直接使用。推荐依赖如下dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.2/version /dependencySpring Boot的自动配置会创建SqlSessionFactory扫描Mapper注解的接口并把它们注册为Spring容器中的Bean。还有一个细节如果你的MapperXML文件没有放在默认的classpath:mapper位置需要在application.yml中显式指定mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.project.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.slf4j.Slf4jImplmapper-locations配置不匹配是SSM转Spring Boot时最常见的启动报错来源。如果你把XML文件放在src/main/resources/mapper下路径就应该写classpath:mapper/*.xml如果你放在其他自定义目录按实际情况调整。5.2 事务管理与Transactional的失效陷阱Spring Boot项目中使用MyBatis操作数据库时事务管理依赖Spring的声明式事务。在Service方法上添加Transactional即可Service public class UserServiceImpl implements UserService { Autowired private UserMapper userMapper; Override Transactional(rollbackFor Exception.class) public void createUserWithOrder(User user, Order order) { userMapper.insert(user); orderMapper.insert(order); } }为什么我看到很多教程里都强调rollbackFor Exception.class因为Spring默认只在遇到RuntimeException和Error时才回滚事务。如果你的业务方法抛出一个自定义的CheckException继承Exception但不继承RuntimeException不写rollbackFor的话事务仍然会提交。这个坑一旦踩上轻则脏数据重则线上事故。更隐蔽的事务失效场景还有三个第一个是Transactional加在private方法上Spring无法代理private方法事务完全不生效第二个是同类内部调用比如this.methodA()调用methodB()methodB上有事务注解但代理对象没有经过Spring容器事务同样失效第三个是事务方法长时间持有数据库连接比如在事务里做大文件下载或者远程API调用连接池会因此被拖垮。这些没有出现在官方文档的“温馨提示”里但实际生产环境经常因此翻车。5.3 高频报错与排查速查表我在带项目时整理过一份MyBatis踩坑速查表这里分享下最常遇到的几个问题报错信息原因分析解决方案Invalid bound statement (not found)Mapper接口方法未找到对应的SQL statement检查XML的namespace和id确认XML在target/classes目录查看mapper-locations路径是否覆盖TooManyResultsException方法返回单个对象但SQL查询结果有多条修改SQL增加唯一条件或把方法返回值改为ListBindingException: Parameter xx not foundMapper方法参数未加Param注解多参数时必须加Param例如findByNameAndEmail(Param(name) String name, Param(email) String email)ResultMap collection元素为null关联查询多端无匹配记录使用notNullColumn指定非空判断列中文乱码JDBC连接URL未指定编码jdbc:mysql://localhost:3306/db?useUnicodetruecharacterEncodingutf8The server time zone value is unrecognizedMySQL 8以上时区问题连接URL配置serverTimezoneAsia/Shanghai其中BindingException的细节值得多说一句。当Mapper接口方法只有一个参数时MyBatis允许直接通过#{参数名}访问但参数名被编译后可能变成arg0和源码里的名字对不上。稳妥的做法是无论一个还是多个参数都统一加Param注解从源头上回避这种问题。5.4 多商户跨境商城项目的实践思考讲到Spring Boot MyBatis的完整落地其实一个典型的java开源多商户跨境商城项目就是这类技术栈非常契合的应用场景。商城项目通常有商户端、用户端、管理后台三个子系统涉及商品、库存、订单、支付、物流、结算多个环节。MyBatis的优势在这里体现得很充分订单列表需要复杂的多表统计查询库存扣减需要精确的行级锁SQL支付回调需要幂等校验用唯一索引防重这些场景需要的都是精细控制的SQL而不是ORM的自动生成。在这种商城项目中最容易出问题的就是数据库事务和缓存的一致性。典型的就是订单创建后扣减库存这个操作必须放在同一个事务里否则可能出现扣了库存却没生成订单的灾难。而MyBatis的二级缓存在这种高并发写多读少的业务中基本不适用我更建议直接用Redis缓存商品详情页MyBatis缓存保持默认关闭让数据库层面的并发控制来保证数据准确。6. 源码级进阶从SQL执行链路到自定义插件6.1 MyBatis执行SQL的完整链路如果你已经能熟练开发业务功能那么这一步就是拉开差距的地方。理解MyBatis内部是怎么执行一条SQL的不仅面试时能侃侃而谈遇到疑难杂症时定位思路也更清晰。一条查询SQL的执行链路如下SqlSession调用Mapper方法 - MapperProxy代理层 - MapperMethod.execute() - SqlSession.selectOne()/selectList() - CachingExecutor负责二级缓存 - BaseExecutor这里包含一级缓存逻辑 - SimpleExecutor/ReuseExecutor/BatchExecutor - StatementHandler负责SQL语句预处理 - ParameterHandler负责参数绑定 - ResultSetHandler负责结果集映射核心的环节是StatementHandler它内部通过PreparedStatementHandler完成JDBC层面的prepare()和parameterize()参数绑定用的就是前面提到的ParameterHandler。ResultSetHandler在handleResultSets中把JDBC的ResultSet转换成一个或一组Java对象反射、构造器、类型转换都发生在这一层。你可以把这条链路想象成一条生产线产品订单Mapper调用进入车间SqlSession经过检验二级缓存、生产线装配Executor、设备调参StatementHandler、原料注入ParameterHandler、质检包装ResultSetHandler最后交付成品返回结果。6.2 手写MyBatis拦截器自动填充创建时间和更新时间理解执行链路之后自定义插件就是顺理成章的事。MyBatis允许通过Interceptor接口拦截四大对象Executor、StatementHandler、ParameterHandler、ResultSetHandler。最常用的是拦截Executor实现公共字段自动填充。假设数据库每个表都有create_time和update_time手动在insert和update里写这两个字段太繁琐使用拦截器可以一站搞定Intercepts({ Signature(type Executor.class, method update, args {MappedStatement.class, Object.class}) }) public class AuditInterceptor implements Interceptor { Override public Object intercept(Invocation invocation) throws Throwable { MappedStatement ms (MappedStatement) invocation.getArgs()[0]; Object parameter invocation.getArgs()[1]; if (parameter null) { return invocation.proceed(); } SqlCommandType sqlCommandType ms.getSqlCommandType(); Date now new Date(); if (sqlCommandType SqlCommandType.INSERT) { reflectField(parameter, createTime, now); reflectField(parameter, updateTime, now); } else if (sqlCommandType SqlCommandType.UPDATE) { reflectField(parameter, updateTime, now); } return invocation.proceed(); } private void reflectField(Object param, String fieldName, Object value) throws IllegalAccessException { Field[] fields param.getClass().getDeclaredFields(); for (Field field : fields) { if (field.getName().equals(fieldName)) { field.setAccessible(true); field.set(param, value); } } } }别忘了在MyBatis配置中注册拦截器plugins plugin interceptorcom.example.project.interceptor.AuditInterceptor/ /plugins或者如果你是Spring Boot直接定义成Bean返回Interceptor实现类即可。这个方案为什么比在代码里手写赋值更优因为公共字段的赋值逻辑被收拢到一处新来的同事写Mapper插入语句时不需要记得设置这两个时间字段减少遗漏发生。6.3 从源码中学习设计模式给项目架构带来的启发看MyBatis源码有一个额外收获能直观感受到场景驱动下的设计模式应用方式。SqlSessionFactoryBuilder是典型的Builder模式通过XML配置逐步构建出复杂的Factory对象。MapperProxy是JDK动态代理模式的典型案例避免了为每个接口手写实现类。BaseExecutor则是一个模板方法模式的绝佳样本把查询流程骨架固定下来把具体差异留给子类实现比如SimpleExecutor和BatchExecutor的执行策略不同。这几个模式如果只在设计模式的书里看很容易忘记但在MyBatis源码里一旦搞懂“为什么要这么设计”后面自己写公共组件时就会下意识地选择同样的结构。如果刚开始读源码不必把每个类都读一遍掌握一条主路径即可选一个简单的selectById方法从SqlSession.selectOne开始断点跟着走进Executor、StatementHandler、ParameterHandler、ResultSetHandler最后看到返回结果的过程。这条路径走通后再去看缓存和插件机制脉络会清楚很多。根据我个人带项目的实际感触MyBatis之所以在JavaWeb技术栈中常年占据重要位置不是因为它有多炫酷而是它把“灵活控制SQL”和“方便开发”这两个看似矛盾的需求平衡得非常好。初学者一开始不要太纠结缓存和源码先在Spring Boot里把增删改查做利索再把动态SQL用熟练然后回归到缓存和拦截器这些进阶话题每一步都踩实。后面一旦遇到诡异的数据问题或需要针对业务定制框架行为时今天梳理的这层底层认知就是你的排雷地图。