用上传追踪器防止重复投稿：库存图片账号防封指南

批量上传库存图片时，一个不经意的重跑就可能让几十个文件重复提交，轻则审核队列积压，重则账号被平台标记。一位开发者分享了自己的教训：某周二晚上，他无意中跑了两次批量脚本，第二天早上发现两个投稿门户里多了84份重复提交。为了不再手工撤回文件，他写了一个简单的上传追踪器 upload_tracker.py，从此每次批量上传前都先检查待办清单。

重复提交为什么比想象中更危险

很多创作者觉得多传一个文件无关紧要，但从审核方的角度看，情况完全不同。Adobe Stock 的审核会检查重复和近乎相同的提交，Vecteezy 的审核员也会在队列里看到同一个文件出现两次。库存平台按下载付费，审核员会比对已有内容，重复上传容易被判定为垃圾信息或关键词堆砌，导致整个账号被审查，而不仅仅是重复的文件。手工撤回同样耗时——这位开发者花了大约四小时清理84个文件。

库存素材平台的核心审核逻辑是防止内容重复和关键词堆砌（keyword stuffing），即上传者通过重复提交相同或高度相似的文件、或滥用关键词来增加曝光。平台通常维护一个已入库内容的指纹库（如图像哈希、感知哈希），审核员会比对提交内容与库中已有素材的相似度。重复提交会被视为试图绕过正常竞争秩序的垃圾行为（spam），触发账号级别的信任降权，而不仅仅是拒绝单个文件。这种降权可能表现为审核队列优先级降低、上传配额受限，甚至临时冻结账户，恢复周期远长于清理重复文件本身。

用账本代替记忆：追踪器的核心逻辑

作者之前用文本文件记录已上传文件，但手动更新在深夜容易被跳过。新方案把记录自动化、检查强制化：追踪器是一个纯文本账本，提供三个命令——pending 列出未完成的文件，done 标记某个文件已上传，status 查看整体状态。

关键习惯是：批量脚本不再直接读取原始文件列表，而是读取 pending 的输出。这样重跑时，已上传的文件名不会出现在待办列表中，自然不会被重复提交。每次成功上传后执行一次 done，每次批量前花两秒钟看一眼 status。整个工具只用 Python 标准库，无任何依赖，在任何能 SSH 登录的机器上都能跑。

pending/done/status 这种设计本质上是一个极简的状态机：每个文件在“待上传”和“已上传”两个状态间单向迁移，账本（ledger）记录迁移结果。与数据库相比，纯文本账本的优势是零依赖、可人工检查、可通过 SSH 在任何机器上读写，且不会因为进程崩溃而损坏。将批量脚本的输入源从原始文件列表改为 pending 的输出，是一种“幂等性”（idempotency）设计——无论脚本重跑多少次，已完成的文件都不会被再次处理。这正是避免重复提交的关键：不是依靠操作者记忆，而是让系统状态成为唯一事实来源。

元数据 CSV 是对接平台的第一道门槛

在追踪器发挥作用之前，元数据必须正确。每个平台对 CSV 的列数和顺序有严格要求，表头错误会在文件进入审核前就被上传表单拒绝：Adobe Stock 要求5列，Vecteezy 要求4列，Dreamstime 要求15列。配套脚本 make_metadata.py 从同一个文件夹生成这些精确表头，不多不少。一旦 CSV 由同一文件夹生成，批量脚本就成了“哪些文件已提交”的唯一事实来源——而重跑恰恰会破坏这一点。

库存平台的 CSV 上传表单通常采用严格的列映射：每一列对应一个元数据字段（如标题、描述、关键词、类别、版权信息等），列的顺序和表头名称必须与平台模板完全一致，否则表单解析器会直接拒绝整个文件，甚至不会给出具体哪一列出错。Adobe Stock 的 5 列模板通常包含文件名、标题、关键词、类别和 releases 信息；Dreamstime 的 15 列模板则细分了更多字段，如描述、类别、模型授权等。用脚本从同一文件夹生成精确表头，可以避免手工编辑 CSV 时常见的列错位、多余逗号或 BOM 编码问题，这些问题在批量上传时会被放大成整批失败。

小服务器上的流水线生存法则

追踪器本身很轻，但周边流水线不轻。作者在1 vCPU、2GB内存、无GPU的服务器上运行全部流程，靠三个习惯维持稳定：同一时间只跑一个进程（单核并行只会互相拖累）；每处理完一个素材调用 gc.collect()；用 resource.getrusage(RUSAGE_SELF).ru_maxrss 测量峰值内存而非平均占用，因为峰值才是触发 OOM 的原因。重渲染步骤每个文件单独起子进程，让内存归还给操作系统；预览图用60 dpi 而非300 dpi 渲染。追踪器作为文本账本，几乎不占资源——安全工具本就该是技术栈里最便宜的一环。

OOM（Out Of Memory）是 Linux 内核在内存耗尽时触发的强制终止机制，会杀死占用内存最多的进程，通常表现为进程无预警消失。ru_maxrss 返回的是进程生命周期内的峰值常驻内存集（Resident Set Size），单位在 Linux 上为 KB。之所以测量峰值而非平均值，是因为 OOM 由瞬时峰值触发，平均值会掩盖内存尖峰。gc.collect() 是 Python 的垃圾回收器手动触发调用，在循环中处理大对象（如图像数组）后主动调用，可以促使循环引用对象被及时释放，降低峰值内存。子进程隔离（每个文件单独起进程）则利用进程退出时操作系统自动回收全部内存的特性，比在单进程内反复分配释放更可靠。

文件夹结构让追踪成为可能

追踪器依赖稳定的文件名。作者采用固定结构：assets/ 放原始输出，output/ 放待提交文件和元数据 CSV，packs/ 放成品压缩包和封面，research/ 存笔记和来源，scripts/ 放工具。每个素材在 assets/ 中一个文件，名字一路带到 output/。如果在步骤之间重命名，账本就会失效，所以名字定一次就别改。作者还强调保留 research/ 文件夹，他曾因清理笔记而丢失后续产品的原始素材。

工具链与落地建议

这套方案被整理成一个合规元数据工具包，包含四个脚本：make_metadata.py（精确的 Adobe 5列、Vecteezy 4列、Dreamstime 15列表头）、upload_tracker.py（上述账本）、md2pdf.py（Markdown 转样式化 PDF）和 pack_product.py（打包产品并生成1280×720封面与600×600缩略图）。整个工具包只有 Pillow 和 reportlab 两个依赖，而元数据和追踪脚本不需要任何依赖。

如果你经常跑批量上传，本周就加一个账本。手工清理重复文件是作者项目中“最无聊的四小时”，而且完全可预防。