Flux Art成功提示不能跟着选择框关闭走
将 Flux Art 图片交给自建编辑工具后，用户选择了保存位置，不等于文件已经写好。浏览器可能只是返回一个文件句柄，后面创建写入流、写入内容和关闭提交仍可能失败。本文讲接收方自己的保存流程，不宣称平台具备直接写入任意本地目录的能力。验收目标是用户指定的文件确实包含本次输出，并能在接收端打开，而不是只看到对话框关闭或一个绿色提示。
先准备候选输出，再让用户确认位置
建议在用户启动保存前准备好明确版本的输出，显示文件类型和建议名称，再由用户主动选择目标。这样能避免选择完成后才发现内容仍未生成，也便于保持一次明确的用户操作。不能在后台静默选择路径或覆盖未知文件。若确需覆盖已有文件，界面应清楚说明目标和内容版本，遵守系统确认流程；原始素材与候选导出分开保留，不用保存测试覆盖唯一源文件。
把句柄、流和提交分开看
showSaveFilePicker 返回句柄并不表示已写入。createWritable 创建可写流，通过流作出的更改在关闭前不会反映到句柄对应文件中；正常流程要等待 write，再等待 close 成功。不要在 write 返回后立即宣布全部保存完成。接口支持与选择器支持也不是同一个判断，应检测实际要使用的完整路径。下表列出每个阶段能报告什么，不将某个浏览器支持外推到所有设备。
| 阶段 | 实际结果 | 正确提示范围 |
|---|---|---|
| 用户选择目标 | 取得句柄或取消 | 尚未证明写入 |
| 创建写入流 | 流可用或拒绝 | 准备写入 |
| 写入数据 | write成功或失败 | 仍待关闭提交 |
| 关闭流 | close实际结果 | 正常保存完成边界 |
| 目标文件验收 | 可读且版本正确 | 该文件交付通过 |
| 不支持选择器 | 启用明确替代路径 | 不要假称原位覆盖 |
取消是有效结果，不是必须重试的错误
用户取消选择时，应回到可继续编辑的状态，不反复弹出窗口，也不清空候选输出。权限拒绝、写入失败和关闭失败则分别记录实际阶段，保留用户可再次尝试的素材。异常处理中如需中止尚未关闭的流，应按其状态进行受控清理，不假定中止本身成功，更不把失败自动转成已经保存。涉及已有文件时，核实最终文件状态，未知就说明需要检查。
写入策略要说明是否保留原内容
创建写入流时，是否保留现有数据影响后续写入的含义；默认行为与需要局部修改的流程不能混用。若只是导出完整新图片，优先明确写入完整候选内容，不把旧文件当作可以任意拼接的字节容器。多个标签或并发写者还可能产生覆盖竞争，建议在自己的应用层协调同一目标的保存动作。不要仅凭最后一次提示成功就推断此前版本已经妥善保留。
用可恢复测试文件验证关闭边界
假设测试员把甲图另存到一个专用测试位置，先观察取得句柄，再观察写入与关闭结果。这是假设验证，不是真实客户记录。正常路径检查文件可打开且内容对应甲；随后在隔离替身中模拟写入失败和关闭失败，确认界面没有提前报成功。再测试取消选择，确认旧文件和候选素材都未被当作删除目标。测试使用可恢复副本，不在真实业务唯一文件上制造中途故障。
不支持时明确切换交付方式
文件选择器可用性有限，不支持的环境应提供普通下载等经过验证的替代方式，并告诉用户结果保存到浏览器管理的下载位置或由其设置决定。下载路径不能冒充已取得原文件句柄，也不能承诺覆盖指定旧文件。两种方式的成功证据分开记录：直接写入看实际流完成和目标内容，下载则看其自身可确认的交付结果，不用统一提示掩盖能力差异。
最终验收需要打开实际文件
建议交付时核对目标文件名、格式、尺寸、内容版本及可读性；若设计允许读取回验，应在合法授权范围内执行。重新编码输出应与已批准的候选版本比较，不要求必然等同源文件字节。记录操作系统、浏览器、实际保存方式和错误阶段。没有测过的断电恢复、并发覆盖或特殊目录行为保持未知，不把正常 close 成功扩大为任意故障条件下都不会丢数据的保证。
资料和使用边界
技术依据核对于2026年11月9日：文件选择器见 https://developer.mozilla.org/en-US/docs/Web/API/Window/showSaveFilePicker ，写入流创建与关闭提交见 https://developer.mozilla.org/en-US/docs/Web/API/FileSystemFileHandle/createWritable 。Flux Art 生成结果可用于商业用途，输入素材权利和商品真实性另行核验；接口入口为 https://flux-art.net/zh/openapi 。本文的保存状态机与验收清单属于自建工具建议，不赋予网页额外的文件系统权限。