点「删除」之后文件还在不在：删除标记、版本状态与对象锁是三条独立的线

直接答案

「我在对象存储里把文件删了，它到底还在不在？」这个问题的答案不是「在」或「不在」，而是四件事的组合：桶的版本状态、这次请求带不带 versionId、这个版本有没有被锁、有没有一条生命周期规则在背后动手。

同一句「删除」，在不同组合下至少有这几种结果：

你做的动作	桶的状态	结果
不带 versionId 的删除（simple DELETE）	从未开过版本控制	对象被删除（这是未开版本控制时的默认语义；删除标记只出现在开启或暂停版本控制的桶里）
不带 versionId 的删除	版本控制已启用	对象没有被删除，只是插入一个删除标记并成为当前版本；读取得到 404
不带 versionId 的删除	版本控制已暂停	仍会插入删除标记（原文明确覆盖 enabled or suspended 两种桶）
带 versionId 的删除	已启用／已暂停	那一个版本被永久删除，且不插入删除标记
带 versionId 的删除	该版本被对象锁保护	403 Access Denied，删不掉
不带 versionId 的删除	该版本被对象锁保护	200 OK，插入一个新的删除标记——动作成功，字节还在
生命周期过期规则（Expiration）	从未开过版本控制	异步永久删除
生命周期过期规则	版本控制已启用	只插入删除标记，不永久删除
生命周期「非当前版本过期」	版本控制已启用	永久删除非当前版本，且「can’t be recovered」

这张表就是全文的骨架。下面把每一条拆开，讲清它为什么是这样，以及你在控制台里看到的「已删除」到底对应哪一行。

本文以 Amazon S3 的公开文档为样本（版本控制、删除标记、对象锁、生命周期四组页面）。这些机制在其它对象存储里名字不同、默认值不同，但要问的问题是一样的：桶在什么状态、请求带不带版本、这个版本有没有保护、有没有规则在替你做决定。

一、先把「删除」拆成四条线

绝大多数「删了怎么还在」的困惑，来自把四件互不相关的事当成一件：

线	它回答什么	谁在决定
① 桶的版本状态	这个桶会不会保留旧版本	桶级配置，一旦启用就回不去
② 请求形态	你删的是「这个键」还是「这个版本」	你的代码、CLI、控制台按钮
③ 保护层	这个版本能不能被永久删除	对象锁的保留期与法律保留
④ 生命周期	有没有规则在按天替你删	桶上的规则，且不受桶策略约束

四条线是正交的：开了版本控制不等于有保护（生命周期照样能永久删非当前版本）；加了对象锁也不等于「删不掉」（不带 versionId 的删除照样返回成功）；反过来，没开版本控制时，一次删除就是一次真删除，没有第二次机会。

一个容易被忽略的细节是版本控制的状态作用于整个桶，而不是某些对象：原文写的是「The versioning state applies to all (never some) of the objects in that bucket.」所以你不能在一个桶里「只给重要文件开版本控制」，只能换桶或换前缀分桶（这是编辑判断：分桶会改变权限与生命周期的作用范围，别为了省事把两者混在一起）。

二、版本控制：三个状态，一道单向门

桶只有三种状态：未启用（默认）、已启用、已暂停。关键的一句是：

After you version-enable a bucket, it can never return to an unversioned state. But you can suspend versioning on that bucket.

也就是说，「关掉版本控制」这个动作在 S3 里不存在，只有「暂停」。暂停之后，已有对象不变，变的是后续请求怎么处理。这条约束对一人公司的实际意义是：一个桶一旦开了版本控制，它的「按版本计费」模式就永久改变了，你只能在生命周期规则上做减法，不能回到「一份对象一份钱」。

关于「开了版本控制之前就存在的对象」，原文给了一个必须记住的细节：

Objects that are stored in your bucket before you set the versioning state have a version ID of null.

这些对象的版本 ID 是 null。开启版本控制不会改变它们的内容与权限，只改变后续请求的处理方式。等到它们下一次被修改，才会拿到一个真正的版本 ID。这也是后面「暂停版本控制」时那条 null 版本规则的来源。

计费是按版本整份算的，不是增量：

Each version of an object is the entire object; it is not just a diff from the previous version. Thus, if you have three versions of an object stored, you are charged for three objects.

