小数据指规模较小、结构清晰、易于处理和分析的数据集，通常用于特定场景下的精准决策与个性化服务。
小数据（gzip，它压缩后可能反而变大；高频低延迟服务优先选 snappy；想兼顾压缩率和速度，zstd 是当前最稳的选择——但必须手动注册，否则直接报错 compressor not registered。
小数据压不动 gzip，不是参数问题，是算法本身限制
gzip 基于 deflate，头部固定开销约 18–30 字节。100 字节的 JSON 压完常变成 120 字节，flate.BestSpeed 或调 gzip.Level 都无法绕过这个硬伤。
- 实测：2KB protobuf 消息，
gzip压缩后体积仅减少 12%，耗时却达 80–150μs；snappy同样输入，体积减 28%，耗时稳定在 ~5μs - 场景判断：API 响应体平均 gzip
- 替代方案：改用
snappy（解压快）或zstd（header 更小，1KB 消息下 header 仅 4 字节）
gRPC 里启用 zstd 必须双注册，漏一个就解压失败
zstd 不是 gRPC 默认支持的编码器，grpc.UseCompressor("zstd") 会直接 panic：compressor not registered。
- 必须同时注册
grpc.RPCCompressor和grpc.RPCDecompressor，顺序无关，缺一不可 - 别用
zstd.Compressor{}—— 这是旧版 API，新版要求实现encoding.Compressor接口 - 推荐写法：
zstdCompressor, _ := zstd.NewWriter(nil) s := grpc.NewServer( grpc.RPCCompressor(grpc.NewCompressor("zstd", zstdCompressor, zstd.Decompressor{})), ) - 客户端也要配
grpc.WithCompressor(grpc.NewCompressor("zstd", ...))，否则服务端即使支持也返回未压缩数据
snappy 在 Kafka / NATS / Sarama 中默认可用，但 framing 模式要对齐
kafka-go、nats.go、Sarama 都原生支持 snappy，无需额外注册，但要注意 framing 兼容性。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- kafka-go 的
snappy.NewCompressionCodec()默认用标准 framing；若对接 Java 客户端，得换snappy.NewCompressionCodecFraming(snappy.Raw) - nats.go 的
SnappyEncoder直接调snappy.Encode()，不加 framing，适合内部服务间通信 - Sarama 的
CompressionSnappy使用标准 framing，与 kafka-go 默认 codec 兼容 - 错误现象：消费者解压失败、日志报
invalid snappy stream→ 八成是 framing 模式不一致
zstd 解码器必须复用，每次 new 是性能黑洞
zstd.NewReader() 内部会重建状态机和哈希表，频繁调用会导致大量内存分配和 GC 压力。
- 典型反模式：
zstd.NewReader(resp.Body)写在 HTTP handler 里，QPS 上千时 CPU 热点全在runtime.mallocgc - 正确做法：用
sync.Pool复用解码器var zstdDecoderPool = sync.Pool{ New: func() interface{} { return zstd.NewReader(nil) }, } // 使用时 reader := zstdDecoderPool.Get().(*zstd.Decoder) defer zstdDecoderPool.Put(reader) decoded, _ := reader.DecodeAll(data, nil) - 压缩端同理：
zstd.NewWriter()也建议池化，尤其在高并发写入日志或消息体时
zstd 的压缩级别调太激进（比如 ZSTD_BEST_SPEED）反而降低小数据吞吐，而 snappy 的 zero-copy 特性在内存受限环境容易被忽略——它不修改原始字节，但要求输入 buffer 生命周期覆盖整个解压过程。
