必须使用新版 protobuf 包并正确配置 protoc 生成代码，HTTP 传 protobuf 需手动处理 Content-Type 和解析逻辑，而 gRPC 才是安全可靠的二进制通信方案。
直接用 proto.Marshal 替换 json.Marshal 不等于启用了二进制传输——关键在协议栈是否真正承载二进制 payload，否则只是“披着二进制外衣的 JSON 通信”。
为什么 protoc --go_out 生成的代码编译报 undefined: proto.Marshal？
新版 google.golang.org/protobuf/proto 已完全取代旧包 github.com/golang/protobuf/proto，但很多教程仍沿用过时命令和导入路径。
- 必须安装新版插件：
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest -
protoc命令要显式指定输出路径，且不加plugins=grpc（该参数已废弃）：protoc --go_out=. --go-grpc_out=. service.proto - 生成文件头部应含
import "google.golang.org/protobuf/proto"，若看到github.com/golang/protobuf/proto就说明生成环境或.proto文件里残留了旧引用 - 手动 import 旧包会触发冲突，删掉所有
import "github.com/golang/protobuf/proto"行
HTTP 微服务里怎么安全传 protobuf 二进制 body？
REST 接口混用 protobuf body 和 JSON path/query 参数极易因中间件自动 decode 或 Content-Type 冲突失败，不是“能跑通”就代表正确。
- 客户端必须设
Content-Type: application/x-protobuf，不能用application/json—— 否则网关或反向代理可能尝试 JSON 解析并丢弃原始字节 - 发送前用指针调用：
body, err := proto.Marshal(&msg)，传值（proto.Marshal(msg)）会导致字段全为空 - 服务端接收后需完整读取
req.Body，再用proto.Unmarshal(bodyBytes, &msg)，别依赖io.ReadAll以外的封装（如某些框架的BindJSON会强制解析 JSON） - 务必校验
msg.ProtoReflect().IsValid()或检查proto.Unmarshal返回的 error，空字节或字段类型错位不会 panic，但会静默忽略字段
gRPC 是唯一靠谱的二进制通信落地方式
HTTP + protobuf body 需手动处理 schema 版本、magic header、错误码映射，而 gRPC 把这些都收束在协议层，省掉 80% 的胶水代码。
立即学习“go语言免费学习笔记（深入）”；
-
protoc --go-grpc_out=.生成的 stub 天然绑定application/grpc+ HTTP/2，无需改Content-Type或写自定义 transport - 流式接口（
rpc StreamData(stream Request) returns (stream Response)）直接支持 chunked 二进制传输，比 HTTP 分块更底层、更低开销 - 连接复用由
grpc.Dial自动管理，grpc.WithKeepaliveParams可控心跳，避免短连接反复建连消耗 - 错误统一走
status.Code，不用自己定义400/500映射表，客户端errors.Is(err, xxx)即可判断
bytes 字段传二进制数据时最常踩的坑
Protobuf 的 bytes 类型不是容器，而是 wire format 原生支持的二进制载体——它不经过 Base64 编码，也不做任何转换。
-
.proto中必须声明为bytes field_name = N;，写成string或message会导致传输损坏 - Go 侧直接赋值
msg.Data = []byte{0xFF, 0x00, 0xAB}，千万别base64.StdEncoding.EncodeToString()再塞进去 - 服务端读取必须用
msg.GetData()（生成的方法名），而非msg.Data字段直取——后者在 proto3 中可能被优化为 nil 指针 - 大文件传输时注意 gRPC 默认 4MiB 限制，需在服务端配置
grpc.MaxRecvMsgSize(16
真正卡住人的从来不是序列化函数怎么写，而是 HTTP 中间件对非 JSON Content-Type 的拦截策略、gRPC 连接池的 timeout 设置、以及 bytes 字段在 proto2/proto3 间生成代码的零值差异——这些地方不查日志、不抓包，光看代码永远定位不到问题。
