S3 上传成功但 ETag 和 MD5 对不上的原因

你好呀，我是小邹。

设想一个资料归档系统：用户上传压缩包，后端将文件保存到对象存储，再比较本地文件的 MD5 与服务端返回的 ETag。两者一致，就把文件状态更新为“上传完成”；不一致，就重新上传。

这套逻辑在小文件测试中一直正常。可当用户开始上传大文件，或者存储桶调整了服务端加密方式，系统突然出现大量“文件校验失败”。

更奇怪的是，把对象重新下载下来，与源文件逐字节比较，内容并没有变化。

问题可能不在上传链路，而在校验逻辑的前提：

S3 的 ETag 并不总是文件内容的 MD5。分段上传、服务端加密方式等因素，都会影响它的含义。 AWS 官方文档明确区分了这些情况，不能把某一种上传路径下成立的关系，当成所有对象都满足的协议保证。([AWS 文档][1])

这篇文章围绕一个实际工程问题展开：怎样判断文件是否真的损坏，而不是被错误的校验方式误伤。

下面涉及的云端行为以 Amazon S3 通用存储桶为范围。其他兼容 S3 API 的存储服务，应分别核对其 ETag、加密与校验和文档，不能仅凭接口名称相同就套用结论。

一、先分清：你究竟在比较什么？

文件上传链路里，经常同时出现 ETag、Content-MD5、ChecksumSHA256、VersionId，以及业务自己保存的 sha256。

这些字段看起来都像“文件标识”，职责却并不相同。

信息	主要用途	使用时必须明确的边界
ETag	对象的实体标签，也可用于条件请求	不能普遍当作整文件 MD5
VersionId	标识启用版本控制后的具体对象版本	它不是内容摘要
整文件 SHA-256	对全部文件字节计算摘要	必须明确计算的是哪一份内容
分段组合校验和	由各分段校验和进一步组合	通常与分段边界有关
自定义元数据中的摘要	保存业务声明或业务计算结果	保存了字符串，不等于服务端验证过它

S3 的条件请求可以使用 ETag 检查对象是否满足读取或写入前提；启用版本控制后，对象版本则通过 VersionId 标识。这两种机制解决的问题不同，不应混用。([AWS 文档][2])

因此，下面这样的业务判断缺少必要条件：

boolean verified = localMd5.equals(remoteETag);

即使补上去除双引号、统一大小写，也只是修正了字符串格式，没有解决语义问题。

真正应该先问的是：

左边和右边，是否使用相同算法，对相同范围、相同版本的字节，按照相同编码方式计算？

这几个条件只要有一个不成立，“两个值不同”就不能直接推出“文件损坏”。

反过来，一个字段恰好长得像 MD5，也不能证明它就是 MD5。业务代码应该依据接口约定和对象属性判断，而不是根据字符串长度猜测。

二、为什么 ETag 有时像 MD5，有时又不像？

1. 单次上传，不代表任何情况下都能直接比较

对于通过 PutObject 等单次操作创建、使用 SSE-S3 加密或符合文档所述明文条件的对象，ETag 可以是对象数据的 MD5。

但使用 SSE-KMS 或 SSE-C 时，不能沿用这个假设。通过 Multipart Upload 或分段复制创建的对象，其 ETag 也不是整个对象的 MD5。([AWS 文档][1])

这里很容易出现一种迁移故障：

原来的上传链路满足“ETag 等于 MD5”的条件，校验代码因此长期没有暴露问题。后来基础设施开启了另一种加密方式，应用层没有改一行代码，校验却开始失败。

这并不说明新加密方式破坏了文件，而是原来的校验实现依赖了一个未被明确记录的前提。

基础设施配置可以改变 ETag 的解释方式，却不必改变下载得到的文件内容。

2. 分段上传的传统 ETag，是“摘要的摘要”

在传统的 MD5 分段组合方式下，可以这样理解 ETag 的生成过程：

先分别计算每个分段的 MD5，再把这些 MD5 的原始摘要字节按顺序拼接，对拼接结果再次计算 MD5，最后附加分段数量。AWS 的分段校验教程给出了对应计算方式。([AWS 文档][3])

用公式表示：

