Go compress/zlib 怎样根据 zlib 字典解压输入

Go 解压使用预置字典的 zlib 输入，应调用 zlib.NewReaderDict(src, dict)，将发送端约定的字典字节传入。输入要求的字典与提供值不匹配时会返回 zlib.ErrDictionary；输入没有引用预置字典时，这个参数会被忽略。创建读取器成功后，还必须继续读取并处理数据错误，不能直接认定整个消息已解压成功。

官方文档：https://pkg.go.dev/compress/zlib

遇到字典错误，我会先分清失败发生在哪一层

假设一个小型消息接收器拿到 zlib 数据，改用普通 NewReader 后却遇到字典错误。我会先检查发送端是否启用了预置字典，而不是直接把输入当成损坏文件。这里是接口设计场景，不是亲历线上故障；下文代码和预期均未实际运行。

排查的顺序可以是：确认外层格式确实为 zlib，确认双方字典版本，再区分“创建读取器失败”和“读取正文失败”。这不是带实测时间戳的事故时间线，而是对处理阶段的拆分。gzip、ZIP 和裸 DEFLATE 不应混用 zlib 读取器来试错。

字典是双方共享的字节，不是解压器自动找出的文本

预置字典为压缩器提供已知内容，解压方必须具备匹配的字典。zlib 流中的字典标识不是整份字典。Go 读取实现会在流声明使用字典时，比对字典的 Adler-32 校验值；不会凭标识自动下载字典，也不会从压缩消息反推出原字典。

如果我要在服务间使用它，会将字典作为协议资产明确版本与来源，而不是用“内容看起来相同”判断。文本换行、尾部空格、编码或字节顺序不同，都可能导致不一致。Adler-32 也不是密码学身份认证；协议仍需自己的可信配置和版本约定。

一个带输出上限的小消息解压例子

下面先用同一字典生成内存样本，再调用 decodeSmall 解压并比较内容。代码不依赖压缩后的固定字节序列，也不承诺某个压缩率。1MiB 是示例的小消息策略，不是 zlib API 的固有限制。

package main

import (
    "bytes"
    "compress/zlib"
    "errors"
    "fmt"
    "io"
)

// decodeSmall 仅处理解压后不超过1MiB的小消息，失败时不返回部分数据。
func decodeSmall(src io.Reader, dict []byte) (out []byte, err error) {
    zr, err := zlib.NewReaderDict(src, dict)
    if err != nil {
        return nil, fmt.Errorf("创建zlib读取器: %w", err)
    }
    defer func() {
        // 关闭读取器不负责关闭src，也不能代替读到流末尾。
        if closeErr := zr.Close(); err == nil && closeErr != nil {
            out = nil
            err = fmt.Errorf("关闭zlib读取器: %w", closeErr)
        }
    }()

    const maxOutput = 1  maxOutput {
        return nil, fmt.Errorf("解压结果超过1MiB上限")
    }
    return data, nil
}

func run() error {
    // 字典按字节约定；换行、空格或编码变化都会改变字典。
    dict := []byte("record:region=;status=;count=;")
    plain := []byte("record:region=east;status=ready;count=12;")
    var compressed bytes.Buffer
    zw, err := zlib.NewWriterLevelDict(&compressed, zlib.DefaultCompression, dict)
    if err != nil {
        return err
    }
    if _, err := zw.Write(plain); err != nil {
        _ = zw.Close() // 出错后释放资源，保留原始写入错误。
        return fmt.Errorf("压缩写入: %w", err)
    }
    if err := zw.Close(); err != nil {
        return fmt.Errorf("压缩收尾: %w", err)
    }

    // 使用独立reader；若要重试，也应从完整压缩数据起点重新创建。
    out, err := decodeSmall(bytes.NewReader(compressed.Bytes()), dict)
    if err != nil {
        if errors.Is(err, zlib.ErrDictionary) {
            return fmt.Errorf("需提供发送端约定的字典: %w", err)
        }
        return err
    }
    if !bytes.Equal(out, plain) {
        return fmt.Errorf("往返内容不一致")
    }
    fmt.Printf("内容=%q\n", out)
    return nil
}

func main() {
    // 本例没有创建文件或网络连接；仅演示内存数据往返。
    if err := run(); err != nil {
        fmt.Println("处理失败:", err)
    }
}

读者可保存为 main.go 自行运行。预期返回的内容与 plain 一致；本文没有运行记录，不将打印语句描述成已发生的结果。压缩端 Close 必须完成后才消费最终数据，它负责收尾，不只是可省略的清理。

解压端最多收集上限加一个字节。一旦超过上限，函数返回错误并丢弃本次结果；输出未超限时，读取器被完整消费，正常末尾及校验才有机会被确认。io.ReadAll 返回 nil 错误只是这个辅助函数的一部分判断，还必须结合长度上限，因为 LimitReader 自己也会产生 EOF。

更换字典后重试，不能沿用已经消费的输入位置

NewReaderDict 在初始化时已经读取头部和字典标识。若字典不匹配，不能简单把同一个已经前进的 src 再传一次，期待它自动回到消息起点。示例使用 bytes.NewReader，是为了每次从保存好的完整消息字节重新创建读取视图。

在网络流上，不应靠不断猜字典反复消费输入；先由协议元数据选择字典，再解码对应的有界消息。没有消息边界时，“重试一遍”很可能连下一条数据也影响到。本文不实现字典猜测，也不扩展自动回退协议。

还要区分资源所有权：关闭 zlib reader 不会关闭调用方传入的底层文件或连接；文件和连接由创建它们的代码管理。示例只有内存 reader，不涉及底层文件关闭。

读到前半段和调用 Close，都不等于完成校验

我更在意的不是“能不能输出几个字符”，而是调用方什么时候接受结果。zlib 的数据校验需要完整消费到流末尾；只读一个前缀就 Close，不会替你把剩余正文读完并确认校验。

这也是 decodeSmall 在错误时返回 nil 数据的原因。若直接流式写入业务目标，读取器最后才报错时，目标中可能已有部分内容；需要另外设计暂存与提交机制。输出上限可以约束本例的内存结果规模，但不能替代网络超时、输入大小限制、CPU预算或来源可信策略。

读取行为参考：https://go.dev/src/compress/zlib/reader.go

上线前，给字典配置和错误类别各留一个位置

对已明确采用预置字典的协议，我会保留字典版本、消息格式和解压结果上限；记录错误类别而不把字典正文或消息明文随意放进日志。以下是可自行复现的预期对照，不是已执行测试报告：

NewReaderDict 能读取没有字典的 zlib 流吗？

可以，官方文档说明输入不引用字典时会忽略传入字典；这不意味着它可以自动识别任意压缩格式。

拿到字典标识就能还原字典吗？

不能。标识用于匹配约定，不携带完整字典内容，应由发送端协议或可信配置提供对应字节。

为什么不直接使用无限制 io.ReadAll？

因为压缩输入可能展开为远大于预期的数据。本例限定小消息输出；更大数据需要不同的存储及提交策略，而不是去掉所有限制。

对我来说，字典解压最重要的约定有三项：字典字节由谁提供、失败是否保留部分结果、何时算完整接收成功。NewReaderDict 解决初始化的字典问题，读取到末尾和完整错误处理解决结果是否可接受的问题，两者不能相互替代。