图片编辑图文
批量ZIP导出失败时，保住已有成品再完成交付
批次修复已经完成，但ZIP没有保存到设备，属于另一条交付链路。先分清图片处理、输出格式编码、归档准备与浏览器保存。保留队列，查看卡在哪一步，必要时用各张成品的下载入口完成交付；既然结果还在，就不必把编辑工作重新做一遍。
发布于 2026-10-30 · 更新于
1. 先确认确实有结果，再诊断ZIP
找到带“检查结果”和单图下载入口的完成卡片，打开代表性成品，确认实际修复已经存在。失败、取消或仅复核但没有结果的卡片，是另一类问题；压缩包无法提供尚未生成的图片。
清点当前拥有结果的卡片，并记录本次要交付的文件名。内置ZIP收集的是现有结果，不会顺便修复未完成图片，不会自动按另一个收件人清单筛选，也不会带上图片历史版本。先确认范围，才能避免把打包失败与处理缺项混在一起。
2. 分开看归档准备与浏览器保存
请求ZIP后，页面先按所选格式准备文件，再组装归档。如果这一阶段报错，压缩包下载可能根本没有启动。阅读可见提示，并保持队列可用，不要据此认定底下每张成品都处理失败。
如果准备已完成，却找不到保存文件，再查看浏览器下载列表、保存对话框与目标目录。权限提示、取消保存或目标位置不可用，属于准备完成之后的交付问题。没有证据就不判定具体原因，更不要因为某个目录里没有ZIP就再次修复图片。
3. 优先逐张PNG，把成品落到设备
对完成卡片使用PNG下载，在设备中找到实际新文件。这直接导出现有PNG结果，不需要再次识别或修复。先打开核对，再按可追踪的顺序，把其余目标成品保存进新建的本机交付目录。
单张下载仍可能需要浏览器批准或选择保存位置。逐项响应并检查文件名，不要连续发起一堆无法区分的下载。下载不会把卡片从队列移走，也不会自动释放页面结果占用；在需要的文件都得到验证之前，保留当前标签页。
4. 把格式转换与打包分别处理
如果原先选择的是JPG压缩包，每张结果要先导出为JPG才能归档。尝试单张PNG，有助于区分现有结果是否可读和JPG转换是否出错，但不能据此证明每个JPG编码器或以后每次归档都会成功，也不会改变已批准的修复。
批次JPG输出会把透明区域铺成白底，并重新编码。只有交付允许时才使用它。不要因为想让ZIP变小，就把必须透明的PNG换成JPG。ZIP只是装入指定文件的容器，不是画质档位，也不保证图片总大小一定更小。
5. 需要时在设备端另行打包
目标图片已安全保存并能打开后，如果收件人必须接收单个压缩包，可以使用自己设备上的归档工具。这是外部交付操作，不是TextWiper新增功能。明确选择已核对的文件，并用能识别本次交付的名称，区别先前未完成的尝试。
把新归档重新打开或解压到另一目录，对照交付记录逐项核文件。原文件名很相似时尤其要检查图片本身。压缩包能打开，但其中装错版本或漏图，仍然是不完整交付，不能仅凭总文件数看似合理就确认完成。
6. 交付文件验证后，才清空队列
只要某张成品唯一可用的副本仍在这个页面，就不要把清空队列、刷新页面或删除完成卡片当作恢复ZIP的方法。以后确实需要腾出空间，应先确认保存文件集，再明确开始新批次，并保留各自的输入输出记录。
如果连单张PNG也导出失败，保留来源并记录可见的导出情况，供进一步诊断，不要声称已经交付。可以适当地重试现有导出，不必耗自动试用次数或重跑整个队列。这里的完成标准，是收件人需要的实际图片能打开，而不是点过ZIP按钮。