一句定义
UUID 文件归档 = 把 Amazon Custom 客户上传图自动重命名为「订单号_序号_时间戳」的可读结构，并按订单分目录存档，让工厂端、客服端、争议端在任何时候都能反查到原文件归属。
原始 UUID 文件名（如 8f0001a3-2c4b-4a52-9c1e-3d0f4b5a9e8c.jpg）对人和工具都不友好——既不能从文件名看出属于哪条订单，也不能按订单批量找图，更不能在客诉时举证。
适用场景
Amazon Custom 含上传图 SKU：照片相框、纪念项链、宠物牌、Logo 定制 T 恤、家庭画像定制等。
多图订单：客户一单上传 2-5 张图，工厂只用第 1 张是高频客诉来源——必须建立「订单号 + 序号」映射。
与外协工厂对接：工厂收到图无法回溯到订单 = 出错时无法追责；归档后工厂可直接按订单号目录取图。
A-to-z claim / PayPal 争议：客户投诉「你们用错图」时，归档目录就是举证链路。
输入输出示例
输入（Amazon Customization ZIP 解压后）
| 原文件名 | 大小 | 用途未知 |
|---|---|---|
| 8f0001a3-2c4b-4a52-9c1e-3d0f4b5a9e8c.jpg | 2.4 MB | ? |
| 4b7e22c1-9d83-4f02-b5c8-1a2e3f4d5b6c.png | 1.1 MB | ? |
| ce920d4f-7b1a-4e36-a8d2-9f0e1b2c3d4e.jpg | 3.7 MB | ? |
输出（归档后目录结构）
```
uploads/
2026-05-23/
order_102-7345891-2233445/
102-7345891-2233445_01_20260523-1432.jpg (原: 8f0001a3-...)
102-7345891-2233445_02_20260523-1432.png (原: 4b7e22c1-...)
102-7345891-2233445_03_20260523-1432.jpg (原: ce920d4f-...)
_manifest.json (含原 UUID ↔ 新文件名 ↔ Surfaces 位置三方映射)
```
_manifest.json 内容（节选）
| 新文件名 | 原 UUID | Surfaces 位置 | MD5 | 客户备注 |
|---|---|---|---|---|
| 102-7345891-2233445_01_20260523-1432.jpg | 8f0001a3-...-9e8c | surfaces[0].areas[0] | a4e1...c9b2 | back image |
| 102-7345891-2233445_02_...png | 4b7e22c1-...-5b6c | surfaces[0].areas[1] | 7f23...8d10 | logo |
| 102-7345891-2233445_03_...jpg | ce920d4f-...-3d4e | surfaces[1].areas[0] | 5b08...1a7e | front image |
实操步骤（6 步）
1. 从 Amazon Custom 拿到 customization ZIP 后立即解压到「待归档区」，不要直接发工厂。
2. 解析 customization JSON，提取每张图对应的 surfaces / areas 位置标签。
3. 按「订单号_序号_时间戳.扩展名」重命名，序号按 surfaces 顺序而非 ZIP 内顺序。
4. 写入 _manifest.json，保留原 UUID 与 MD5（争议时证明文件未被替换）。
5. 按订单号建子目录，统一存到 uploads/YYYY-MM-DD/ 下，保留 90 天以上。
6. 工厂端拉取时按订单号目录整包发送，不再发散文件。
常见误区
误区一：直接把 ZIP 解压发给工厂。工厂收到一堆 UUID 文件名，对不上订单只能猜——错图概率超过 9%。
误区二：只重命名不留映射。改完名找不到原 UUID，客户问「我上传的那张原图呢」答不上来。
误区三：序号按 ZIP 顺序而不按 surfaces 顺序。ZIP 内顺序不稳定，今天解压是 1.jpg，明天可能是 3.jpg——会错位。
误区四：不存 MD5。客户投诉「你们用的图被改过」时无法证明原始性；MD5 是廉价但有效的真实性证据。
误区五：归档目录不留存。订单出货 1 周就清掉，3 个月后 A-to-z claim 来了无图可查——保留 90 天是底线。
Koru 如何处理
Koru 订单同步时自动解 ZIP 并归档。原始 UUID、新文件名、surfaces 位置、MD5、客户备注五元组写入 manifest，全程不需要运营手动重命名。
按订单号目录展示。在工作台点开订单详情即可看到所有上传图的缩略图、原文件名、新文件名、所属位置——运营审核时一眼到位。
工厂导出按订单打包。导出 Excel 时同步打包对应订单目录，工厂收到的就是「订单号文件夹 + 图 + manifest」三件套，没有散文件。
争议追溯一键导出。客诉时直接导出某条订单的 manifest + 原图 + MD5，作为 A-to-z claim 或 PayPal 争议的举证材料。
行动建议
1. 立刻停止「裸 ZIP 发工厂」流程：哪怕先用脚本手动重命名也比让工厂猜强，这一步能压掉 80% 的错图客诉。
2. 定义订单号 + 序号命名规范：序号按 surfaces 顺序而非 ZIP 顺序，避免位置错位。
3. 保留 _manifest.json + MD5：每条订单都要有这两个文件，争议来临时它就是免赔金。
4. 设 90 天最短保留期：A-to-z claim 通常在出货后 30-60 天发起，归档过早清理 = 自杀式无证据。