Go compress/flate 升级 Go 后 ZIP 字节校验失败怎么办

先看失败的是“整个 ZIP 的哈希与旧快照不同”，还是解压时报 checksum error。Go 1.27 调整了 compress/flate 编码器，官方明确说明压缩输出可能与 Go 1.26 不同，使用 DEFLATE 的 ZIP 也可能随之变化。字节不同不自动等于损坏，但真正的读取错误和内容差异也不能靠更新快照跳过。

Go 官方地址：https://go.dev/。下面按输入、归档结构和内容三层说明判断方法，并给出原创测试示例。示例未在本文环境运行，不提供虚构的升级前后哈希、压缩率或性能结果。

先把“校验失败”拆成三类

SHA-256、ZIP 内部 CRC 和业务断言承担不同责任。一个测试若只想证明“导出的工单文本没有丢失”，却比较整个 ZIP 的固定字节，就把压缩实现也写进了业务契约。反过来，下载验证本来就要确认发布产物的完整字节，不能随意改成只比较解压内容。

分层检查：输入、元数据与压缩器分别看

第一层记录输入成员：名称、内容、数量和写入顺序。不要让文件遍历次序或未排序的 map 影响构建，再把所有差异归因于工具链。

第二层比较归档头：时间戳、权限、注释、Extra、压缩方法以及成员顺序。ZIP 不只是压缩后的文件内容，头字段和中央目录同样属于最终字节。可复现构建需要有意识地固定这些输入。

第三层才是压缩器：确认使用的是 Deflate，是否注册了自定义压缩器，压缩级别和工具链是否变化。如果成员使用 Store，就不经过 DEFLATE 压缩；此时不能直接拿 flate 的版本变化解释它的全部差异。

哪些证据支持“只是表示方式变化”

可供项目排查的证据包括：两份归档都能完整读取、成员集合符合要求、解压字节一致、约定的元数据一致，而压缩表示不同。结合 Go 1.27 的发布说明，这支持压缩实现变化这一解释，但不能仅凭“刚升级过 Go”下结论。

若实际出现 zip.ErrChecksum、意外 EOF、缺少成员或读取出的负载不同，应保留原产物，继续检查写入和传输错误。尤其确认 zip.Writer.Close 的错误有没有处理；它会完成中央目录，不能在关闭归档前就把缓冲区当成最终产物。底层文件或流还要由拥有者负责关闭和处理错误。

业务测试可以改成成员级断言

下面测试生成一个受控的单成员归档，然后检查数量、名称、压缩方法和内容，不再要求 ZIP 与旧工具链的整包字节相等。它给的是测试结构，不是已经确认当前项目没问题的证明。

package archivecase

import (
    "archive/zip"
    "bytes"
    "io"
    "testing"
)

// TestZipPayload 验证受控的小型归档内容，不绑定压缩器的具体输出字节。
func TestZipPayload(t *testing.T) {
    want := []byte("工单: ready\n")
    var buffer bytes.Buffer
    writer := zip.NewWriter(&buffer)
    entry, err := writer.Create("ticket.txt")
    if err != nil {
        t.Fatal(err)
    }
    if _, err := entry.Write(want); err != nil {
        t.Fatal(err)
    }
    // Close 写入中央目录；必须完成归档后才能读取。
    if err := writer.Close(); err != nil {
        t.Fatal(err)
    }

    reader, err := zip.NewReader(bytes.NewReader(buffer.Bytes()), int64(buffer.Len()))
    if err != nil {
        t.Fatal(err)
    }
    if len(reader.File) != 1 || reader.File[0].Name != "ticket.txt" {
        t.Fatal("归档成员集合不符合预期")
    }
    file := reader.File[0]
    if file.Method != zip.Deflate {
        t.Fatal("压缩方法不符合预期")
    }
    stream, err := file.Open()
    if err != nil {
        t.Fatal(err)
    }
    // 此处仅针对自己刚生成的小样本，读至末尾以暴露读取及校验错误。
    got, readErr := io.ReadAll(stream)
    closeErr := stream.Close()
    if readErr != nil {
        t.Fatal(readErr)
    }
    if closeErr != nil {
        t.Fatal(closeErr)
    }
    if !bytes.Equal(got, want) {
        t.Fatal("解压后的成员内容发生变化")
    }
}

这里要完整读取成员并检查错误，而不是只读几个字节或只打开文件。测试样本由代码自身生成且很小，所以用 io.ReadAll 简化表达；面对外部、不可信或很大的 ZIP，应另外限制成员数量、总解压体积和单项读取量，不能把这个测试助手直接当作生产解压器。

真实导出包若包含多个成员，测试应比较完整成员集合，明确重复名称的处理规则，并逐项检查内容。权限、顺序或注释若是对外契约，也应增加相应断言；“改为语义测试”不意味着只检查任意一个文件就算通过。

反向确认：别让新测试变得过于宽松

调整测试后，建议项目加入三类负例：预期名称写错、成员负载改变、归档被截断。它们应让相应断言或读取失败。对于明确可控的坏校验样本，也应保证读取错误能被上报。本文只列出回归建议，不执行或声称这些负例已经通过。

若交付协议要求跨构建复用同一签名或内容地址，则整包字节本身就是契约。需要固定工具链、压缩设置、元数据和写入顺序，并维护可复现构建流程；仅固定压缩级别或时间戳，不能保证跨 Go 版本的 DEFLATE 字节不变。

正式发布时仍应针对最终封存的 ZIP 计算哈希并签名。消费者验证下载到的就是那一份已发布产物。重新压缩得到的新字节即使内容相同，也不是旧签名所绑定的旧产物，不能把旧摘要继续沿用。

修复前的清单

• 确认错误来自整包快照、成员读取还是内容比较，保留原始失败材料。
• 检查输入成员、元数据、压缩方法与写入顺序，再比较编码器版本。
• 业务测试按实际契约断言，明确 Close 与读取错误处理。
• 若要求字节级复现，固定构建链路而不是盲目刷新基准。
• 最终产物哈希继续服务发布完整性，与成员级测试分开维护。

统一设为 BestCompression 能恢复旧 ZIP 字节吗？

不能据此保证。压缩级别是策略参数，不是指定旧版编码实现；相同级别也不意味着不同工具链输出完全相同。

把 ZIP 哈希换成原文件哈希就够了吗？

要看目的。内容测试可以逐成员比较负载或内容摘要，同时比较成员名和所需元数据；下载校验和签名则仍要绑定最终归档字节。不要用单个原文件摘要代替整个发布包的完整性契约。

结论是先定位比较层次，再决定修复方式。Go 1.27 的编码变化为字节差异提供了明确背景，但只有正确处理归档错误、成员集合与负载，才能避免把真实损坏一起“修复”掉。

参考：Go 1.27 flate 变更、ZIP 读写与错误接口、DEFLATE 压缩器文档。