这里的 || 表示字节拼接。

假设上传后看到的 ETag 是：

7394719830f348918947edecf58fec1e-3

后面的 -3 表示这种组合形式对应三个分段。但即使去掉 -3，前面的部分仍然是“分段摘要拼接之后的摘要”，不是整文件 MD5。

因此，这种修复方式仍然错误：

String normalized = etag.replace("\"", "").split("-")[0];
boolean verified = localMd5.equals(normalized);

它只是把一个明显不同的字符串，变成了一个外观更像 MD5 的字符串。

3. 分段数量相同，也不代表组合摘要相同

组合校验不仅与分段数量有关，还与每个分段的边界有关。

例如，同一个文件分成三个部分：

第一次按“前一段较大、后两段较小”切分，第二次按“前两段较小、最后一段较大”切分。即使都是三个分段，参与组合的各段摘要仍然可能不同。

所以，想重建某个已有对象的组合校验和，仅知道文件总大小和分段数量通常不够，还需要知道实际分段边界。

整文件摘要描述的是完整字节序列；组合摘要还包含了分段方式带来的影响。

三、用一个本地实验，看清同文件与不同 ETag

下面生成一个固定的 12 MiB 文件，分别按 5 MiB 和 8 MiB 划分。

实验不需要 AWS 账号，只使用 Python 标准库。代码中的 usedforsecurity=False 用来明确：这里使用 MD5 是为了演示传统校验行为，不是把它作为安全设计中的抗碰撞算法。该参数需要 Python 3.9 或以上版本。([Python documentation][4])

先在独立的实验目录中生成文件：

python3 - <<'PY'
from pathlib import Path

with Path("sample.bin").open("wb") as output:
    for number in range(12):
        output.write(bytes([number]) * (1024 * 1024))

print("已生成 sample.bin，大小为 12 MiB")
PY

然后保存下面的脚本为 checksum_lab.py：

import argparse
import base64
import hashlib
import json
import sys
from pathlib import Path


def inspect_file(path: Path, part_bytes: int) -> dict:
    """模拟传统 MD5 multipart ETag，不预测任意存储服务的 ETag。"""
    full_md5 = hashlib.md5(usedforsecurity=False)
    full_sha256 = hashlib.sha256()

    part_md5_chain = hashlib.md5(usedforsecurity=False)
    part_sha256_chain = hashlib.sha256()

    total = 0
    part_count = 0

    with path.open("rb") as source:
        while True:
            data = source.read(part_bytes)
            if not data:
                break

            total += len(data)
            part_count += 1

            # 整文件摘要：直接处理原始文件字节。
            full_md5.update(data)
            full_sha256.update(data)

            # 组合摘要：处理每个分段的原始摘要字节。
            # 注意不是拼接 hexdigest() 返回的十六进制字符串。
            part_md5_chain.update(
                hashlib.md5(
                    data,
                    usedforsecurity=False,
                ).digest()
            )
            part_sha256_chain.update(
                hashlib.sha256(data).digest()
            )

    if part_count == 0:
        raise ValueError("该分段演示要求非空文件")

    return {
        "bytes": total,
        "part_bytes": part_bytes,
        "part_count": part_count,
        "full_md5_hex": full_md5.hexdigest(),
        "full_sha256_hex": full_sha256.hexdigest(),
        "full_sha256_base64": base64.b64encode(
            full_sha256.digest()
        ).decode("ascii"),
        "classic_multipart_etag": (
            f"{part_md5_chain.hexdigest()}-{part_count}"
        ),
        "composite_sha256_base64": (
            base64.b64encode(
                part_sha256_chain.digest()
            ).decode("ascii")
            + f"-{part_count}"
        ),
    }


def main() -> int:
    parser = argparse.ArgumentParser()
    parser.add_argument("file", type=Path)
    parser.add_argument("--part-mib", type=int, default=5)
    args = parser.parse_args()

    if args.part_mib <= 0:
        parser.error("--part-mib 必须为正整数")

    try:
        result = inspect_file(
            args.file,
            args.part_mib * 1024 * 1024,
        )
    except (OSError, ValueError) as error:
        print(f"校验失败：{error}", file=sys.stderr)
        return 1

    print(
        json.dumps(
            result,
            ensure_ascii=False,
            indent=2,
        )
    )
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

