Go compress/flate 为什么同一输入的压缩字节会变化

先给结论：compress/flate 的“同一输入”只说明原始字节相同，并不能保证压缩字节相同。压缩级别、预置字典、是否调用 Flush、写入边界以及 Go 版本都会影响编码环境；其中 Go 官方文档还明确说明，写入的精确字节不在 Go 1 兼容承诺内。

如果结果用于解压传输，优先比较解压后的内容；如果结果必须做签名、内容寻址或字节级快照，就要把压缩参数、写入方式和工具链一起固定。

背景：DEFLATE 允许多种合法表示

compress/flate 实现的是 DEFLATE 格式，同一段原文可以用不同的匹配选择、Huffman 编码和块边界表示。只要解码后得到同样的原始字节，两个压缩流都可以是正确结果。因此，压缩率和解压内容是功能目标，压缩后的逐字节相等是额外的工程约束。

官方地址：https://pkg.go.dev/compress/flate@go1.27.3

所以先不要把“哈希不一样”直接当成数据错误。若接收端能正常解压并得到相同内容，差异可能只是编码选择变化。真正需要排查的是：两次是否使用了同一个 level、同一个字典、同一种写入与刷新方式，以及同一套 Go 实现。

旧写法的问题：只固定输入，没有固定编码条件

最常见的误区是只保存一份 []byte，然后假设下面的压缩函数天然具备跨环境字节稳定性。实际上 NewWriter 会接收 level，NewWriterDict 还会把字典作为编码状态的一部分。字典一旦变化，即使正文不变，压缩结果也可能变化；读取时也必须使用同一字典。

package main

import (
    "bytes"
    "compress/flate"
    "fmt"
    "log"
)

// encode 使用显式 level，避免调用方在不同位置使用不同默认值。
func encode(src []byte, level int) ([]byte, error) {
    var dst bytes.Buffer
    zw, err := flate.NewWriter(&dst, level)
    if err != nil {
        return nil, err
    }
    // 一次写入完整输入，示例不把 Flush 当成普通结束操作。
    if _, err := zw.Write(src); err != nil {
        return nil, err
    }
    // Close 会完成最后的压缩块，必须处理它可能返回的底层写错误。
    if err := zw.Close(); err != nil {
        return nil, err
    }
    return dst.Bytes(), nil
}

func main() {
    src := []byte("same input does not mean same encoding contract")
    a, err := encode(src, flate.DefaultCompression)
    if err != nil {
        log.Fatal(err)
    }
    b, err := encode(src, flate.BestSpeed)
    if err != nil {
        log.Fatal(err)
    }
    // 这里只比较长度来说明 level 是编码条件，不把输出数字当作固定事实。
    fmt.Println(len(a), len(b))
}

这段示例的重点不是哪个 level 更好，而是把它从隐含状态变成调用契约。DefaultCompression、BestSpeed 和 BestCompression 代表不同取舍；若压缩字节要稳定，必须固定具体值，而不是让不同调用点自行选择。

新规则：把输入、字典和 Flush 边界一起记录

Flush 适合需要让网络接收端及时拿到当前数据的压缩协议，但它会写出同步标记；调用次数和位置进入压缩流后，字节级结果自然可能不同。把“每写一段就 Flush”与“一次写完再 Close”混用，是快照比较失败的常见来源。

如果业务确实要分段发送，应把分段和 Flush 作为协议的一部分，并在协议版本中固定；如果目标是稳定快照，则让编码函数接收完整输入，统一一次性写入，最后只调用 Close。Reset 只复用已分配的 writer 状态，不会把压缩结果变成跨版本格式承诺。

还要区分“同一次进程内的重复编码”和“跨 Go 版本的重复编码”。同一版本、同一参数和同一写入约束通常更容易复现；但官方文档明确提醒，精确写出字节不受 Go 1 兼容保证。升级工具链后，不能仅凭旧快照失败就判定新压缩器错误。

兼容注意：什么时候应该比较解压内容

传输、缓存和归档通常只需要接收端成功解压；这类场景应校验解压后的内容哈希，或者校验“解压内容哈希 + 编码契约版本”。若是签名、内容寻址、去重键或 golden 文件确实要求压缩字节不变，就固定 Go 版本、level、字典、输入字节归一化规则和 Flush 约定，并把它们写进构建说明。

不要用“把 level 调到最高”解决稳定性问题。更高 level 主要改变速度与压缩效率，并没有把未来版本的实现锁死；也不要把压缩后的字节直接当作跨语言唯一规范，除非双方明确约定相同的 DEFLATE 编码策略。

采用清单与相关问题

• 原始输入是否先完成换行、字段顺序和空白归一化？
• 是否明确记录 level、字典内容和字典版本？
• 是否禁止快照路径中的中途 Flush，并统一由 Close 收尾？
• 跨 Go 版本比较时，是否改为比较解压结果或固定构建镜像？

为什么只改写入次数也可能影响结果？如果写入过程中穿插了 Flush，它会改变流中的同步边界；如果只是把同一字节分成多次 Write 且不改变刷新和结束条件，应把重点放回 level、字典与实现版本，而不要把所有差异都归因于分片。

压缩结果不同是否说明解压失败？不是。DEFLATE 允许多个合法编码。要判断正确性，应让接收端解压并比较原始字节；只有解压失败或内容不一致，才是数据链路问题。

官方资料：https://pkg.go.dev/compress/flate@go1.27.3、https://go.dev/src/compress/flate/。本文示例用于解释编码契约，未把示例输出冒充为运行证据。