mybatis一级缓存默认生效且与spring事务天然耦合：事务内复用同一sqlsession，使相同查询命中缓存；事务结束或执行增删改操作时缓存自动清空；修改缓存中对象引用会导致“脏读”现象。
MyBatis 一级缓存默认生效，且与 Spring 声明式事务天然耦合——不是“配合”，而是“自动对齐”。关键在于：Spring 的事务管理器在开启事务时，会复用同一个 SqlSession（由 SqlSessionTemplate 或 SqlSessionUtils 统一管理），而一级缓存正依附于该 SqlSession 的生命周期存在。
一级缓存的载体是 SqlSession，而 Spring 事务控制了 SqlSession 的复用
在 Spring + MyBatis 整合中：
- Spring 声明式事务（@Transactional）会在方法入口创建或获取一个 SqlSession，并绑定到当前线程（通过 ThreadLocal）；
- 整个事务方法执行期间，所有 Mapper 调用都共享这同一个 SqlSession；
- 因此，同一事务内两次 完全相同 的查询（相同 SQL、相同参数、相同 Statement 类型），第二次会命中该 SqlSession 内置的 LocalCache，不发 SQL；
- 一旦事务提交（commit）或回滚（rollback），SqlSession 通常被关闭或清空，一级缓存随之失效。
为什么修改实体后再次查询会返回“脏对象”？
这不是缓存“错”，而是对象引用导致的语义混淆：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 第一次
selectById(1)返回的 User 对象，是 MyBatis 创建并存入一级缓存的原始 Java 对象； - 你在 Service 层直接修改了这个对象的字段（如
user.setName("new")），由于一级缓存中存的是对象引用，缓存里的对象也被同步修改； - 第二次
selectById(1)仍命中缓存，返回的仍是那个已被修改过的对象实例（user1 == user2为 true）； - 此时你看到的“不是数据库最新值”，本质是读到了内存中被污染的缓存对象，而非数据库未更新。
什么操作会清空一级缓存？
MyBatis 在以下任意操作发生时，会主动清空当前 SqlSession 的 LocalCache，以避免陈旧数据干扰：
- 执行任意 INSERT / UPDATE / DELETE 语句（无论是否影响当前查询的数据）；
- 显式调用
sqlSession.clearCache()； - 调用
sqlSession.commit()或sqlSession.rollback()（事务结束时 Spring 会自动触发）； - SqlSession 关闭（如非事务环境下的每次请求新建 Session）。
如何验证或调试一级缓存行为？
可在日志中观察关键信号：
- 启用 MyBatis 日志（如 logback 中设置
logger name="org.apache.ibatis" level="DEBUG"）； - 事务内首次查询：日志出现
==> Preparing:和； - 事务内第二次相同查询：无 SQL 日志，仅输出结果对象（说明走缓存）；
- 若中间执行了 update，之后再查：又会出现
==> Preparing:，表明缓存已清空。
一级缓存本身不可关闭，但可通过设计规避副作用：避免在事务中直接修改查询返回的实体；必要时用 selectById(id) 后立即 BeanUtils.copyProperties 脱离引用；或在关键查询前手动 clearCache()。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