分别运行：

python3 checksum_lab.py sample.bin --part-mib 5
python3 checksum_lab.py sample.bin --part-mib 8

本地运行得到的结果如下：

分段大小	分段数量	模拟的传统 Multipart ETag
5 MiB	3	7394719830f348918947edecf58fec1e-3
8 MiB	2	f569746e6443164c25b25025f2c53031-2

两次计算的整文件 MD5 都是：

8ae580935168578d50e615fe0df145ef

整文件 SHA-256 也完全相同：

ded3055308dcb447b61ad0e04ec45060f57b6d8b1acdc722d612ac62ca9f31b5

这组结果来自本地计算，不是云端上传回包。

它已经足够证明一个关键问题：

文件内容没有发生变化，仅改变分段方式，就能得到不同的组合结果。

脚本中的 classic_multipart_etag 特意保留了“传统组合”的限定。不要把它改名为 s3_etag，然后认为它能够预测任意加密方式、任意兼容存储服务返回的 ETag。

这个脚本更适合作为排查工具：验证自己的分段理解是否正确，以及检查代码是否误把摘要字符串当成摘要字节进行组合。

四、换成 SHA-256，也不一定立刻正确

不少系统发现 ETag 的问题后，会把校验逻辑改成：

“以后不用 MD5，统一比较 SHA-256。”

方向没有错，但还缺一个重要条件：是哪一种 SHA-256？

1. 必须同时记录算法与校验范围

S3 区分 FULL_OBJECT 和 COMPOSITE 两种校验类型。

FULL_OBJECT 针对完整对象内容；COMPOSITE 则由分段校验和进一步组合。通过 PutObject 上传的对象使用整对象校验类型，而分段上传需要区分算法所支持的类型。([AWS 文档][5])

以几种常用算法为例，下面这张表只针对 Multipart Upload 上传阶段：

算法	支持整对象校验	支持组合校验
CRC64NVME	是	否
CRC32C	是	是
SHA256	否	是

因此，分段上传对象返回的 ChecksumSHA256，不能不看 ChecksumType 就拿来与本地整文件 SHA-256 比较。([AWS 文档][5])

这不是 SHA-256 算错了，而是参与计算的数据不同。

本地整文件 SHA-256 处理的是文件内容；组合 SHA-256 处理的是各分段的摘要。两者使用相同哈希算法，不代表它们应该输出同一个值。

2. 十六进制与 Base64，也不能直接比较

AWS CLI 的 --checksum-sha256 接收的是摘要原始字节的 Base64 编码，而不是 sha256sum 常见的十六进制字符串。([AWS 文档][6])

对于刚才的测试文件，同一份 SHA-256 摘要有两种展示形式。

十六进制：

ded3055308dcb447b61ad0e04ec45060f57b6d8b1acdc722d612ac62ca9f31b5

Base64：

3tMFUwjctEe2GtDgTsRQYPV7bYsazcci1hKsYsqfMbU=

二者字符串不同，但解码后表达的是相同的摘要字节。

正确的计算方式是：

digest_bytes = hashlib.sha256(data).digest()
checksum_base64 = base64.b64encode(
    digest_bytes
).decode("ascii")

不要先生成十六进制文本，再对这段文本做 Base64。那会得到另一组完全不同的数据。

因此，业务中的校验描述至少应包含四个维度：

对象版本、摘要算法、校验范围、摘要编码。

只保存一个名为 checksum 的字符串字段，会把这些条件全部隐藏起来。后续维护人员很难判断它能与哪个远端字段进行比较。

五、完成一次明确的整文件校验闭环

下面使用 PutObject 做一个小文件实验，将整文件 SHA-256 明确传给服务端，然后读取对象属性，最后重新下载并计算摘要。

选择单次上传，是为了让这个实验的校验范围清晰，而不是建议所有大文件都放弃分段上传。

整体过程如下：

