商品图批量生成 之后，如果导出目录里始终叫 final.jpg ，下一次处理很容易把旧图覆盖，甚至把旧文件误当作新版本上传。文件名负责说明用途，内容哈希则能帮助判断文件字节有没有变化。两者一起用，能让交接更可追溯。
商品图批量生成之后，如果导出目录里始终叫 final.jpg，下一次处理很容易把旧图覆盖，甚至把旧文件误当作新版本上传。文件名负责说明用途，内容哈希则能帮助判断文件字节有没有变化。两者一起用，能让交接更可追溯。
建议把记录文件放在导出目录之外，否则下一轮清理文件夹时可能连证据一起删掉。若团队使用云盘，同名文件同步冲突也值得检查：本地与云端名字一致，内容不一定一致。哈希能快速指出字节差异，却不能解释为什么变化；版本备注和审核记录仍是必要的。
一个足够小的验收记录
下面使用 Python 标准库 hashlib.sha256 按块读取文件，输出文件名和哈希值。把结果保存到一次导出的记录中，下次导出再对比。接口见 Python 官方文档。
import hashlib
from pathlib import Path
def sha256_file(path: Path) -> str:
digest = hashlib.sha256()
with path.open("rb") as handle:
for chunk in iter(lambda: handle.read(1024 * 1024), b""):
digest.update(chunk)
return digest.hexdigest()
for path in sorted(Path("exports").glob("*.jpg")):
print(path.name, sha256_file(path), sep=",")哈希适合回答一个很窄的问题：两个文件的字节是不是一样。比如设计师说“已经替换新版”，而运营目录里仍是旧文件；对比两份哈希，可以迅速确定文件有没有变化。但不能因为哈希不同就自动认定“这是新版正确图”，压缩参数变化也会使哈希变化。反过来，如果导出图与上次完全相同，可能是正常复用，也可能是忘记重新处理，需要结合任务记录判断。
一个可用的验收表还应有 SKU、用途、输出路径、哈希、审核状态与审核人。这里的审核人不是给程序背书，而是明确谁看过商品内容。若同名文件反复覆盖，建议按批次保留导出目录或在清单里写版本号，这样发生回滚或误传时能找到上一版。代码中的 glob('*.jpg') 只会检查当前目录里的 JPG，不会检查 PNG 或子目录；实际项目要按格式和目录约定调整。
最后上传到平台后还应查看成品页面。平台可能重新压缩图片，上传后的文件哈希通常不会等于本地导出文件；此时不能用两个哈希不一致来断言平台改坏了图。看清商品是否被错误裁切、是否传错 SKU、细节是否仍可辨认，才是上传后的业务验收。哈希负责追溯文件，眼睛与清单负责核对商品。
若要把哈希报告交给别人，最好同时保存生成报告的脚本版本。否则换了扫描目录、文件格式或排序规则，下一次报告与这次可能不可比。技术记录一旦脱离业务上下文，容易变成一串看似精确却解释不了问题的字符。报告服务于追溯，不应取代实际页面的商品核验。
一个很实际的复核办法是保留两份记录：本地导出清单与平台发布清单。前者说明交出去的文件是什么，后者说明最后上线的是哪一张。两份记录若对不上，就检查上传或替换流程，而不是让哈希工具替人猜测责任。
哈希不同，只能说明文件内容变了，不能证明图片更好或颜色更准；哈希相同，也不能说明它被正确分配到了对应 SKU。若需要检查业务版本，还要把 SKU、文件用途、导出时间和审核人写进清单，并留一份原片。对重复导出很多商品图的团队，最值得自动化的可能正是这些不起眼的验收动作，而不是让脚本宣布“所有图片已合格”。
参考资料