Iris框架不支持ProtoBuf自动编解码，因其ReadJSON()依赖json.Unmarshal()而ProtoBuf为二进制流，必须手动读取Body并调用pb.Unmarshal()/pb.Marshal()，设置Content-Type: application/x-protobuf，禁用ctx.ReadJSON()/ctx.JSON()。
Iris框架本身不支持直接用ProtoBuf做HTTP请求体序列化，必须手动接管请求/响应的编解码逻辑。 它默认只处理JSON、表单、URL编码等标准格式，ProtoBuf需自行注册iris.Context的读写方法，否则ctx.ReadJSON()或ctx.JSON()会直接报错或静默失败。
为什么Iris的ctx.ReadJSON()不能读ProtoBuf
Iris的ReadJSON()底层调用json.Unmarshal()，而ProtoBuf二进制数据不是合法JSON，会触发invalid character错误；同理ctx.JSON()输出的是JSON字符串，不是.proto定义的二进制格式。你看到的“解析失败”或空结构体，基本都源于此。
- ProtoBuf消息是二进制字节流，长度不定，无分隔符，不能靠
Content-Type: application/json自动识别 - Iris没有内置
ReadProto()或WriteProto()方法，必须显式调用pb.Unmarshal()和pb.Marshal() - HTTP Header中需明确设为
Content-Type: application/x-protobuf（非强制但推荐，便于调试和网关识别）
在MVC控制器里安全读写ProtoBuf数据
关键是在PostXXX或PutXXX方法内，跳过Iris默认解析，直接操作ctx.Request().Body和ctx.ResponseWriter()。
- 读取：用
io.ReadAll(ctx.Request().Body)拿到原始[]byte，再传给pb.Unmarshal()；记得检查err是否为io.EOF或io.ErrUnexpectedEOF - 写入：先
pb.Marshal()得到[]byte，然后调用ctx.ResponseWriter().WriteHeader(200)+ctx.ResponseWriter().Write()，并手动设置ctx.ResponseWriter().Header().Set("Content-Type", "application/x-protobuf") - 不要用
ctx.ReadJSON(&v)或ctx.JSON(v)——它们对ProtoBuf完全无效 - 若需复用结构体字段校验（如
binding:"required"），得自己实现Validate()方法，Iris的ctx.ReadBody()不支持ProtoBuf绑定
ProtoBuf与gRPC共存时的常见冲突点
如果你同时在Iris里调用gRPC服务（比如用pb.NewGreeterClient()），注意ProtoBuf生成代码和HTTP传输用的是同一套.proto定义，但运行时互不干扰；真正容易出问题的是google.golang.org/protobuf版本混用。
- 确保
go.mod里所有google.golang.org/protobuf引用统一为v1.34+（2026年主流版本），低版本可能和gRPC-Go v1.6x不兼容 - 别把gRPC客户端生成的
*_grpc.pb.go和HTTP层用的*_pb.go放在同一包下却用不同protoc-gen-go版本生成，会导致Unmarshalpanic - HTTP接口返回ProtoBuf时，别漏掉
Content-Length头——某些反向代理（如Nginx默认配置）会截断无长头的二进制响应
最常被忽略的是错误处理粒度：ProtoBuf解码失败时，err可能是proto: invalid wire format或proto: illegal tag，这类错误应返回400 Bad Request而非500 Internal Server Error，因为本质是客户端发了非法二进制数据。
