批量转换中断如何恢复？outputs文件夹揭秘

在使用「unet person image cartoon compound人像卡通化」镜像处理大量照片时，你是否遇到过这样的情况：

正在批量转换30张人像，做到第18张时浏览器突然卡死或网络中断；
重启WebUI后发现——界面清空了进度条，历史记录没了，连“已成功生成哪些图”都无从查起；
只能硬着头皮重头来一遍？不，其实答案就藏在那个不起眼的outputs/文件夹里。

本文不讲模型原理、不跑训练代码、不堆参数配置，只聚焦一个工程师日常最真实的问题：批量任务意外中断后，如何快速定位已完成项、跳过重复工作、安全续传？
我们将一层层打开outputs/目录，看清它的命名逻辑、时间戳结构、文件归属关系，并给出可直接复用的 Shell 命令和 Python 脚本，帮你把“中断焦虑”变成“精准续作”。

1. outputs 文件夹不是临时缓存，而是你的任务快照库

很多用户误以为outputs/是 WebUI 运行时的临时输出目录，关掉服务就失效。但事实恰恰相反：它是整个卡通化流程中唯一持久化、可追溯、可审计的结果存储中心。

1.1 默认路径与权限结构

根据镜像文档说明，所有输出默认保存在：

项目目录/outputs/

在容器内实际路径为/root/unet-person-cartoon/outputs/（可通过docker exec -it <容器名> ls /root/unet-person-cartoon/outputs/验证）。该目录具备以下关键特征：

写入权限开放：WebUI 进程（Gradio）以 root 用户运行，可自由创建/写入文件
无自动清理机制：不会因重启、超时或错误而删除已有文件
全量保留原始输入信息：每张输出图均携带完整时间戳与序号，隐含处理顺序

注意：这不是日志文件夹（如logs/），也不是中间缓存（如cache/），而是最终交付物仓库。只要容器没被rm -f强删，里面的内容就永远安全。

1.2 文件命名规则：时间戳 + 序号 + 格式，三重锚点

查看outputs/下的文件列表，你会看到类似这样的命名：

outputs_20260104_152347_001.png outputs_20260104_152347_002.png outputs_20260104_152347_003.png ... outputs_20260104_152412_018.png

拆解其结构：

段落	含义	示例	说明
`outputs_`	固定前缀	`outputs_`	所有输出文件统一标识
`20260104`	年月日（YYYYMMDD）	`20260104`	来自系统本地时间，非UTC
`_152347`	时分秒（HHMMSS）	`_152347`	精确到秒，同一秒内多图靠序号区分
`_001`	三位序号	`_001`	最关键字段：表示本次批量任务中的第几张图
`.png`	输出格式	`.png`	由WebUI参数决定，支持`.png`/`.jpg`/`.webp`

核心结论：

同一批次的所有文件，共享相同的YYYYMMDD_HHMMSS时间戳；
序号_001,_002, ...,_018严格按处理顺序递增；
若中断发生在第18张，则_001到_018已存在，_019及之后不存在 —— 这就是你的“断点坐标”。

2. 中断场景还原：三类典型失败模式与对应恢复策略

批量转换中断并非随机事件，而是有迹可循。我们结合镜像实际运行机制，归纳出最常发生的三类场景，并给出针对性恢复方案。

2.1 场景一：浏览器崩溃 / 页面刷新（最常见）

现象：

正在“批量转换”标签页查看进度条，突然页面白屏或提示“连接已断开”；
重新访问http://localhost:7860，进度条归零，右侧面板显示“暂无结果”。

原因分析：
Gradio 前端仅维护内存中的进度状态，不向后端持久化当前序号。一旦页面丢失，前端就失去了“现在做到第几张”的上下文，但后端早已将_001至_018写入磁盘。

恢复操作（30秒完成）：

# 进入容器（假设容器名为 cartoon-app） docker exec -it cartoon-app bash # 定位 outputs 目录并列出最新批次 cd /root/unet-person-cartoon/outputs/ ls -t outputs_*.png | head -n 20

你将看到类似：

outputs_20260104_152347_018.png outputs_20260104_152347_017.png ... outputs_20260104_152347_001.png

→ 最大序号即为已完成张数（此处是018）。
→ 下次上传时，只需剔除原批次中前18张图片，剩余图片单独打包上传即可。

小技巧：用ls outputs_20260104_152347_*.png | wc -l直接统计本次批次总数。

2.2 场景二：服务器资源耗尽（OOM / CPU满载）

现象：

进度条卡在65%长达2分钟，浏览器控制台报Failed to load resource；
docker stats cartoon-app显示内存使用率持续 99%，CPU 100%。

