Go flate 预置字典不一致为什么只在读取时失败

我们平时在Go中使用标准库flate处理带预置字典的压缩逻辑时，经常会遇到很反直觉的情况：两端预置字典内容不一致的时候，压缩写入流程全程跑通没有任何报错，只有到后续解压读取数据的时候才直接返回错误，不会提前在压缩阶段就暴露问题。

Go的flate实现设计上不会在压缩编码阶段校验预置字典和待写入数据的适配性，只有在解压侧执行霍夫曼解码、匹配字典映射关系的时候，发现位流解析结果不符合格式规则，才会抛出对应异常，因此预置字典不一致的问题只会在读取阶段触发错误。

直接答案：flate.NewReaderDict 返回的是一个惰性解压读取器。创建时只保存输入源并用字典初始化历史窗口，不会把 DEFLATE 流完整读完，也没有独立的字典一致性校验。因此，只有后续 Read、io.Copy 或 io.ReadAll 真正解析块并展开回溯引用时，问题才可能暴露。

还要注意：字典不一致不保证一定报错。若回溯位置在错误字典中仍然有效，解压可能顺利完成，却得到错误字节。

NewReaderDict 为什么不能提前判断

预置字典并不是普通前缀数据，而是解码器已经“读过”的历史窗口。压缩流中的长度和距离引用会回看这段历史。Go 官方文档明确要求压缩器与解压器预先约定同一字典；NewReaderDict 本身没有返回 error，也就不存在构造阶段的完整校验结果。

先把错误接在真正的读取位置

常见误判是只观察读取器创建是否成功，却忽略 io.Copy 的错误。正确做法是完整消费解压流，并分别处理读取和关闭错误。

func decode(dst io.Writer, src io.Reader, dict []byte) error {
    zr := flate.NewReaderDict(src, dict)

    // 真正的 DEFLATE 解析发生在 Copy 内部，字典问题在这里暴露。
    if _, err := io.Copy(dst, zr); err != nil {
        _ = zr.Close()
        return fmt.Errorf("解压数据: %w", err)
    }

    // Close 释放读取器资源，也应纳入调用方错误处理。
    if err := zr.Close(); err != nil {
        return fmt.Errorf("关闭解压器: %w", err)
    }
    return nil
}

为什么有时不报错但内容错了

raw DEFLATE 流并不替应用层保存“应该使用哪份业务字典”的可靠契约。错误字典若长度足够，距离引用仍可落在有效窗口内，解码器无法知道这些字节在业务上不正确。Go 官方示例甚至用替换后的字典展示：解压可以完成，但命中的字典片段会变成另一组字符。

线上修复要落在协议层

不要依靠“试着解压”猜字典。发送方应在 DEFLATE 数据之外携带字典 ID、版本或稳定哈希，接收方先查到完全匹配的字典，再创建读取器。升级字典时保留旧版本，直到历史数据和在途消息全部过期。

type Envelope struct {
    // DictID 是双方约定的稳定标识，不能用模糊名称代替。
    DictID string
    Body   []byte
}

func open(env Envelope, dictionaries map[string][]byte) ([]byte, error) {
    dict, ok := dictionaries[env.DictID]
    if !ok {
        return nil, fmt.Errorf("未知压缩字典: %s", env.DictID)
    }

    var out bytes.Buffer
    // 只有选中确定字典后才开始读取压缩流。
    if err := decode(&out, bytes.NewReader(env.Body), dict); err != nil {
        return nil, err
    }
    return out.Bytes(), nil
}

能否从 flate 流自动识别字典？
不要这样设计业务协议。应在外层帧、消息头或元数据中携带字典标识。

只检查 CorruptInputError 够吗？
不够。错误字典可能静默产出错误内容；关键数据还应有外层长度、校验和、签名或结构校验。