protobuf在go微服务中性能远超json，实测吞吐高3–5倍，因其实现零反射、二进制flat buffer及字段编号顺序写入，而json依赖字符串解析和运行时反射，高并发下cpu易跑满。
Go 微服务里选序列化协议，别只看“支持跨语言”——实际压测下来，Protobuf 和 JSON 的吞吐差距能到 3–5 倍，但前提是你的结构体得符合 proto.Message 接口，否则 proto.Marshal 直接 panic。
为什么 json.Marshal 在高并发下 CPU 跑满，而 proto.Marshal 还很稳
JSON 是纯文本解析，每次都要做字段名匹配、类型推断、嵌套结构展开；Protobuf 是二进制 flat buffer，字段按编号顺序写入，跳过所有字符串 key 查找。Go 标准库的 encoding/json 没法跳过反射开销，而 google.golang.org/protobuf/proto 默认使用 codegen 后的结构体方法，零反射。
- 实测 10 万次序列化：JSON 平均耗时 8.7ms，Protobuf 仅 20.2ms？错——那是没开
protoc-gen-gov2 的预编译模式；用protoimpl生成的代码后，实际是 2.1ms - 反序列化更敏感：JSON 必须构建完整 AST 再映射到 struct；Protobuf 直接按偏移 copy 字节，
proto.Unmarshal不会触发 GC 扫描 - 注意：如果用了
json.RawMessage或嵌套interface{}，JSON 性能会进一步掉 30%+，Protobuf 却完全不受影响
proto.Marshal 报错 “message does not implement proto.Message” 怎么修
这不是配置问题，是类型契约没满足。eRPC 或 gRPC 里的 Protobuf 编解码器要求传入值必须是 proto.Message 接口实现体，不是任意 struct。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 检查你传的是不是
&User{...}—— 必须是pb.User（由protoc生成），不能是手写的同名 struct - 确认 import 路径：生成代码里必须有
func (*User) ProtoMessage()方法，且 package 导入的是google.golang.org/protobuf/proto，不是旧版github.com/golang/protobuf/proto - 如果你在用 eRPC，它的
ProtoCodec会强制校验v.(proto.Message)，失败就 return error；别试图用json.Marshal包一层绕过去，那等于放弃 Protobuf 全部优势
Thrift 在 Go 里跑不快？大概率是没选对传输协议
eRPC 的 ThriftCodec 默认走 TBinaryProtocol，但 Go 的 thrift lib 对 binary 协议优化一般；真正快的是 TSimpleJSONProtocol 或压缩后的 TCompactProtocol，不过后者需要两端都支持。
-
TCompactProtocol序列化体积比 JSON 小 40%，但 Go 官方 thrift 实现（apache/thrift）的反序列化速度只有 Protobuf 的 60% - eRPC 里启用 compact 需显式注册：
codec.RegisterCodec("thrift-compact", &ThriftCodec{Protocol: thrift.COMPACT_PROTOCOL}) - 别混用：Thrift IDL 里定义的
optional字段，在 Go client 里如果传了 nil 指针，TBinaryProtocol会 panic，TCompactProtocol才正确跳过
真正卡住性能的往往不是协议本身，而是你没关掉日志里的 json.MarshalIndent，或者在中间件里反复 json.Unmarshal → json.Marshal 做透传——这种操作在 Protobuf 下根本不会发生，因为二进制 payload 不可读，没人会去“格式化”它。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