graph LR
    A["源文件字节"] --> B["计算整文件 SHA-256"]
    A --> C["携带摘要上传"]
    B --> C
    C --> D["服务端校验"]
    D --> E["绑定对象版本"]
    E --> F["读取云端校验信息"]
    F --> G["下载并重新计算摘要"]
    G --> H["记录验证结果"]

1. 实验前提

需要配置好的 AWS 身份、已有测试桶，以及支持下列参数的 AWS CLI。命令在 Bash 环境中执行。

先设置测试桶：

export BUCKET='替换为你的已有测试桶名称'

实验使用随机生成的对象键，并通过 If-None-Match 防止同名覆盖。该条件写入机制会在对象已存在时拒绝写入，而不是直接覆盖旧对象。([AWS 文档][6])

示例遵循存储桶默认的加密配置，没有为了让 ETag 看起来像 MD5 而关闭加密。若桶策略要求显式指定加密参数，应按照桶策略补充。

下面的云端步骤需要在自己的测试环境执行；这里没有连接或操作你的 AWS 账户。

2. 上传、核验与下载脚本

将下面内容保存为 upload_verify.sh，与前面的 checksum_lab.py、sample.bin 放在同一目录：

#!/usr/bin/env bash
set -euo pipefail
export AWS_PAGER=""

: "${BUCKET:?请先设置 BUCKET 为已有测试桶名称}"

FILE="sample.bin"
KEY="integrity-lab/$(python3 -c 'import uuid; print(uuid.uuid4())').bin"

# 计算上传前的整文件摘要。
python3 checksum_lab.py "$FILE" > local-checksum.json

SHA256_B64="$(python3 -c \
  'import json; print(json.load(open("local-checksum.json"))["full_sha256_base64"])')"

# 明确提交整文件 SHA-256，禁止覆盖同名对象。
aws s3api put-object \
  --bucket "$BUCKET" \
  --key "$KEY" \
  --body "$FILE" \
  --checksum-algorithm SHA256 \
  --checksum-sha256 "$SHA256_B64" \
  --if-none-match '*' \
  --output json > put-result.json

ETAG="$(python3 -c \
  'import json; print(json.load(open("put-result.json"))["ETag"])')"

VERSION_ID="$(python3 -c \
  'import json; print(json.load(open("put-result.json")).get("VersionId") or "")')"

# 优先读取此次上传产生的具体版本。
READ_ARGS=(--bucket "$BUCKET" --key "$KEY")

if [[ -n "$VERSION_ID" && "$VERSION_ID" != "null" ]]; then
  READ_ARGS+=(--version-id "$VERSION_ID")
else
  READ_ARGS+=(--if-match "$ETAG")
fi

aws s3api head-object "${READ_ARGS[@]}" \
  --checksum-mode ENABLED \
  --output json > head-result.json

python3 - <<'PY'
import json
from pathlib import Path

expected = json.loads(
    Path("local-checksum.json").read_text()
)
remote = json.loads(
    Path("head-result.json").read_text()
)

checks = {
    "字节数": (
        remote.get("ContentLength")
        == expected["bytes"]
    ),
    "校验类型": (
        remote.get("ChecksumType")
        == "FULL_OBJECT"
    ),
    "SHA-256": (
        remote.get("ChecksumSHA256")
        == expected["full_sha256_base64"]
    ),
}

failed = [
    name
    for name, passed in checks.items()
    if not passed
]

if failed:
    raise SystemExit(
        "云端校验未通过：" + "、".join(failed)
    )
PY

aws s3api get-object "${READ_ARGS[@]}" \
  --checksum-mode ENABLED \
  --output json downloaded.bin > get-result.json

python3 checksum_lab.py downloaded.bin \
  > downloaded-checksum.json

python3 - <<'PY'
import json
from pathlib import Path

expected = json.loads(
    Path("local-checksum.json").read_text()
)
actual = json.loads(
    Path("downloaded-checksum.json").read_text()
)

if (
    expected["bytes"],
    expected["full_sha256_hex"],
) != (
    actual["bytes"],
    actual["full_sha256_hex"],
):
    raise SystemExit("下载文件与源文件不一致")

print("源文件、云端整对象 SHA-256、下载文件校验通过")
PY

printf '测试对象：s3://%s/%s\n' "$BUCKET" "$KEY"

