lz4解压比gzip快是因为其核心为查表+memcpy，无需huffman解码或滑动窗口状态维护，单核可达gb/s；但正因无数据完整性校验，帧头长度不符或字节缺失即直接返回io.errunexpectedeof，而gzip会报校验和错误。
别用 compress/gzip 或 compress/zlib 解大日志——LZ4 解压速度是它们的 3 倍以上，但必须按帧对齐、显式处理长度头，否则一读就 io.ErrUnexpectedEOF。
为什么 LZ4 解压比 gzip 快，却更容易出错？
LZ4 的解压核心是查表+memcpy，不依赖 Huffman 解码或滑动窗口状态维护，所以单核就能跑满 GB/s。但这也意味着它完全不校验数据完整性——只要输入字节流缺一个字节、或帧头长度声明和实际不符，lz4.NewReader 就会直接返回 io.ErrUnexpectedEOF，而不是像 gzip 那样报 zlib: invalid checksum。
常见错误现象：
- 日志文件是多个 LZ4 帧拼接（无分隔），但代码当成单帧读，第二帧开头被当作文本解析失败
- 协议规定前 4 字节是小端长度，但用
binary.Read(r, binary.LittleEndian, &n)后没检查n是否超出剩余缓冲区 - 用
io.Copy直接解压到bytes.Buffer，但源io.Reader实际只提供部分帧，导致解压中途卡住
用 pierrec/lz4 解压带长度头的日志流
标准库没有 LZ4 支持，必须用 github.com/pierrec/lz4。它提供 lz4.NewReader，但注意：它默认期望输入是完整 LZ4 帧（含魔数 0x184D2204），而很多日志系统（如 Filebeat + Logstash pipeline）发的是“裸 LZ4 数据”——即只有压缩体，没帧头。
实操要点：
- 若日志流是“长度头 + 裸 LZ4 数据”，跳过帧头校验：
lz4.NewReader(r, lz4.WithZeroFrame()) - 长度头必须提前读出并截断输入：
io.LimitReader(r, int64(length))，不能靠lz4.NewReader自己判断边界 - 每个日志块独立解压，不要复用同一个
lz4.Reader实例——它的内部状态（如字典、滑动窗口）不重置 - 解压失败时，
err可能是io.ErrUnexpectedEOF或lz4.ErrInvalid，二者需区别对待：前者大概率是长度头不准，后者才是数据损坏
批量并行解压日志字符串的 goroutine 安全写法
解压本身是 CPU 密集型，但 LZ4 的 Go 实现（pierrec/lz4）已做 asm 优化，单 goroutine 就能打满一个核。盲目开 100 个 goroutine 解压，并不会提速，反而因调度和内存分配拖慢整体吞吐。
真正该并行的是 I/O 和解压后的文本处理（如 JSON 解析、字段提取）：
- 用固定数量 worker（比如
runtime.NumCPU()）从 channel 拿待解压的[]byte（已含长度头） - 每个 worker 先剥离长度头 →
io.LimitReader→lz4.NewReader→io.ReadAll - 解压后结果立即发往下游 channel，由另一组 goroutine 做正则匹配或结构化解析
- 避免在解压 goroutine 里做
string(data)—— 日志文本可能含非法 UTF-8，应先用bytes.Equal或utf8.Valid判断再转
解压后字符串乱码或截断的三个隐蔽原因
不是 LZ4 算法问题，而是协议层没对齐：
- 发送方用了
lz4.CompressBlock（块模式），接收方却用lz4.NewReader（帧模式）——块模式无长度头，必须提前知道原始长度 - 日志文本原始编码是 GBK 或 Shift-JIS，但解压后直接当 UTF-8 处理——LZ4 不改编码，解压前后编码一致
- TCP 粘包导致多个长度头连在一起，第一个
binary.Read读出的n实际是第二个块的长度，后续解压必然失败
真正难的不是调 API，而是确认你手上的日志字节流，到底是“裸块”、“带帧头”还是“长度头+裸块”——这三种模式的解压入口函数、错误处理逻辑、buffer 分配策略全都不一样。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