一个 2 GB 的文件改十次，账单上是十份 2 GB（外加请求费），不是「2 GB + 十次小改动」。这条直接决定了「版本控制 + 生命周期」必须一起设计，否则你只是把「误删」换成了「账单」。

还有两个操作性副作用，都是原文写明的：

• 开启后要等一会儿。 首次开启版本控制时变更需要传播，期间可能出现「间歇性 HTTP 404 NoSuchKey」，官方建议「wait for 15 minutes after enabling versioning before issuing write operations (PUT or DELETE)」。刚开完就灌数据，会看到莫名其妙的 404。
• 版本太多会拖垮写入。 如果某个对象积累了「millions of versions」，对该桶的 PUT／DELETE 会出现大量 503 Service Unavailable。不是权限问题，是版本数问题。

三、不带 versionId 的删除，只是插了一个标记

这是全文最反直觉的一节。在开启版本控制的桶里，一次普通的 DeleteObject（不带 versionId）不会删除任何字节：

the object is not deleted. But the delete marker makes Amazon S3 behave as if the object is deleted.

删除标记（delete marker）本身是一个「像对象但不是对象」的东西：它有 key 名、有版本 ID，但没有数据、没有 ACL。它成为该 key 的当前版本，于是：

• 不带 versionId 的读取返回 404 Not Found，并带响应头 x-amz-delete-marker: true；
• 带 versionId 读取「恰好是标记」的那个版本，返回 405 Method Not Allowed，同样带这个头；
• 这个头的值永远不会是 false——为假时它干脆不出现。所以「有没有这个头」比「头里写了什么」更有信息量。

三个操作层面的后果，都值得写进 runbook：

① 列表接口看不见它。 原文写得很直接：ListObjectsV2 或 ListObjects 不会返回「当前版本是删除标记」的对象；要看到删除标记与其它版本，只能用 ListObjectVersions。所以「我在控制台列表里找不到这个文件」不能证明它被永久删除了——它可能只是被一个标记挡住了。

② 删除标记会一直留着。 「Even if overwritten, delete markers remain in your object versions.」你后来又上传了同名文件，旧标记仍然在版本列表里，只是不再是当前版本。

③ 它自己要占一点存储，按 key 名计费。 「The storage size of a delete marker is equal to the size of the key name of the delete marker.」UTF-8 编码下每个字符占 1–4 字节，且删除标记固定存放在 S3 Standard 存储类。原文用的词是「a minimal charge」——单个标记几乎不花钱，但如果你有「每天删几万个短 key」的批处理，这笔钱是存在的，且不会因为你「删了」而停止。

还有一个方向性提醒：删除标记不是「删除失败」，也不是「删除成功」。它是「删除请求被记录下来了」。应用侧看到 404、监控看到 404 率上升、用户看到「文件不存在」，全都是真的；只有存储侧知道字节还在。

四、永久删除，是带 versionId 的那一次

真正删掉字节的动作只有一个形态：

If your DELETE operation specifies the versionId, that object version is permanently deleted, and Amazon S3 doesn’t insert a delete marker.

配合版本控制页那句「恢复很容易」，完整的操作闭环是三步：先 ListObjectVersions 找到目标版本的 ID，再带 versionId 删除，最后确认列表里真的没有了。少任何一步，你都不知道自己删的是标记还是数据。

顺带三个容易踩的边界：

• 新版本只在 PUT 时产生。 原文：「New versions of objects are created only when you PUT a new object.」CopyObject 底层就是 PUT，所以「复制到同一个 key」会产生新版本；而「改标签」这类不写入新对象的操作不会。用「版本数」当变更审计时，这个区别很重要。
• MFA delete 是另一道门。 开启后，删除某个版本或改变桶的版本状态，请求里「must include two forms of authentication」。它不是加密，是把「删历史」这件事从「有权限就行」变成「有权限 + 第二个因素」。
• 控制台的「删除」按钮不等价于永久删除。 控制台默认行为通常是「简单删除」（插标记），要删具体版本得先显示版本再选中版本。这正是下一节那个「动作成功、字节还在」的场景来源。

五、对象锁保护的是版本，不是「删除」这个动作

这是本文最值得记住的一句原文：

Placing a retention period or a legal hold on an object protects only the version that’s specified in the request. Retention periods and legal holds don’t prevent new versions of the object from being created, or delete markers to be added on top of the object.