运行：

bash upload_verify.sh

这个脚本没有把 ETag 当作摘要。它只在缺少有效 VersionId 时，把 ETag 用于条件读取。

HeadObject 需要开启校验和模式才能请求相应信息；涉及 SSE-KMS 的对象，还需要核对读取校验和所需的 KMS 权限。没有权限读取，不等于对象损坏。([AWS 文档][7])

3. 为什么优先绑定 VersionId？

假设上传完成后，另一个任务立即覆盖了相同对象键。

此时，仅执行“读取这个键的最新对象”，可能读到另一个任务上传的内容。校验结果不一致，并不能证明刚才那次上传出了问题。

使用 VersionId，可以明确读取具体版本；使用 If-Match，则是在读取时检查当前对象的 ETag 是否符合条件。GetObject 支持这两种参数，但条件读取不能完全替代版本标识。([AWS 文档][8])

没有启用版本控制时，更稳妥的业务设计是使用不可复用的对象键，并限制其他任务覆盖它。随机键只是降低名称冲突概率，不能替代写入权限和生命周期约束。

另外，脚本发现校验类型缺失或不符合预期时会退出，而不是自动改成比较 ETag。这种“拒绝猜测”的行为，比静默降级更适合校验链路。

六、大文件采用 Multipart Upload 时，重点不是再猜一次 ETag

大文件分段上传通常需要经历初始化、上传各分段、完成合并三个阶段。高层 SDK 可以封装这些步骤，但应用仍然需要理解它们各自确认了什么。([AWS 文档][9])

1. 初始化时就明确算法与类型

应在 CreateMultipartUpload 阶段确定校验算法和校验类型，而不是直到合并时才临时补一个摘要。

初始化请求支持 ChecksumAlgorithm 和 ChecksumType 等信息，后续请求需要按照所选模式组织。([AWS 文档][10])

这条规则的工程意义是：同一个上传任务，应只有一份明确的校验配置。

不要让上传第一段的工作线程选择 SHA-256，上传第二段的工作线程使用另一套默认值，再让合并线程根据响应猜测实际采用了哪种算法。

任务配置应该持久化，重试时恢复，而不是依赖某个进程启动时的默认参数。

2. 保存每个分段的真实响应

上传每个分段时，应保存对应的 PartNumber、ETag，以及使用附加校验时返回的相关校验信息。UploadPart 提供分段级校验参数与响应信息。([AWS 文档][11])

这里保存的是该次分段上传实际返回的值，不是根据本地猜出的 ETag。

对于并行上传，尤其要避免把“完成顺序”误当成“分段顺序”。第三段先传完，不代表它应该排在合并清单的第一位。

重试还需要考虑旧响应失效的问题：某个分段重新上传后，应使用与最终分段内容对应的结果，不能继续引用第一次尝试时缓存下来的响应。

3. 合并成功，必须读取完整 API 结果

CompleteMultipartUpload 根据提供的分段清单，按照分段编号顺序组装对象。

这里还有一个容易漏掉的协议细节：该操作可能先返回 200 OK 响应头，之后在响应体里返回错误。直接调用 REST API 的实现，需要解析完整响应；AWS SDK 会处理这种嵌入式错误。([AWS 文档][12])

因此，“HTTP 状态码是 200”不能成为所有 S3 操作统一的业务成功判定。

一个上传任务至少要区分：

请求已发送、分段已上传、合并已完成、完整性已确认、业务已发布。

这些状态不是同一个时刻，也不应该挤进一个没有上下文的 success=true。

4. 整文件 SHA-256 与传输校验可以并存

业务可能需要一个与分段策略无关的整文件 SHA-256，用于归档、跨系统核验或后续下载检查。

这并不意味着必须把存储服务返回的组合 SHA-256 强行解释成整文件 SHA-256。

可以分别保存两套信息：

业务层记录可信来源文件的整文件 SHA-256；存储层记录实际采用的校验算法、类型及返回值。需要跨链路验证时，再针对完整下载字节计算业务摘要。

对于某些场景，上传阶段完成服务端校验即可满足要求；对于长期归档、关键交付物等场景，还可以设计异步回读验证。选择哪一级验证，应由故障成本和业务要求决定，而不是默认所有文件都立即下载一次。

