protobuf在高频大体积数据交换中显著优于json，但配置文件或简单api响应等场景硬切反而增加维护成本；其性能优势源于预生成代码绕过反射、二进制编码省去字符串解析，实测1mb数据序列化耗时仅1.8ms（json为12.4ms），内存分配次数减少至9次（json为47次）。
Protobuf 在高频、大体积数据交换场景下显著优于 JSON，但不是所有地方都该换——配个 config 文件或写个简单 HTTP API 响应，硬上 Protobuf 只会抬高维护成本和调试门槛。
Go 里 json.Marshal 和 proto.Marshal 性能差距到底在哪
核心差异不在“语法”，而在执行路径：
-
encoding/json默认走反射，每次 Marshal 都要动态查字段名、类型、 tag，CPU 和内存开销都高；google.golang.org/protobuf/proto用预生成代码，字段偏移、长度、编码规则全在编译期固化 - JSON 是文本格式，必须做字符串解析、引号转义、UTF-8 校验；Protobuf 是二进制，字段按编号紧凑排列，无冗余分隔符
- 时间字段典型例子：
time.Time{}在 JSON 中序列化为长字符串（如"2024-01-01T00:00:00Z"），而 Protobuf 推荐用google.protobuf.Timestamp，只占 12 字节且无解析歧义
实测 1MB 数据：JSON 序列化耗时约 12.4ms，Protobuf 仅 1.8ms；反序列化内存分配次数前者 47 次，后者仅 9 次。
omitempty 在 JSON 和 Protobuf 中行为不一致，容易踩坑
JSON 的 omitempty 是运行时判断字段值是否为 Go 零值（""、0、nil），但 time.Time{} 或 sql.NullString{Valid: false} 并非零值，仍会被序列化；Protobuf v3 默认就不发送未设置的字段（即“未赋值”而非“零值”），语义更干净，但迁移时若结构体字段没显式赋值，可能丢数据。
- 别把
CreatedAt time.Time直接映射成 proto 的int64 created_at = 1—— 缺少类型约束，反序列化时可能溢出或截断 - 想跳过空字段？JSON 里优先用指针类型（如
*string）+omitempty；Protobuf 里靠字段是否调用SetXXX()控制，无需额外标记 - 嵌套结构体字段为空时，JSON 可能输出
{"user": {}}，Protobuf 则完全不包含user字段，接收方需做好 nil 判断
什么时候该坚持用 encoding/json，而不是切 Protobuf
不是性能差就要换，要看瓶颈是否真在序列化本身：
- HTTP API 返回给前端的数据：JSON 可读、浏览器原生支持、便于调试，换 Protobuf 得加一层网关解码，得不偿失
- 配置文件、命令行参数、本地日志快照：人类要直接看，Protobuf 二进制无法 cat，也不方便
grep - 已有大量
map[string]interface{}动态结构：Protobuf 不支持运行时 schema，硬套会导致 panic 或静默失败 - 短期项目或 PoC 阶段：ProtoBuf 要写
.proto、生成代码、管理版本兼容性，开发节奏被拖慢
如果卡在 JSON 性能上但又不能动协议，先试试 github.com/goccy/go-json —— 替换 import 就能提速 2～4 倍，且完全兼容标准库接口。
Protobuf 真正快起来，绕不开几个关键配置
光用 proto.Marshal 不代表就高效，常见疏漏直接抵消掉一半优势：
- 没启用
Size()缓存：加option (gogoproto.sizer) = true;，否则每次 Marshal 前都要遍历计算长度 - 忽略输入校验开销：生产环境可设
proto.UnmarshalOptions{DiscardUnknown: true}，跳过未知字段合法性检查 - 字段类型乱配：比如 proto 定义
int32 id = 1，Go struct 却用int64，触发 runtime 类型转换，比 JSON 还慢 - 用
bytes字段存 JSON 字符串：等于套娃序列化，CPU 白烧，体积反而更大
最常被忽略的一点：Protobuf 的性能收益高度依赖“字段定义与实际数据分布匹配”。比如一个字段 99% 时间为空，却定义为非 optional，它仍会占用空间并参与编码逻辑——这比选错库更伤。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
