Go compress/flate 怎样用字典压缩重复前缀

Go compress/flate 可以用 flate.NewWriterDict 把共享前缀作为预置字典交给压缩器，再由 flate.NewReaderDict 使用同样的字典还原。字典不是额外写入正文的前缀，也不会作为正文从解压结果中返回。它让独立压缩流在刚开始时就有可引用的历史内容。

适合先考察的是大量格式相似、分别压缩的短记录，而不是把它当作所有数据的默认优化。下面给出最小配套写法，再说明传输、版本和收益判断。本例未执行，不提供实测压缩率或耗时。

先把共享前缀作为预置历史

例如每条业务记录都带有 service、region 和 kind 等稳定字段。即使每条记录都独立建流，也希望压缩器能利用这部分公共字节。预置字典提供的是“先前已有这些字节”的压缩历史，而非面向业务字段的语义词典。

此处的“重复前缀”指多条记录共同拥有的开头。它不要求先把前缀从每条记录中手工删除，也不是替换字段名的自定义编码协议。压缩输入仍然是完整 src，解压结果应与完整 src 一致。

按 Go 标准库字典接口文档，NewWriterDict 初始化压缩历史而不为字典本身输出压缩正文；与之配套的读取器也把字典视为已经读过的历史。这是调用契约，不是对压缩效果的保证。

压缩和还原使用同一份字典

下面的 encode 与 decode 使用同一份 dict。编码时必须完成 Close，不能仅以 Write 返回成功判断压缩数据完整；解码时检查读取错误并关闭读取器。示例选用 DefaultCompression，不额外引入压缩等级对比。

package main

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

// encode 为每条记录建立独立压缩流，并检查最终收尾错误。
func encode(src, dict []byte) ([]byte, error) {
    var dst bytes.Buffer
    w, err := flate.NewWriterDict(&dst, flate.DefaultCompression, dict)
    if err != nil {
        return nil, err
    }
    if _, err := w.Write(src); err != nil {
        _ = w.Close() // 写入已失败，丢弃这条压缩结果。
        return nil, err
    }
    if err := w.Close(); err != nil {
        return nil, err // 只有流收尾成功才能交付完整压缩数据。
    }
    return dst.Bytes(), nil
}

// decode 仅用于本例可信小数据；外部输入还应限制解压后的大小。
func decode(src, dict []byte) ([]byte, error) {
    r := flate.NewReaderDict(bytes.NewReader(src), dict)
    out, readErr := io.ReadAll(r)
    closeErr := r.Close()
    if readErr != nil {
        return nil, readErr
    }
    if closeErr != nil {
        return nil, closeErr
    }
    return out, nil
}

func main() {
    // 字典只包含公共、稳定的字段模板，两端必须保持字节一致。
    dict := []byte("service=ledger;region=east;kind=receipt;")
    src := []byte("service=ledger;region=east;kind=receipt;status=ready")
    packed, err := encode(src, dict)
    if err != nil {
        panic(err)
    }
    restored, err := decode(packed, dict)
    if err != nil {
        panic(err)
    }
    // 比较还原内容，不断言某个 Go 版本的具体压缩字节。
    fmt.Println("内容一致:", bytes.Equal(src, restored))
    fmt.Println("原文与压缩字节数:", len(src), len(packed))
}

读者运行后应关注“内容一致”是否为 true，以及本地实际输出的字节数；这里不填入猜测值。dict 中的模板应与真实输入有关，但不要放入私有凭据。示例 io.ReadAll 只适合已知可信的小对象，接入外部压缩数据时仍需单独约束解压后的数据量。

若需要无字典基线，可用相同输入、相同压缩等级的 NewWriter 建流，并同样在 Close 成功后取长度。不要拿没有收尾的缓冲区与完整压缩流比较。

短记录可能受益，但不能预设收益

潜在受益者是能够控制编码与解码两端、记录模式稳定、单条记录又不足以自行积累大量公共历史的应用。反过来，长流内部已经重复出现的内容可能不再明显受益；随机字节、已压缩数据或者与字典无关的记录，也不应预期有固定改善。

字典不负责业务分词，字段顺序、分隔符、大小写和实际字节分布都影响可复用性。先从可公开共享的字段模板收集候选，再用代表性样本选择，不要只拿专门为某一字典构造的记录证明它更好。

字典版本属于协议，不属于压缩正文

compress/flate 处理原始 DEFLATE 数据，不要把产物直接当成带其他封装的文件格式。NewReaderDict 不会自动从某个业务注册表下载字典。两端的字典字节必须匹配，字典版本不能只靠人记忆。

可以让外层协议保存字典标识，接收端用字典注册表把标识解析成字典字节，再构造 NewReaderDict。压缩流与外层字典标识是两类不同对象；更新字典时保留旧版本，直到旧数据不再需要还原。不要用同一个标识静默覆盖不同字节。

字典标识解决的是选择问题，不自动提供内容完整性或真实性。使用错误字典时，不能依赖“读取没有报错”就认定内容正确；可能出现解压失败，也可能出现错误内容。外层若需要完整性与来源保证，应由相应协议承担，不能借压缩器的错误检查替代。

按样本与总成本决定是否采用

采用路径可以很短：固定一组代表性记录，比较无字典和候选字典；确认内容往返一致；再决定是否把字典版本纳入协议。这里的检查是读者接入建议，并非本文声称完成的测试。

• 体积：记录完整压缩流长度，同时核算字典首次分发与长期保存的成本。
• 耗时和分配：在相同运行环境与等级下比较，避免仅以长度推断吞吐量。
• 兼容：保留旧字典还原旧数据，未知字典标识明确拒绝而非猜测。
• 稳定性：断言解压内容一致，不锁定压缩后的具体字节；官方不承诺不同 Go 版本产生完全相同的压缩字节。

字典会出现在解压结果开头吗？

不会。它是预置历史，不是本次正文，结果应仅包含传给 Write 的业务输入。

NewReader 可以自动猜到字典吗？

不能把猜测作为协议。使用字典压缩的数据，应安排对应的 NewReaderDict 与同一字典。

前缀很短也一定更省吗？

不一定。压缩流开销、实际匹配和字典分发成本都要一起衡量。小样本无收益时，保留简单的无字典方案可能更合适。

预置字典的价值是让独立流共享既定历史，代价是两端多了一项必须长期一致的协议依赖。先证明本业务的净收益，再引入字典版本管理，结论才有适用范围。