Go语言标准库compress/lzw包仅处理字节流，不直接压缩文件内容，且要求输入字节满足特定约束。
Go语言标准库的 compress/lzw 包不支持直接压缩「文件内容」——它只处理字节流，且要求输入数据满足特定约束：每个字节必须 （通常为 <code>），但更重要的是，它**专为 GIF/TIFF 等二进制格式设计，不是通用文本或任意文件压缩工具**。盲目套用会导致解压失败、数据损坏或 panic。
为什么 compress/lzw 不能直接用于普通文件压缩
该包本质是协议级解码器，不是通用压缩器：
- 它假设输入符合 LZW 流格式（含 CLEAR、EOF 等控制码），而你读取的文件原始字节流不含这些
-
litWidth固定为 8（GIF 标准），但实际文件可能含任意字节（如 UTF-8 多字节序列），lzw.Writer会静默截断高位，导致解压后乱码 - 它不处理字典重置逻辑以外的错误恢复，遇到非预期字节序列（如随机二进制）极易触发
io.ErrUnexpectedEOF或 panic - 对纯文本压缩率远低于
compress/flate（即 gzip/zip 底层），且无 CRC 校验、无头部信息，无法安全传输或存储
lzw.Writer 和 lzw.Reader 的正确使用前提
仅在以下场景可用，且需严格匹配：
- 压缩端与解压端都明确约定
litWidth = 8和Order = lzw.LSB（GIF 常用）或lzw.MSB（TIFF 变体） - 输入数据本身已是「LZW-ready」格式，例如从 GIF 解码器拿到的原始像素索引流（0–255 范围内）
- 你正在实现 GIF 编码器或解析器，而非通用文件压缩工具
- 调用
Close()是必须的，否则末尾编码可能未刷出，解压时缺字节直接报io.ErrUnexpectedEOF
想压缩任意文件？改用 compress/flate 或 compress/gzip
这才是 Go 中处理文件内容压缩的实际路径：
立即学习“go语言免费学习笔记（深入）”；
-
compress/gzip：带 RFC 1952 头部，可直接用gzip.NewReader/gzip.NewWriter包裹文件句柄，兼容性最好 -
compress/flate：更轻量，无头部，适合嵌入协议或自定义容器；但需自行管理边界，解压时必须传入完整压缩块 - 二者都支持流式处理，内存可控，且对文本/二进制一视同仁；压缩比、速度、稳定性全面优于
lzw - 示例片段（gzip 压缩文件）：
src, _ := os.Open("input.txt") dst, _ := os.Create("input.txt.gz") gw := gzip.NewWriter(dst) io.Copy(gw, src) gw.Close() // 必须调用，否则尾部未写入
真正需要 LZW 的场合极少，基本只出现在图像格式兼容层或遗留协议对接中。把 compress/lzw 当作通用压缩工具，等于拿螺丝刀当锤子——能敲，但钉子弯了还找不到原因。