拆开就是：锁保护「这个版本不被覆盖或删除」，不保护「这个 key 看起来还在」。 于是同一把锁，在两种删除请求下给出两种完全不同的响应：

请求	响应	你该怎么读
带 versionId 的永久删除	403 Access Denied	锁生效了，字节删不掉
不带 versionId 的简单删除	200 OK + 新删除标记	锁也生效了，但应用看到的是「删成功」

如果你的合规诉求是「监管期内这份文件必须可读」，那么第二行就是一个真实的缺口：任何人都能用一个普通删除把文件从应用视角藏起来，而锁不会阻止这件事。要堵这个缺口，得在权限层禁止对该前缀做 DeleteObject（编辑判断），锁本身不负责这件事。

两种保留模式的区别，原文写得很硬：

• 合规模式（compliance）：受保护的版本「can’t be overwritten or deleted by any user, including the root user in your AWS account」；保留模式不能改、保留期不能缩短；提前删除的唯一办法是「delete the associated AWS account」。这句不是修辞——它意味着配错保留期的代价可能是「等它到期」或「注销账号」。
• 治理模式（governance）：默认保护大多数用户，但持有 s3:BypassGovernanceRetention 权限的人可以在请求里带 x-amz-bypass-governance-retention:true 绕过。原文还留了一个非常实际的注脚：S3 控制台默认就会带这个头，所以「有权限的人在控制台点删除会成功」——CLI 拒绝、控制台成功，不是权限配错了，是控制台替你加了绕过头。

另外三个常被误解的点：

① 锁只在开了版本控制的桶里生效。 「Object Lock works only in buckets that have S3 Versioning enabled.」没有版本，就没有「版本」可锁。

② 法律保留（legal hold）没有到期日。 它和保留期相互独立：保留期到期了，法律保留还在，对象继续受保护；反之亦然。任何有 s3:PutObjectLegalHold 权限的用户都可以放置或移除它——所以它是流程约束，不是不可撤销的物理约束。

③ 保留期可以延长，不能缩短。 合规模式下模式与期限都锁定；治理模式下改期限需要绕过头。原文还有一个容易忽略的细节：不同版本可以有不同的保留模式与期限。举例来说，一个已经进入 30 天保留期第 15 天的对象，你再 PUT 一个同名、60 天保留期的新版本，旧版本仍按原来的 30 天走，15 天后就可删——「新版本锁得久」不会延长旧版本的保护。

六、生命周期是第四个「删除者」

很多人以为「生命周期只是省钱工具」，但在版本控制的桶里，它的语义会变：

Versioning-enabled bucket – If the current object version is not a delete marker, Amazon S3 adds a delete marker with a unique version ID.

也就是说，Expiration 动作在开了版本控制的桶里不永久删除任何东西，它只是替你插一个删除标记，把当前版本变成非当前版本。真正会永久删除的，是另一个动作：

You can use the NoncurrentVersionExpiration action element to direct Amazon S3 to permanently delete noncurrent versions of objects. These deleted objects can’t be recovered.

这就是那句「开了版本控制之后，想保持原来的永久删除行为，必须额外加 noncurrent expiration 配置」的机制来源。只配 Expiration 的结果是：对象从列表里消失、存储继续计费、版本越堆越多——一个既不省钱也不安全的中间态。

关于「非当前版本过期」，原文给了两个可配参数与一个硬约束：可以按「成为非当前版本后的天数」计，也可以指定「最多保留多少个非当前版本」（取值 1–100）；但指定这个上限时必须同时给 Filter 元素，否则请求会返回 InvalidRequest。

生命周期的另外几条，决定了它有多难被「挡住」：

