Google Drive 商品图已批准的旧版本，为什么还要单独设置保留？

封面是根据官方文档整理的操作路径示意，非平台界面截图或已完成的验收记录。

因为 Google Drive 中 JPG、MP4、PDF 等文件的旧版本，并不是无限期自动保留的批准档案。官方帮助说明，旧版本可能在 30 天后或出现 100 个较新版本时被永久删除；需要保留的具体版本可在 Manage versions 中选择 Keep forever。Google Docs、Sheets、Slides 的版本历史是另一套行为，不能直接套用。Google Drive：Check activity & file versions

本篇适用于截至 2026-10-23 官方文档所述的 Drive 二进制文件版本，面向反复替换同一商品图片、视频文件的团队。“Keep forever”用于防止修订自动清理，不是照片的使用许可，也不是任何人工删除或账号故障下的恢复保证。

先定位批准的修订，不只记一个文件名

把批准记录中的具体画面与文件版本对应起来。例如客户同意的是蓝杯、无价格字样的正面图，而当前同名文件已经改成含促销价的裁切版；保存当前链接，只能找到这一文件入口，不能代替辨认批准修订。

记录文件身份、候选修订、批准时间及内容识别点，并与真实批准导出比对。若管理版本中找不到能够确认的修订，保留已有批准文件，继续找来源；不要把日期最接近的版本直接当成正确答案。

Figma 找回客户批准版本讨论怎样比对历史画布和导出。本篇要在此之前解决另一个问题：Drive 的旧图片或视频修订是否会被自动清理，以及团队有没有固定真正需要保留的那一份。

在旧版本仍存在时设置保留

在电脑端 Drive 选择目标文件，打开 More、Manage versions，找到需要保存的版本，再选择该版本的 More、Keep forever。官方帮助以勾选标记确认所选版本不会被删除；这里应理解为该保留设置下的自动清理保护，而不是给整个账户作永久担保。需要独立交付文件时，可按相应菜单下载并检查实际文件。

Google 开发者文档把这些称为 blob revisions：没有固定的非当前修订通常保留 30 天；如果累积 100 个未固定修订并继续上传新修订，也可能提前清理。不要把“上传还不足30天”当成旧版一定安全的等待窗口。Google for Developers：Manage file revisions

该文档同时说明，每个文件最多可固定 200 个修订，固定修订计入存储容量。不要把“全部版本永远保留”作为不受容量限制的默认策略；明确哪些是批准稿、必要源版本或有保留理由的修订，再由存储负责人安排容量。

一份同名商品图的虚构保留记录

以下为完整虚构练习，未打开 Drive 文件、修改版本设置或下载图片。设定同一文件 EX-CUP-FILE 有三个修订，编辑甲负责定位，审核人乙负责确认批准内容。

R2 的观察是虚构输入，不是已完成的账户检查。真实表应填写实际文件和修订标识、保留标记、核验时间、批准依据及负责人。若没有查看到标记，不能复制示例写“已固定”。

保留旧修订，不需要覆盖当前工作

本次目标是保存批准稿，不是把当前文件恢复成旧内容。先从选定旧修订取得所需副本，按下载物与批准预览核对检查商品、文字和裁切，再决定是否需要后续编辑。

如果团队选择把旧内容重新用于当前文件，应另行批准这项变更，并考虑现有收件人可能仍通过同一文件入口访问当前内容。不能为了归档一个旧广告，顺手覆盖同事正在制作的新活动稿。

借助来源到发布物的关联记录，区分批准修订、现行工作稿与实际发布副本；保留设置只回答旧修订是否避免自动清理，不回答哪一份应该上线。

缺少版本或接近保留上限时先做什么

已找不到批准修订时，不承诺点击 Keep forever 能把它找回来；先核对独立交付副本及已有记录。无法确认修订内容、没有相应权限，或容量与固定上限尚未解决时，由素材负责人暂停“批准稿已归档”的签收，交给文件所有者或管理员处理。

不要通过主动删版本、连续上传大量修订或改动真实商品稿来验证清理阈值。一次可用的收尾应能指出具体批准修订、实际保留状态、独立副本与当前工作之间的区别，并写明未核验范围。本文不提供自动归档脚本，也没有执行版本恢复或压力测试。

署名：Itemlume 编辑组织，使用 AI 辅助起草。案例与表格为虚构练习，未进行 Google Drive 账户实测；界面规则及修订边界来自所列官方帮助和开发者文档。操作由相应文件负责人完成，不代表 Itemlume 已接通版本管理。

编辑证据政策与产品事实 · 联系与纠错。官方资料查阅日期：2026-10-23；开发者修订文档显示更新于2026-09-03，操作前仍应复核当前原文与账户界面。