原因分析：
DCT-Net 模型对显存/内存有明确需求。当批量图片过多（如单次传50张）、或输入图分辨率过高（>2000px），会导致推理过程内存溢出，Python 进程被系统 OOM Killer 终止 ——此时 WebUI 后端进程已退出，但 outputs/ 中已写入的文件不受影响。

恢复操作（两步走）：

确认存活文件范围：

# 查看该时间戳下所有文件的修改时间（精确到秒） stat -c "%y %n" outputs_20260104_152347_*.png | sort

输出示例：

2026-01-04 15:23:47.123456789 +0800 outputs_20260104_152347_001.png 2026-01-04 15:23:47.234567890 +0800 outputs_20260104_152347_002.png ... 2026-01-04 15:24:12.987654321 +0800 outputs_20260104_152347_018.png 2026-01-04 15:24:13.012345678 +0800 outputs_20260104_152347_019.png ← 这行可能不存在

→ 最后一个有stat时间戳的文件，就是最后成功写入的那张。

规避资源瓶颈：
- 下次批量时，将图片数量控制在15~20张以内（镜像文档明确建议）；
- 提前用mogrify -resize 1280x1280^ -gravity center -extent 1280x1280 *.jpg统一缩放输入图，避免高分辨率冲击。

2.3 场景三：手动终止 / 容器重启

现象：

你主动点击了浏览器的“停止加载”按钮；
或执行了docker restart cartoon-app；
再次打开 WebUI，发现“批量转换”面板空白。

原因分析：
Gradio 的批量处理是同步阻塞式调用。一旦进程被中断（SIGINT/SIGHUP），当前正在处理的那张图会失败，但此前已完成的图已刷入磁盘，且文件句柄已关闭—— 它们完全独立于 WebUI 进程生命周期。

恢复操作（零风险）：
直接进入outputs/，按时间戳筛选出最新批次，用序号判断断点。无需任何额外工具，纯文件系统操作即可。

重要提醒：不要尝试rm outputs_20260104_152347_*.png全部删除再重来！这等于放弃所有已完成工作，白白消耗算力。

3. 实战脚本：三行命令自动识别断点 + 生成待处理清单

手动数_018很快，但若面对上百张图、多个中断批次，效率骤降。我们提供两个轻量级脚本，真正实现“一键续传”。

3.1 Shell 脚本：`find-breakpoint.sh`（推荐新手）

功能：自动识别最新批次的最大序号，并输出待处理图片列表（需你自行准备原图）。

#!/bin/bash # find-breakpoint.sh - 在 outputs/ 中定位最新批量任务断点 OUTPUTS_DIR="/root/unet-person-cartoon/outputs" LATEST_PREFIX=$(ls "$OUTPUTS_DIR"/outputs_*.png 2>/dev/null | head -n1 | sed -E 's/(outputs_[0-9]{8}_[0-9]{6})_.*/\1/') if [ -z "$LATEST_PREFIX" ]; then echo " outputs/ 中未找到任何输出文件，请先运行一次批量任务" exit 1 fi MAX_SEQ=$(ls "$OUTPUTS_DIR"/${LATEST_PREFIX}_*.png 2>/dev/null | sed -E 's/.*_([0-9]{3})\..*/\1/' | sort -n | tail -n1) if [ -z "$MAX_SEQ" ]; then echo " 未识别到有效序号，请检查文件命名" exit 1 fi echo " 最新批次前缀：$LATEST_PREFIX" echo " 已完成最大序号：$MAX_SEQ" echo " 下次上传时，请排除原图中前 $MAX_SEQ 张，从第 $(($MAX_SEQ + 1)) 张开始"

使用方式：

# 保存为脚本并赋予执行权限 echo '#!/bin/bash ...' > /root/find-breakpoint.sh chmod +x /root/find-breakpoint.sh # 直接运行 /root/find-breakpoint.sh

输出示例：

最新批次前缀：outputs_20260104_152347 已完成最大序号：018 下次上传时，请排除原图中前 18 张，从第 19 张开始

3.2 Python 脚本：`generate-resume-list.py`（进阶用户）

功能：读取你原始图片文件夹（如input_photos/），自动跳过已处理项，生成精简版待处理 ZIP 包。

