Go flate HuffmanOnly 为什么文件可能比原数据更大

flate.HuffmanOnly 变大并不反常。这个模式禁用 Lempel-Ziv 重复串搜索，只做 Huffman 熵编码；只有部分字节明显比其他字节更常出现时，短码收益才容易覆盖 DEFLATE 块、码表、对齐和结束标记等开销。输入很短、字节频率接近均匀，或已经做过高效熵编码时，总输出就可能比原数据更大。

根因一：没有 LZ 重复串匹配，只剩字节频率

常规 DEFLATE 会把重复字符串表示为“距离 + 长度”，再对符号做熵编码。HuffmanOnly 跳过前一部分，因此像重复 JSON 字段、长段相同文本这样的结构不会被转换成回溯引用。它关注的是单个字节出现频率：少数符号占比高时可分配短码，分布越均匀，平均码长越难明显低于原始 8 位。

官方给出的典型用途，是数据已经经过 Snappy、LZ4 这类 LZ 风格压缩、但还缺少熵编码，并且输出字节仍有频率偏斜。若输入已经是 JPEG、PNG、ZIP、常规 DEFLATE、加密结果或高质量随机数据，再套 HuffmanOnly 通常很难获益。

根因二：短块和 Flush 把固定开销放大

即使编码后的数据部分略有缩小，完整 DEFLATE 流仍要表达块类型、结束位置和必要的编码信息。对几十字节的小消息，这些固定成本占比很高。若每条消息都新建并关闭一个 Writer，相当于为每条消息单独承担流边界开销。

Flush 也不是免费操作。Go 文档说明，即使没有待写数据，调用 Flush 仍会发出至少 4 字节的同步标记。低延迟协议如果每写一小段就 Flush，累积后的标记可能比 Huffman 节省的空间更多。

不要猜压缩率，直接比较业务样本

下面函数返回完整 DEFLATE 输出长度，可用同一批输入比较 HuffmanOnly、BestSpeed 和 DefaultCompression。不要断言某个模式在所有数据上都最好，也不要在测试里依赖精确压缩字节；官方明确说明具体输出字节不属于 Go 1 兼容承诺。

package ratio

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

func CompressedSize(data []byte, level int) (int, error) {
	var dst bytes.Buffer
	zw, err := flate.NewWriter(&dst, level)
	if err != nil {
		return 0, fmt.Errorf("创建压缩器失败: %w", err)
	}

	// 一次写入完整样本，避免把额外 Flush 标记混入模式比较。
	if _, err := zw.Write(data); err != nil {
		_ = zw.Close()
		return 0, fmt.Errorf("写入压缩器失败: %w", err)
	}
	// Close 会写完剩余数据和流结束信息，必须计入最终大小。
	if err := zw.Close(); err != nil {
		return 0, fmt.Errorf("关闭压缩器失败: %w", err)
	}

	return dst.Len(), nil
}

func Compare(data []byte) error {
	levels := []int{
		flate.HuffmanOnly,
		flate.BestSpeed,
		flate.DefaultCompression,
	}
	for _, level := range levels {
		size, err := CompressedSize(data, level)
		if err != nil {
			return err
		}
		// 输出总字节数供基准或监控采集，不把示例值写死。
		fmt.Printf("level=%d input=%d output=%d\n", level, len(data), size)
	}
	return nil
}

样本应覆盖真实消息长度分布，而不是只测一段大文本。除了总输出大小，还要记录吞吐、CPU 时间、分配次数和端到端延迟；HuffmanOnly 的价值常常是更快，而不是最高压缩率。

按数据特征选择处理策略

如果协议要求每条消息独立解压，就必须接受独立流的边界成本；不要为了压缩率破坏消息隔离。若可以保持一条连续压缩流，减少 Writer 重建和无意义 Flush 往往比微调 Huffman 参数更有效。

常见问题

HuffmanOnly 输出变大说明数据损坏了吗？

不是。它仍生成符合 RFC 1951 的 DEFLATE 数据，变大只说明编码收益没有覆盖格式和分块开销。能否正确解压与压缩率高低是两件事。

可以用“输出必须小于输入”作为单元测试吗？

不建议。应测试往返解压后数据一致，并在基准或容量测试中观察代表性样本的统计分布；具体压缩字节和大小可能随实现改进而变化。