Go compress/flate 怎样用 HuffmanOnly 处理文本压缩

如果文本中有大量重复字节，又希望压缩过程尽量少做匹配搜索，可以考虑 compress/flate 的 HuffmanOnly。它对应压缩级别 -2，只进行 Huffman 熵编码，不做 LZ 匹配搜索，因此通常更偏向吞吐和较低的 CPU 负担，而不是追求最小结果。

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

先记住一个判断：HuffmanOnly 不承诺“输入变小”。它适合先用实际样本比较速度、结果大小和可逆性；对已经压缩或字节分布接近随机的数据，结果可能没有收益，甚至变大。

先看 HuffmanOnly 到底改变了什么

flate.NewWriter 的第二个参数是压缩级别，允许的范围是 -2 到 9。其中 flate.HuffmanOnly 是 -2，文档明确说明它只使用 Huffman 压缩；普通级别还会寻找重复片段，用长度和距离引用已经出现过的内容。

因此，文本压缩前先检查三个现象：

• 内容是否存在明显的高频字节，例如重复的空格、标点、字段名或固定模板。
• 数据是否已经经过 gzip、zlib、Snappy、LZ4 等压缩；重复结构已经被前一层处理后，HuffmanOnly 的空间会变小。
• 调用方更在意吞吐和延迟，还是更在意传输字节数；二者不能只靠压缩级别名称判断。

压缩文本时先把 Writer 生命周期写完整

最容易遗漏的地方不是级别常量，而是 Close。写入完成后必须关闭 flate Writer，让它把尚未输出的块和结束信息写到底层缓冲区。示例把压缩结果留在内存中，便于后面解压比较；真实项目可以把 bytes.Buffer 换成文件或网络写入器。

package main

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

func compressText(src []byte) ([]byte, error) {
    var dst bytes.Buffer

    // -2 表示只做 Huffman 编码，不做 LZ 重复片段搜索。
    writer, err := flate.NewWriter(&dst, flate.HuffmanOnly)
    if err != nil {
        return nil, fmt.Errorf("创建 flate writer 失败: %w", err)
    }

    // Write 返回已接受的字节数；短写要按错误处理，避免静默丢数据。
    n, err := writer.Write(src)
    if err != nil {
        _ = writer.Close()
        return nil, fmt.Errorf("写入待压缩文本失败: %w", err)
    }
    if n != len(src) {
        _ = writer.Close()
        return nil, io.ErrShortWrite
    }

    // Close 会刷新末尾数据并写出 DEFLATE 结束块，不能省略。
    if err := writer.Close(); err != nil {
        return nil, fmt.Errorf("关闭 flate writer 失败: %w", err)
    }
    return dst.Bytes(), nil
}

func main() {
    source := []byte("status=ok;service=order;status=ok;service=order;\n")
    compressed, err := compressText(source)
    if err != nil {
        panic(err)
    }
    fmt.Printf("原文=%d 字节，压缩后=%d 字节\n", len(source), len(compressed))
}

这里的 HuffmanOnly 不是“最高压缩级别”，也不是 BestSpeed 的别名。BestSpeed 仍然属于带 LZ 匹配策略的级别，只是更偏向速度；两者的压缩路径不同。

压缩结果要用解压回读确认

看见输出字节数变小，只能说明这次样本占用更少，不能证明链路正确。把压缩结果交给 flate.NewReader 解压，再与原文比较，可以同时确认 Writer 已经关闭、数据没有截断、读取端能够消费完整 DEFLATE 流。

func roundTrip(source []byte) error {
    compressed, err := compressText(source)
    if err != nil {
        return err
    }

    // Reader 只负责解压；用 defer 兜底关闭，避免未来改成文件或网络源时遗漏资源。
    reader := flate.NewReader(bytes.NewReader(compressed))
    defer reader.Close()

    restored, err := io.ReadAll(reader)
    if err != nil {
        return fmt.Errorf("读取解压结果失败: %w", err)
    }
    if !bytes.Equal(restored, source) {
        return fmt.Errorf("解压结果与原文不一致")
    }

    // 一致性检查通过后再记录压缩比，不把大小变化误当成正确性证明。
    fmt.Printf("round-trip ok: source=%d compressed=%d\n", len(source), len(compressed))
    return nil
}

如果真实场景是流式处理，不要为了比较而一次性把所有数据读进内存；可以让 flate.NewReader 接在文件或网络流上，再按块读取。文章示例使用 io.ReadAll 只是为了把正确性边界写得清楚。

出现“压缩后更大”时按输入特征排查

HuffmanOnly 的核心依据是符号出现频率。若每个字节的分布都比较平均，或者原始内容很短，编码表和 DEFLATE 块本身的开销可能抵消收益；这不是 API 失效。

上线前用这份清单做反向确认

1. 级别是否明确写成 flate.HuffmanOnly，并且团队知道它等价于 -2 而不是“最高压缩率”。
2. 是否记录了原文大小、压缩后大小、耗时和样本类型，而不是只观察一次结果。
3. 写入错误、短写和 Close 错误是否都能返回到调用方。
4. 解压端是否能完整读回；流式场景是否有明确的 Reader 关闭责任。
5. 对于已压缩、近似随机或很短的数据，是否有跳过压缩或切换级别的策略。

最终选择可以很简单：如果重复文本让 HuffmanOnly 在真实样本上带来可接受的体积收益，同时压缩耗时明显符合预算，就保留它；如果主要目标是尽量减少传输字节数，应把它和默认级别、BestSpeed 放在同一组样本上对照，而不是只凭名字决定。

相关问题

• HuffmanOnly 和 BestSpeed 有什么区别？ 前者只做 Huffman 编码，后者仍会进行 LZ 匹配，只是策略更偏速度。
• 为什么必须调用 Close？ Writer 可能还有缓冲数据和结束块没有写到底层输出。
• 短字符串是否一定适合压缩？ 不一定，编码与块开销可能超过收益，应按样本设置策略。
• 压缩后更大是不是错误？ 不一定，这是输入分布和元数据开销共同作用的结果。