七、校验失败时，按这个顺序排查

1. 先检查是不是同一个对象

先核对 bucket、对象键、环境、版本，以及校验操作与上传操作是否对应同一个任务。

生产环境里，“测试环境摘要拿去比较生产环境对象”“旧任务覆盖新对象”“读取最新版本而不是上传版本”，都应纳入故障假设。

排查记录最好保存一次请求的对象身份，而不是让日志只打印文件名。文件名相同，并不能说明对象相同。

2. 再检查算法、范围与编码

确认本地值是 MD5 还是 SHA-256，远端值是 ETag 还是明确的校验字段。

接着检查 FULL_OBJECT、COMPOSITE，以及十六进制、Base64。

这一步应该放在网络抓包、磁盘诊断之前。否则，一个纯粹的格式或语义问题，很容易被升级成复杂的基础设施排障。

排查组合校验时，可以通过 GetObjectAttributes 获取对象校验和、分段信息等属性，而不是只观察最终 ETag 的字符串形状。([AWS 文档][13])

3. 检查参与摘要计算的字节范围

业务说“这是同一个文件”，可能指的是同一份逻辑内容，但计算机比较的是字节。

例如，压缩前的 JSON 与压缩后的文件不是同一串字节；原始文本与经过换行转换的文本也不同。

因此，要明确摘要计算发生在压缩、加密、转码、打包之前还是之后。不能拿前一个处理阶段的摘要，去比较后一个阶段的产物。

同样，校验某个范围下载的结果时，也不能直接使用整文件摘要。验证范围必须与实际读取范围一致。

4. 检查源文件是否在上传期间变化

“先计算摘要，再上传文件”存在一个前提：两次读取期间，文件保持不变。

假设导出任务还在追加内容，上传线程已经开始计算摘要，那么摘要对应的内容与最终上传内容可能不同。即使文件路径和名称完全一致，也不代表读取到了相同版本的数据。

工程上可以先完成导出，再将产物移交给上传任务；或者使用只读快照、独立暂存文件，避免生成与上传同时修改同一份文件。

这个问题不能只靠重试解决。源文件持续变化时，重试只是再次参与竞争。

5. 最后才判断是否为真实内容异常

如果对象身份、算法、范围、编码和源文件稳定性都已确认，再进一步检查上传流读取、分段组装、下载落盘及中间转换链路。

这时“校验不一致”才真正开始指向内容差异，而不是比较条件错误。

调查过程中应保留源文件、对象版本、实际响应和摘要计算方式。不要发现失败就立即覆盖旧对象，否则最有价值的现场可能被自己的重试逻辑清理掉。

八、业务状态应该表达证据，而不是表达乐观判断

下面给出一种适合归档系统的状态设计：

graph LR
    A["待上传"] --> B["上传中"]
    B --> C["存储完成"]
    C --> D["完整性验证"]
    D -->|通过| E["允许业务使用"]
    D -->|不一致| F["隔离并调查"]
    D -->|证据不足| G["待补充验证"]
    B -->|失败| H["重试或终止"]

这里最重要的区别，是把“明确不一致”和“无法完成验证”分开。

例如，远端没有返回预期校验字段，可能是请求参数、权限、接口支持或对象历史信息的问题。它应进入“待补充验证”，而不是直接标记为“损坏”。

对于业务记录，我建议至少能回答这些问题：预期摘要由谁计算，针对什么字节；上传到了哪个对象和版本；远端提供了什么校验信息；最后完成了哪一种验证。

尤其要区分“客户端声明的摘要”和“可信服务端计算的摘要”。

把用户提交的 sha256 原样写入对象元数据，之后再从元数据中读出来，两边当然可以一致，但这只能证明字符串被保存下来，不能证明对象内容经过了对应校验。S3 允许保存用户自定义元数据，这与服务端校验和机制是不同的能力。([AWS 文档][14])

还有一个容易混淆的边界：完整性不等于真实性。

下载文件与某个已知 SHA-256 匹配，可以支持内容一致性检查；但如果预期摘要也来自不可信来源，就不能据此认定文件来源可靠。