• 桶策略挡不住它。 「You can’t use a bucket policy to prevent deletions or transitions by an S3 Lifecycle rule.」原文甚至把话说满：即使桶策略拒绝所有 principal 的所有动作，生命周期配置照常运行。想阻止某条规则生效，只能改规则本身。
• 它对已有对象也生效。 加规则时，已经超过阈值的对象会被排队处理，「今天加规则、明天发现老文件全没了」是正常行为。
• 它只处理当前版本。 「Object expiration applies only to an object’s current version (it has no impact on noncurrent object versions).」所以「过期」在版本桶里等于「插标记」。
• 删除标记本身也有清理规则。 如果当前版本是删除标记、且它是唯一剩下的版本（原文叫 expired object delete marker），S3 会把它移除。
• 对象锁会让它停手。 「Amazon S3 doesn’t take any action on noncurrent versions of objects that have the S3 Object Lock configuration applied.」——被锁的非当前版本不会被生命周期清掉。这既是保护，也是成本：锁多久，就存多久。
• 计费在「符合条件」时切换，不等真删。 原文：「billing changes are applied as soon as the object becomes eligible for the lifecycle action」，即使实际删除有延迟，过期之后不再收存储费。
• 一天只执行一个动作，冲突时按代价排序。 同一对象同一天符合多条规则时，「Permanent deletion takes precedence over transition」，而「Transition takes precedence over creation of delete markers」。这不是「先到先得」。
• 按标签的规则会在执行时重新读标签。 规则每天评估一次，执行时再核对当前标签；标签没了，过期就不执行。反过来，「想阻止一次即将执行的过期」可以删标签——原文提示标签更新的生效速度比规则变更快（规则传播最长 15 分钟）。

还有一类成本不会显示在「删除」按钮上：如果对象在最短存储期未满时被过期（例如 IA 类未满 30 天、Glacier Flexible Retrieval 未满 90 天、Deep Archive 未满 180 天），你仍按最短期限付费。删除动作免费，提前删除不免费。

七、「删了到底还在不在」核对清单

下面这套顺序是编辑判断（API 名称取自上述文档，命令语法以你所用 SDK／CLI 版本为准），原则是先读状态，再读版本，最后才动手：

#	检查项	看什么	漏了会怎样
1	桶的版本状态	桶属性里的 versioning 配置：未启用／已启用／已暂停	把「已暂停」当成「未启用」，误判删除语义
2	对象是否只剩删除标记	不带 versionId 的 HeadObject／GetObject：404 且带 x-amz-delete-marker: true	以为文件没了，其实只是被标记挡住
3	版本列表	ListObjectVersions（不是 ListObjectsV2）	列表里看不到，就以为已经永久删除
4	目标版本 ID	从第 3 步拿到确切的 versionId	删错版本，或删了个标记
5	该版本是否被锁	对象锁配置：保留模式、保留到期日、法律保留	永久删除请求直接 403，或误判「锁没生效」
6	桶上的生命周期规则	有没有 Expiration、有没有 NoncurrentVersionExpiration	以为「留着就一直在」，其实规则在删
7	最短存储期	对象所在存储类与已存天数	提前删除仍按最短期限计费
8	版本数量趋势	单 key 的版本数是否在失控增长	累积到百万级后写入开始 503
9	删除路径的权限边界	谁能发 DeleteObject、谁能带 versionId、谁能绕过治理模式	有锁也挡不住「从应用视角消失」
10	恢复演练	真的按 versionId 取回一次，并核对内容哈希	只有「以为能恢复」

一段最小示例（语法未在真实桶上执行，仅示意顺序）：

# 1. 桶状态
aws s3api get-bucket-versioning --bucket example-bucket

# 2. 这个 key 的当前状态（看是否 404 + x-amz-delete-marker）
aws s3api head-object --bucket example-bucket --key reports/2026-q3.pdf

# 3. 列出所有版本与删除标记
aws s3api list-object-versions --bucket example-bucket --prefix reports/2026-q3.pdf

# 4. 取回某个具体版本并核对
aws s3api get-object --bucket example-bucket --key reports/2026-q3.pdf \
  --version-id <version-id> /tmp/restored.pdf && shasum -a 256 /tmp/restored.pdf

# 5. 只有确认无误，才永久删除指定版本
aws s3api delete-object --bucket example-bucket --key reports/2026-q3.pdf \
  --version-id <version-id>

第 4 步的哈希核对不是形式主义：版本列表里「有这一版」与「这一版内容正确」是两件事，尤其当你的写入路径有过重试或并发覆盖时。

八、六种常见误读

误读一：「开了版本控制就不会丢数据。」 版本控制只保证「删除变成标记」「覆盖变成新版本」。它不阻止生命周期永久删除非当前版本（原文：这些对象「can’t be recovered」），也不阻止有人带 versionId 直接删。它甚至不阻止「版本控制被暂停后继续按暂停语义写入」。版本控制是恢复能力，不是保留承诺。

