snappy.encode无法流式压缩大文件，因只接受[]byte且依赖随机访问滑动窗口；小文件需分块处理并手动管理块边界与元信息；真正流式场景应选zstd或gzip。
直接结论：用 snappy.Encode 压缩文件内容是可行的，但必须先读入内存；不能流式压缩大文件，否则会 OOM。
为什么不能直接对 *os.File 用 snappy.Encode？
snappy.Encode 只接受 []byte 类型输入，不接收 io.Reader 或文件句柄。它内部依赖随机访问滑动窗口（默认 32KB），无法边读边压——这和 gzip.Writer 的流式设计有本质区别。
- 试图传入
os.File会导致编译失败，因为类型不匹配 - 即使封装成
io.Reader并手动分块调用Encode，也无法保证块间重复数据被识别（Snappy 的重复查找跨块失效） - 官方
snappy包至今未提供Writer接口，这是有意为之的设计取舍
小文件（
典型场景：配置文件、日志片段、Protobuf 序列化后的小结构体。直接读全量 + 一次 Encode 最简单可靠。
- 用
ioutil.ReadFile（Go 1.16+ 推荐os.ReadFile）一次性加载 - 传给
snappy.Encode(nil, data)，让库自动分配目标缓冲区 - 如果反复压缩同规格小文件，可复用预分配的
[]byte避免 GC：例如snappy.Encode(make([]byte, 0, len(data)*1.2), data)
示例：
data, err := os.ReadFile("config.json")
if err != nil {
panic(err)
}
compressed := snappy.Encode(nil, data) // 自动扩容
os.WriteFile("config.snappy", compressed, 0644)
大文件（> 50MB）必须分块处理，但要注意陷阱
Snappy 本身不支持跨块去重，所以“分块压缩”本质是多个独立 Snappy 块拼接，不是单个逻辑流。解压时也必须按同样块大小逐段 Decode。
- 块大小建议设为 64KB～1MB：太小增加标签开销，太大削弱缓存局部性
- 不要用
bufio.Scanner按行切分——文本行长度不可控，破坏 Snappy 对齐假设 - 必须自己维护块边界：用
io.ReadFull或循环Read确保每次读满指定字节数（最后一块除外） - 压缩后需额外存储块元信息（如每块原始长度），否则解压时无法还原
关键点：这不是标准 Snappy 流格式，snappy.Decode 无法直接解压整个拼接文件，必须按块调用。
真正需要流式压缩时，别硬刚 snappy-go
如果你的场景明确要求“打开文件就压、边读边发、不限大小”，snappy-go 不是合适选择。它的定位就是低延迟、内存可控的批处理压缩。
- 替代方案一：改用
zstd（如github.com/klauspost/compress/zstd），它提供完整的zstd.Encoder流接口，且速度接近 Snappy - 替代方案二：用
gzip+gzip.BestSpeed，虽然比 Snappy 慢 3–5 倍，但原生支持流式且兼容性无敌 - 替代方案三：自己封装
snappy分块逻辑，但要承担协议设计成本（比如加 magic header、块头校验、长度字段）
最容易被忽略的一点：Snappy 压缩后可能比原文还大——尤其是随机噪声数据（如加密内容、已压缩图片）。上线前务必在真实数据上测压缩率，别只看文档里的“平均值”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
