数据库回滚之后，缓存是否也回到了原来的状态，要看具体缓存操作是否参加了事务同步。本节在事务与事件边界实验之后，检查事务感知缓存能延后哪些操作、哪些操作仍会立即生效。
资料基于 Spring Framework 7.0.10。原始核查：2026 年 10 月 24 日；发布整理复核：2026 年 10 月 30 日 JST。以下练习尚未运行；既有 6.2.11 项目仍需按实际配置验收。
延后执行的是指定缓存操作
TransactionAwareCacheDecorator 将 put、evict、clear 与 Spring 事务同步关联，在成功提交后的阶段调用底层缓存。没有对应事务同步时，这些操作立即执行。putIfAbsent、evictIfPresent 等即时操作不能按同样方式延后，不能期待数据库回滚会撤销它们。装饰器契约
固定版本装饰器源码使用 TransactionSynchronizationManager.isSynchronizationActive() 判断是否登记回调。核查项目时应同时观察实际事务与同步状态，不能仅凭业务方法名或一个注解判断路径已经生效。
AbstractTransactionSupportingCacheManager 的 transactionAware 默认是 false，需要显式开启。这是该基类的默认值，不能推断任意缓存管理器或项目配置。管理器契约与固定版本实现可用于核对真正暴露的 Cache 是否已装饰。
练习一：提交、回滚与无事务三组对照
用虚构商户 1001、真实测试事务管理器和可记录调用的 Cache 委托，通过 TransactionTemplate 分别执行下面三组。每组重置底层缓存与计数，事务内和事务完成后都直接检查底层委托。
| 场景 | 事务内应观察什么 | 完成后应观察什么 |
|---|---|---|
| 装饰缓存 put 后正常提交 | 委托 put 尚未发生 | 提交后发生一次 put |
| 装饰缓存 put 后主动回滚 | 委托 put 尚未发生 | 没有这次 put |
| 无事务同步时 put | 调用当时执行委托 put | 条目已经存在 |
表中是待验收的预期，不是实跑记录。若测试框架默认回滚，必须另建显式提交路径，否则没有覆盖第一组。只检查方法返回值看不到操作真正发生的阶段。
练习二：即时操作与提交后失败
在空缓存事务中调用 putIfAbsent，确认底层已出现该键，再故意回滚；与普通 put 的回滚组比较。目标是观察即时写入不会由这个装饰器自动撤销，不能把缓存仍有值误诊为数据库回滚失效。
再在成功提交后的委托 put 处注入故障，分别记录数据库最终状态、缓存状态和调用方异常。调用方收到异常，不足以反推数据库没有提交。
延迟操作仍需恢复设计
把缓存操作安排到提交后，不等于数据库与 Redis 获得分布式原子提交，也不构成进程崩溃后的持久重试保证。这是阶段安排带来的工程边界；需要恢复保证时，应继续使用已有持久事件、幂等与缓存恢复设计。
本节不改变项目依赖版本，也不把固定版本源码核对当作 Redis、数据库或跨进程实验。来源独立发布日期未标明。