误读二：「删除标记占一份完整的对象存储。」 不。删除标记没有数据，存储大小等于 key 名的字节数，固定放在 S3 Standard。真正贵的是版本本身——每个版本都是完整对象。

误读三：「合规模式就是永久保留。」 合规模式保护到 retain-until-date 为止；到期后对象可以被覆盖或删除。它锁的是「期限内不可删」，不是「永远不可删」。把它当永久归档，会在到期那天发现文件可以被任何人删掉。

误读四：「生命周期过期 = 永久删除。」 只在未开版本控制的桶里成立。开了版本控制，Expiration 只是插标记；要真删，得配 NoncurrentVersionExpiration（或显式带 versionId 删）。这也是「明明配了过期，账单没降」的最常见原因。

误读五：「加了对象锁，文件就删不掉了。」 不带 versionId 的删除会返回 200 OK 并插入新标记——从应用视角文件确实「没了」。锁保护的是被锁的那个版本不被永久删除，不保护这个 key 的可见性。

误读六：「暂停版本控制就回到原来了。」 桶「can never return to an unversioned state」。暂停只是让后续写入不再累积新版本，已有的版本、已有的删除标记、已有的计费都还在。而且暂停状态下的删除仍会插标记（原文覆盖 enabled 与 suspended 两种桶）。

九、本周就能做的五件事

1. 列出所有桶的版本状态。把「已启用」的桶单独标出来——它们的删除语义、计费方式、生命周期配置都和默认桶不同。
2. 对其中一个开了版本控制的桶，跑一次 ListObjectVersions。看看里面有多少删除标记、多少非当前版本。多数人第一次跑会发现「以为删掉的东西全都还在」。
3. 检查生命周期规则有没有 NoncurrentVersionExpiration。只配了 Expiration 的桶，正处于「列表里没有、账单里还在」的状态。
4. 确认删除路径的形态：你的代码、CLI、控制台，各自发的是带 versionId 还是不带 versionId 的删除？把它们写成一行注释放进 runbook。
5. 挑一个被锁的版本，做一次「删不掉」验证：带 versionId 删，确认返回 403；再不带 versionId 删，确认返回 200 且出现新标记。亲手看到这两行响应，比读十遍文档都牢。

如果只能记住一件事：「删除」在对象存储里是一次请求，不是一个结果。 请求带不带版本、桶在什么状态、版本有没有锁、有没有规则在跑，四个答案拼起来才是「文件还在不在」。

---

边界说明：本文的机制性陈述全部来自 Amazon S3 用户指南的六个公开页面（2026-10-29 逐条访问，均 HTTP 200，字节数见「来源」）。不写任何单价与账单金额（原文只说「按每个版本计费」「删除标记按 key 名计费」，未在这几页给出价格）；不把合规模式写成「永久保留」；不把删除标记写成「占一份完整对象」；不把对象锁写成「防勒索万能药」——它只保护被锁的版本，新版本仍可写入，简单删除仍可让对象从应用视角消失。文中标注为编辑判断的有：未开版本控制的桶里「简单删除即永久删除」的推论、分桶替代「部分对象开版本控制」的建议、「权限层禁止 DeleteObject」作为补锁缺口的做法、第七节的核对顺序与命令示例、以及第九节的五件事。本文只覆盖 S3 的版本控制、删除标记、对象锁与生命周期四组机制，不涉及跨区域复制、对象锁的合规认证适用性、也不涉及「删除桶／删除账号」的路径。

来源

以下页面均于 2026-10-29 逐条访问并验证为 HTTP 200；字节数为当日抓取的实际大小。

