Supplier在Seata中用于延迟创建快照，避免提前初始化失败，解耦生成逻辑与事务时机；它不缓存结果，每次get()重新执行，需自行扩展支持缓存且注意事务一致性。
Java中Supplier在Seata柔性事务中并不直接参与快照对象的“快取”，而是用于**延迟创建快照、避免无谓初始化、解耦快照生成逻辑与事务上下文绑定时机**。它本质是策略封装，不是缓存机制。
Supplier解决的是快照创建时机问题
Seata AT模式下，本地事务执行前需对涉及的数据库记录做快照（before image），以便回滚时比对和还原。但快照生成有开销，且依赖当前数据库连接和SQL执行环境。若在事务开启时就立即生成，可能因连接未就绪、SQL未编译或数据尚未变更而失败。
使用Supplier可将快照生成逻辑推迟到真正需要时（如分支事务注册前或回滚触发时）才执行，确保环境可用、数据状态确定：
- Supplier<List<Row>> beforeImageSupplier = () -> queryBeforeImage(sql, params);
- 该Supplier被保存在UndoLog或BranchTransaction中，不立刻执行
- 仅当需要校验脏写或执行回滚时，调用get()触发实际查询
它不等同于缓存，但可配合缓存优化
Supplier本身不保存结果，每次get()都重新执行逻辑。若业务场景中同一行数据在短时间被多次读取快照，可手动包装为带缓存的Supplier：
立即学习“Java免费学习笔记（深入）”；
- 用ConcurrentHashMap或Caffeine缓存key→Row映射，Supplier内部先查缓存再查库
- 注意缓存有效期：快照必须反映“事务开始时刻”的状态，不能复用跨事务的旧快照
- Seata默认不内置这种缓存，需自行扩展DataSourceProxy或UndoLogManager
与Seata扩展点的实际结合方式
在自定义undo log生成或image代理中，常见用法如下：
- 重写AbstractUndologManager#buildBeforeImage，返回Supplier而非即时List
- 在ConnectionProxy#execute中，将beforeImageSupplier传入BranchTransaction上下文
- 回滚阶段通过UndoLogParser反序列化后，仍持有一个延迟计算的Supplier（适用于JSON+表达式等轻量快照格式）
注意事项与典型误用
滥用Supplier可能导致语义错误或资源泄漏：
- Supplier内若持有Connection或ResultSet未关闭，get()多次调用会泄漏
- 若Supplier捕获了外部事务上下文（如ThreadLocal中的connection），而执行时线程已切换，会出错
- 不要用Supplier替代真正的快照持久化——UndoLog仍需落库，Supplier只是延迟加载入口
