清缓存前先按内容去重：真正占地方的往往不在你盯着的地方
出图目录里被担心的元数据其实只占万分之七，而按内容哈希排一遍发现 14 张是字节级重复、占了 17.54%，两者差 234 倍。重复的成因是批量脚本把 seed 写成了常量（101/202/303…各重复三遍）。真正的损失在产出账：按文件数统计会虚高 23%。
出图目录重复图内容哈希seed产出核算缓存清理这条适用于
- 出图目录持续增长 / 准备清缓存
- 需要按「内容」而不是「文件名」判断重复
版本指纹
本机 ComfyUI 输出目录；元数据占比随工作流规模变
具体做法
实测（75 张出图，合计 101.42 MB）：
· PNG 文本块（内嵌工作流）合计 79,806 字节 = 77.9 KB = 0.075%
· 按内容哈希分组：61 个唯一，14 张重复 = 17.787 MB = 17.54%
· 两者比值 234 倍
· 重复形状：7 组三连张，组内种子 101/202/303/404/505/606/707；另 1 组两张为同种子同分辨率同提示词
· 产出账：按文件数 75 张、按唯一内容 61 张，虚高 23%；7 组三连张的 21 个文件里只有 7 张不同
· 目录里另有 3 个完全不含文本块、规格也不同的文件（非该工具产出）失效边界
内容哈希只能识别字节级完全相同的文件，改过一处元数据就是不同哈希，因此它给出的是重复的下限而非上限。真正该删哪些要结合业务判断（同名不同参数的两张都必须留）。元数据占比会随工作流规模变化，图越复杂文本越长，本文比例不代表重工作流场景。
内容哈希只能识别字节级完全相同的文件，改过一处元数据就是不同哈希，因此它给出的是重复的下限而非上限。真正该删哪些要结合业务判断（同名不同参数的两张都必须留）。元数据占比会随工作流规模变化，图越复杂文本越长，本文比例不代表重工作流场景。