同理，MD5 已知存在碰撞弱点，本文使用它只是为了分析传统 ETag 行为，不应因此把它重新当作对抗恶意篡改的安全凭证。([Python documentation][4])

九、不要让校验本身成为新的性能与运维问题

1. 先明确验证级别，再决定读取次数

前面的实验有意采用“本地计算、上传、下载后再次计算”的方式，目的是形成一个容易理解的闭环。

生产环境不一定需要对每个对象都做立即回读。文件越大，这种做法带来的额外读取和传输工作就越明显。

优化之前，先明确系统到底要证明什么：上传流有没有意外变化，存储对象是否与可信来源一致，还是完整下载链路是否正确。

不同问题对应不同的验证方式。不要把“少读一次文件”当作唯一目标，也不要因为“验证更严格”就无差别增加多次全量读取。

2. 流式处理不等于没有校验成本

示例脚本不会把整个文件一次性读入内存，但它每次读取一个分段，峰值缓冲仍然与分段大小有关。

在高并发上传服务中，单任务可接受的缓冲量，乘以同时工作的任务数，可能形成明显的内存占用。

因此，分段大小、并行度和摘要计算策略应该一起评估。不能只调高并行上传数量，却忽略每个任务正在保留多少分段数据。

如果需要改造成生产工具，还应补充分段缓冲复用、文件稳定性检查、任务取消和错误日志，而不是简单把本地演示脚本放进线程池。

3. 重试应针对失败原因

格式错误、算法错误、权限不足、对象版本冲突和真实传输失败，不适合使用同一种重试策略。

把十六进制摘要误传到 Base64 参数里，重试十次也不会让它自动变成正确编码。

类似地，校验已经发现对象版本发生变化时，应该重新确认任务归属，而不是继续覆盖同名对象。

对于分段上传，还需要管理未完成任务。S3 提供 AbortIncompleteMultipartUpload 生命周期动作，可以用于清理长期未完成的分段上传；这应作为运维兜底，而不是替代应用正常的终止处理。([AWS 文档][15])

4. 回归测试必须覆盖“内容正确，但校验方法错误”

下面是一组适合纳入测试的场景。它们是测试设计，不是云端实测报告。

测试场景	应检查的结果
同一文件采用不同分段大小	整文件摘要保持一致，不能要求组合值一致
单次上传与分段上传切换	校验逻辑不能继续假设 ETag 等于 MD5
将摘要从十六进制改为 Base64 展示	解码后的摘要字节一致
修改文件中的一个字节	与原始预期摘要的比较应失败
摘要计算完成后继续修改源文件	不允许静默发布为已验证文件
上传后同名对象被覆盖	读取应绑定版本或触发条件检查
读取校验和缺少权限	标记为验证受阻，不能直接认定损坏
分段上传完成接口返回嵌入式错误	任务不能进入存储完成状态

最值得关注的，恰恰是第一类测试。

多数系统会测试“把文件改坏，校验能不能发现”，却很少测试“文件没坏，校验会不会误报”。

对于会自动重试、自动告警、自动隔离文件的系统，误报同样会带来真实的业务损失。

十、参考资料

Amazon S3 Object API：ETag 的适用条件

Amazon S3：上传阶段的完整性校验、整对象与组合校验

Amazon S3：分段上传与附加校验教程

AWS CLI：PutObject 参数说明

Amazon S3：CompleteMultipartUpload 响应与错误处理

Amazon S3：HeadObject 校验和与权限说明

十一、总结

文件校验的难点，不是调用一次 MD5 或 SHA-256，而是确认两边比较的是同一种东西。

ETag 不是通用的整文件摘要。分段组合校验和不等于整文件校验和。十六进制与 Base64 只是同一摘要的不同表达，也不能直接按字符串比较。

更重要的是，所有校验结果都应该绑定明确的对象身份与字节范围。没有版本约束，没有可信的预期摘要，没有清晰的校验类型，即使代码里写满了哈希计算，也可能只是在制造一种“已经验证过”的错觉。

可靠的文件校验，依赖明确的对象、算法、范围和证据，而不是依赖一个看起来像 MD5 的字符串。