1. Retaining multiple versions of objects with S3 Versioning核查于 2026/10/29（200，18 127 B）：桶只有三种状态（unversioned 默认／enabled／suspended），「After you version-enable a bucket, it can never return to an unversioned state. But you can suspend versioning on that bucket.」；版本状态作用于桶内全部对象；开启前已存在的对象版本 ID 为 null，开启不改变它们；「Each version of an object is the entire object; it is not just a diff from the previous version」，三个版本按三个对象计费；Important 段落要求：若要在开启版本控制后保持原来的永久删除行为，必须补一条 noncurrent expiration 配置。
2. How S3 Versioning works核查于 2026/10/29（200，24 913 B）：首次开启版本控制需要传播时间，期间可能出现间歇性 HTTP 404 NoSuchKey，官方建议开启后等 15 分钟再发 PUT／DELETE；版本 ID 只由 S3 生成、不可编辑、UTF-8、长度不超过 1,024 字节；不带 versionId 的 DELETE 会保留所有版本并插入删除标记；带 versionId 的 DELETE 永久删除且不插入标记；新版本只在 PUT 时产生，CopyObject 以 PUT 实现，改标签不产生新版本；单对象版本数达到百万级时 PUT／DELETE 会出现大量 503；MFA delete 要求删除版本或改变版本状态时提供两种认证。
3. Working with delete markers核查于 2026/10/29（200，20 021 B）：删除标记是 simple DELETE（不带 versionId）留下的占位物，「the object is not deleted. But the delete marker makes Amazon S3 behave as if the object is deleted.」；它有 key 名与版本 ID，无数据、无 ACL；不带 versionId 的 GET 返回 404 并带 x-amz-delete-marker: true，带 versionId 指向标记时返回 405 并带同一响应头，该头「never returns false」；「Even if overwritten, delete markers remain in your object versions.」；只有 ListObjectVersions 能列出它们，ListObjectsV2／ListObjects 不返回当前版本是标记的对象；存储大小等于 key 名大小（UTF-8 每字符 1–4 字节），存于 S3 Standard，属「a minimal charge」；只要对 enabled 或 suspended 桶发 DeleteObject，S3 就会创建删除标记。
4. Locking objects with Object Lock核查于 2026/10/29（200，36 155 B）：WORM 模型，两种保护方式为保留期与法律保留，可同时存在；「Object Lock works only in buckets that have S3 Versioning enabled.」；保留只作用于请求中指定的那个版本，「Retention periods and legal holds don’t prevent new versions of the object from being created, or delete markers to be added on top of the object.」；合规模式下受保护版本「can’t be overwritten or deleted by any user, including the root user」，模式不可改、期限不可缩短，「The only way to delete an object under the compliance mode before its retention date expires is to delete the associated AWS account.」；治理模式需要 s3:BypassGovernanceRetention 权限加 x-amz-bypass-governance-retention:true 请求头，而控制台默认就带这个头；法律保留没有到期日、独立于保留期、有 s3:PutObjectLegalHold 权限即可放置或移除；删除行为：带 versionId 的永久删除返回 403，不带 versionId 的简单删除返回 200 并插入新标记。
5. Managing the lifecycle of objects核查于 2026/10/29（200，21 032 B）：生命周期有两类动作（transition／expiration），「Amazon S3 deletes expired objects on your behalf」；「You can’t use a bucket policy to prevent deletions or transitions by an S3 Lifecycle rule」，即使桶策略拒绝所有 principal 的所有动作，规则照常运行；规则同时作用于已有对象与新增对象；计费在对象「becomes eligible」时即切换，即使实际删除有延迟。
6. Expiring objects核查于 2026/10/29（200，24 930 B）：未开版本控制的桶——异步永久删除；版本控制已启用——若当前版本不是删除标记，则插入带唯一版本 ID 的删除标记，使当前版本变为非当前版本；已暂停——插入版本 ID 为 null 的删除标记，替换掉原有的 null 版本，「effectively deletes the object」；过期只作用于当前版本，不影响非当前版本；当前版本是删除标记且还有其它版本时不动作；只剩一个「expired object delete marker」时会移除它；NoncurrentVersionExpiration 永久删除非当前版本且「can’t be recovered」，可配天数与「最多保留 1–100 个非当前版本」，指定后者必须同时给 Filter，否则返回 InvalidRequest；「Amazon S3 doesn’t take any action on noncurrent versions of objects that have the S3 Object Lock configuration applied.」；同一对象一天只执行一个动作，多条规则冲突时「Permanent deletion takes precedence over transition」「Transition takes precedence over creation of delete markers」；按标签的规则每天评估、执行时重新读标签，标签不存在则不执行，规则传播最长 15 分钟；最短存储期（IA 30 天／Glacier Flexible Retrieval 90 天／Deep Archive 180 天）未满时提前过期仍按最短期限计费。