#!/usr/bin/env python3 # generate-resume-list.py - 自动构建续传图片包 import os import glob import shutil import zipfile from pathlib import Path OUTPUTS_DIR = Path("/root/unet-person-cartoon/outputs") INPUT_DIR = Path("/root/unet-person-cartoon/input_photos") # 请按实际路径修改 RESUME_ZIP = Path("/root/unet-person-cartoon/resume_batch.zip") def get_latest_batch_seq(): png_files = list(OUTPUTS_DIR.glob("outputs_*.png")) if not png_files: raise RuntimeError("outputs/ 中无输出文件") # 提取所有时间戳前缀 prefixes = set(f.stem.split("_", 2)[0] + "_" + f.stem.split("_", 2)[1] for f in png_files) latest_prefix = max(prefixes) # 字典序即时间序 # 提取该前缀下所有序号 seqs = [ int(f.stem.split("_")[-1]) for f in png_files if f.stem.startswith(latest_prefix) ] return latest_prefix, max(seqs) def main(): try: prefix, last_seq = get_latest_batch_seq() print(f" 识别到最新批次：{prefix}，已完成 {last_seq} 张") # 获取所有原始图片（按字典序，确保与上传顺序一致） all_inputs = sorted(INPUT_DIR.glob("*.{jpg,jpeg,png,webp}")) if len(all_inputs) <= last_seq: print(" 所有图片均已处理完毕！") return # 取出待处理部分（从 last_seq+1 开始） resume_inputs = all_inputs[last_seq:] print(f"📦 准备 {len(resume_inputs)} 张待处理图片...") # 打包 with zipfile.ZipFile(RESUME_ZIP, 'w', zipfile.ZIP_DEFLATED) as zf: for i, img_path in enumerate(resume_inputs, start=last_seq+1): # 保持原文件名，避免 WebUI 解析异常 zf.write(img_path, arcname=img_path.name) print(f" 续传包已生成：{RESUME_ZIP}") print(f" 下次在 WebUI「批量转换」中上传此 ZIP 即可") except Exception as e: print(f"❌ 执行失败：{e}") if __name__ == "__main__": main()

使用方式：

# 确保 input_photos/ 存在且包含全部原始图 mkdir -p /root/unet-person-cartoon/input_photos cp /your/original/photos/*.jpg /root/unet-person-cartoon/input_photos/ # 运行脚本 python3 /root/generate-resume-list.py

4. 预防胜于补救：四条实操建议让批量更稳

知道怎么恢复只是下策，让中断不再发生才是上策。基于该镜像的实际运行表现，我们总结出四条经过验证的稳定性建议：

4.1 严格控制单次批量规模

镜像文档明确建议“单次不超过 20 张”，这不是保守数字，而是经压力测试得出的安全阈值。

推荐值：12~15 张/批（留出 20% 内存余量）
❌ 避免：一次性拖入整个相册（如 50+ 张），尤其当含多张 4K 人像时。

4.2 输入图预处理：统一尺寸 + 格式标准化

DCT-Net 对输入敏感。未经处理的手机直出图（如 HEIC、超宽屏截图）易触发异常。
执行以下预处理（一行命令搞定）：

# 安装 imagemagick（如未安装） apt-get update && apt-get install -y imagemagick # 批量转换：统一为 JPG + 限制最长边 1280px + 去除元数据 mogrify -format jpg -resize 1280x1280^ -gravity center -extent 1280x1280 -strip *.heic *.png *.webp

4.3 启用 WebUI 参数：降低分辨率 + 中等风格强度

高分辨率（2048）和高强度（1.0）虽效果惊艳，但显著拉长单图耗时（从 5s → 12s+），增加中断概率。

生产环境推荐设置：
输出分辨率：1024（画质足够印刷，速度提升 40%）
风格强度：0.75（自然卡通感，避免过度失真）

4.4 关键操作后手动备份 outputs/

虽然outputs/本身很安全，但为防容器误删或磁盘故障，建议养成习惯：

每完成一个重大项目（如婚礼300张图），执行：

tar -czf outputs_$(date +%Y%m%d_%H%M%S).tar.gz -C /root/unet-person-cartoon outputs/

将生成的.tar.gz拷贝至宿主机：

docker cp cartoon-app:/root/unet-person-cartoon/outputs_20260104_183022.tar.gz ./backup/

5. 总结：把 outputs/ 当作你的批量任务“区块链”

outputs/文件夹没有花哨的数据库、没有复杂的日志解析，它用最朴素的文件系统语义，实现了最可靠的状态持久化：

不可篡改性：文件一旦写入，时间戳与序号即固化；
可验证性：通过ls/stat/wc等基础命令，10秒内确认断点；
可移植性：ZIP 包跨平台、跨设备、跨浏览器，随时续传。

下次当你看到进度条卡住、浏览器报错、甚至怀疑“是不是全白做了”，请记住：
→ 打开终端，ls /root/unet-person-cartoon/outputs/；
→ 找到那个最长的outputs_YYYYMMDD_HHMMSS_XXX.png；
→ 把XXX加 1，就是你下一次的起点。

技术的价值，不在于它多炫酷，而在于它多可靠。而可靠性，往往就藏在一个被忽略的文件夹里。