Avro不是压缩格式，而是带schema的二进制序列化协议；其体积小源于schema复用与紧凑编码（如省略字段名、变长整数、null省略），非内置gzip类压缩，高压缩需额外套zlib/gzip，且goavro2是当前最稳定库，支持Avro 1.11、schema registry及清晰错误提示。
Avro 不是压缩格式，而是带 schema 的二进制序列化协议
很多人误以为 Avro 本身能“高压缩”，其实它不内置压缩算法；它的体积小，主要靠 schema 复用 + 二进制紧凑编码（比如省略字段名、变长整数、null 省略等），不是 gzip 那种通用压缩。真正要“高压缩率”，得在 Avro 序列化后**再套一层 zlib 或 gzip**——但必须注意协议层对齐和流式兼容性。
goavro2 是当前最稳定的 Avro 库，别用 google/avro/v1beta1
google/avro/v1beta1 已归档、无维护，且 API 设计与 Avro 规范有偏差（比如不支持 union 类型的 runtime 解析）。生产环境应选 github.com/hamba/avro/v2（简称 goavro2），它完整支持 Avro 1.11 schema 语法、支持 schema registry 兼容模式、错误提示清晰。
- 安装：
go get github.com/hamba/avro/v2 - schema 必须提前定义好（
.avsc文件），运行时不能动态生成；否则反序列化会 panic - 写入时用
avro.NewWriter，传入io.Writer；不要直接写到bytes.Buffer后再压缩——会导致两次内存拷贝 - 读取时用
avro.NewReader，需提供 exact schema（不是 schema string，是解析后的avro.Schema实例）
Avro + zlib 流式封装：避免 gzip.Header 和 footer 破坏协议
HTTP 场景下用 gzip.Writer 没问题，但自定义 TCP 或 Kafka 场景下，gzip 的 header（0x1f8b）和 footer（crc+size）会干扰帧边界。更稳妥的做法是用 compress/zlib，它只压缩数据流，无额外头尾：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 服务端写入链：
avro.Writer → zlib.Writer → net.Conn - 调用
zlib.NewWriterLevel(conn, zlib.BestCompression)，避免默认的zlib.DefaultCompression在小 payload 下反而膨胀 - 每次
w.Write()后必须w.Flush()，否则数据卡在 zlib 缓冲区，接收端收不到 - 客户端读取时，先读固定长度（如 uint32 头），再用
zlib.NewReader(io.LimitReader(r, n))解压，防止粘包或截断
Schema registry 同步是最大隐性成本，不是代码问题
Avro 的 schema 变更（哪怕只是加个 optional 字段）要求 producer/consumer 两端 schema 完全兼容，否则 avro: cannot decode union: unknown type 这类错误会在运行时爆发。比写代码难十倍的是：
立即学习“go语言免费学习笔记（深入）”；
- schema 必须 git commit 到统一仓库，用 CI 校验前向/后向兼容性
- 不要在代码里硬编码 schema 字符串；用
avro.ParseSchemaBytes(bts)加载，启动时 panic 而非静默失败 - Kafka 场景下，务必对接 Confluent Schema Registry，用
avro.NewSchemaRegistryClient动态获取 schema ID，而非本地文件 - 字段重命名、类型变更、删除必字段——这些操作在 Avro 里没有“迁移工具”，只能靠双写+灰度+回滚预案
真正卡住上线的，从来不是 avro.Marshal 写不对，而是 schema 版本没对齐、registry 权限没开、或 consumer 还在用 v1 schema 解 v2 数据。
