Flux Art先找出成功提示依据哪一个事件
把 Flux Art 图片结果交给自建浏览器素材库后，界面可能在一条写入请求成功时就显示已保存，但同一事务中的后续操作失败，整个修改最终没有提交。也可能先创建事务，再等待外部请求，回来时事务已经不再活动。本文讨论接收方的 IndexedDB 实现，不声称平台采用该结构。先记录提示由哪个事件触发，才能区分请求返回、事务完成和用户真正看到可恢复记录这三个层次。
把外部准备放在事务之前
建议先完成网络获取、格式转换和业务校验，准备好本次要保存的数据快照，再开启尽量短的事务。不要创建事务后等待用户点按钮，也不要在其中等待无关网络请求。记录本次操作编号、数据版本、涉及的对象仓库和必须一起保存的记录，明确哪些部分需要原子性。若准备期间业务版本已变化，应重新核对输入，而不是拿过期快照覆盖当前记录。
理解活动期与自动提交
MDN 说明，事务在创建它的任务以及请求的成功或错误事件处理任务中处于活动状态，在其他任务中可能不活动；没有待处理请求且没有再加入新请求时会自动提交。不能把一个 JavaScript 变量仍存在理解为事务一直可写，也不能将所有 await 简化成同一种行为。应避免跨越无关异步任务后再向旧事务追加请求，依据实际活动期安排操作。
| 观察点 | 应该等待或核对 | 不得误报 |
|---|---|---|
| 外部数据准备 | 输入快照完成 | 事务尚未开始 |
| 单条请求成功 | 继续等待最终事务 | 不立即称已保存 |
| 事务中止 | 失败原因及候选保留 | 不隐藏为成功 |
| 事务完成 | 对应操作编号与版本 | 不称远端已同步 |
| 提交后回读 | 真实数据库记录 | 不只看内存对象 |
| 浏览器数据丢失 | 独立备份恢复结果 | 不承诺永久保存 |
等待事务完成，再报告已保存
为事务绑定 complete、abort 和 error 等需要的处理，把单条请求结果与事务最终状态分别记录。建议只有确认事务完成后才将这次本地保存标为成功；请求成功只表示该请求阶段通过。涉及多条必须一致的记录时，在同一合适范围的事务内处理，失败后保持明确的未提交状态。不要在错误回调中仅隐藏提示，使界面继续展示一个没有持久记录的成功版本。
读写流程要能识别版本与重复操作
事务提交后，可按操作编号读取已存版本并验证关键字段，作为应用级验收。不要用列表上仍在内存中的旧对象冒充数据库回读。用户在等待期间再次点击保存时，应通过当前应用状态约束重复执行，或设计明确的幂等标识，避免生成多份难以区分的草稿。本文不提供通用冲突合并策略，跨标签或跨设备同步仍需独立设计，不能由本地事务成功推断已经同步。
用后续失败验证是否误报成功
假设一个事务需要同时写入素材记录和关联索引，第一条请求成功后第二条因测试约束失败。这是假设故障注入，不是真实生产演练。检查界面没有提前承诺已保存，失败后没有留下被误当完整的记录。再测试外部准备延迟，确认事务是在准备完成后才建立。最后完成正常保存并重新读取对应版本，记录请求事件和事务事件的顺序，而不是只截取一个绿色提示。
失败恢复不要删除唯一副本
事务中止时保留待保存的候选数据，让用户看到本次未完成的原因和可重试范围。配额不足、约束冲突与程序错误不应共用无限重试。清理可再生成缓存和清除未同步草稿也不是同一操作，不能为腾空间直接删除唯一素材。若无法确认当前保存结果，标为待核对并先查询操作编号；不要同时告诉用户成功，又在后台悄悄重建一个新版本。
本地完成不是灾难恢复保证
事务完成是正常应用流程的重要边界，但不应承诺在任意断电、浏览器数据清除或设备损坏后都能恢复。关键素材仍需设计独立导出或获授权的同步备份。交付记录写清浏览器版本、数据库版本、对象仓库范围和故障样本，说明测试是普通关闭重开还是其他恢复场景。未实际演练的异常保持未知，不能用一条 complete 事件替代完整的备份与恢复验收。
资料与业务接入
技术依据核对于2026年11月9日：事务生命周期见 https://developer.mozilla.org/en-US/docs/Web/API/IDBTransaction 。本文的操作编号、候选保护和回读核对是接入方工程建议。Flux Art 生成结果可用于商业用途，输入素材权利和商品真实性另行核验；接口入口为 https://flux-art.net/zh/openapi 。图片生成完成、本地保存完成与远端业务同步完成应分别记录，不将浏览器存储流程写成平台已提供的持久化服务。