大批量 PSD 转 JPG：用可恢复任务、manifest 与分桶模板把「跑了一夜却从头再来」的概率压到最低
电商上新、游戏活动与本地化物料往往一次抛出上千张 PSD，如果批处理脚本中途崩溃却没有断点信息，团队会在凌晨两点被迫整库重跑。`batch-psd-jpg` 这一类能力要把工程化放在第一位：每张输入对应唯一主键、明确状态机、可重试错误码与输出哈希。与此同时，亮调产品图与暗调氛围海报共用一套质量因子通常不成立，应按题材分桶配置模板并在 manifest 里写明桶 ID。只有把「哪些成功、哪些失败、失败原因是什么」结构化落盘，运营与外包才能并行消化异常，而不是在聊天里丢一堆截图。
如何使用
- 跑批前抽样三类题材各选五张做试跑，确认合并可见逻辑、色彩配置与长边缩放一致，再把正式任务切成可并行的小批次，每批写清输入根目录、输出根目录与参数 JSON 版本号。
- 任务运行中监控失败率曲线，对连续相同错误码触发熔断并单独导出失败清单；不要盲目「全部重试」，而是按错误类（文件损坏、磁盘满、色彩配置缺失）分流处理。
- 收尾时用脚本比对 manifest 与对象存储上的对象数量，随机抽检输出 JPG 的文件大小分布是否异常；将整包 manifest 与参数归档到发布仓库，便于三个月后审计仍能复现同一批像素。
PSD 转 JPG（batch）问答
上千张 PSD 批量转 JPG，怎样设计可恢复任务？
输出 manifest：输入路径、版本、状态、错误码、输出哈希；支持断点续跑与按错误类型重试，不要整库重扫。
同一目录里有的极亮有的极暗，能共用一套质量吗？
按题材分桶（产品/场景/海报）各配模板；全局单参数往往牺牲一半稿件。
运营改文件名导致映射断了，怎么防？
以源路径哈希或 PSD 内嵌文档 ID 为主键，文件名仅作展示；重命名走受控脚本。
批处理占用队列，急单插入会不会拖死大任务？
应将长耗时的大目录任务与「只要几十张」的加急单拆到不同队列，分别设置并发上限、单任务超时与优先级策略，避免小任务被前面一个万级目录堵死。超大任务本身也应支持按子文件夹分段提交与合并 manifest，这样即使某一格点故障，也只需重跑受影响段而不是整库重来。
外包回传的 JPG 与自研结果不一致，如何对齐？
在合同或工单附件中同步冻结版参数 JSON、三张以上金样 PSD 及其期望 JPG 哈希，并提供自动化像素对比或结构相似度脚本的阈值；双方每周用同一份抽检清单签字，而不是靠口头「差不多」。一旦出现偏差，先比对参数文件版本与运行环境，再谈赔偿与返工，可显著减少互相甩锅的时间。