go http服务接入protobuf需手动处理content-type校验、完整读取body再proto.unmarshal，响应侧用proto.marshal设application/protobuf头；不可直接传req.body，须防oom设maxbytesreader；grpc-web增复杂度但收益有限。
Protobuf 在 Go HTTP 服务里怎么接进 request / response
Go Web 服务用 protobuf 替 JSON，核心不是换序列化格式，而是换掉 json.Unmarshal 和 json.Marshal 的调用点。HTTP 层本身不认 Protobuf，得自己接管 Content-Type 和 body 解析逻辑。
常见错误是直接把 *http.Request 丢给 proto.Unmarshal——它只吃 []byte，且要求数据是二进制 wire format，不是原始 body 流。必须先读全 body，再校验 Content-Type: application/protobuf（或你约定的 type），最后解码。
- 别用
req.Body直接传给proto.Unmarshal；先io.ReadAll(req.Body) - 务必检查
req.Header.Get("Content-Type")，避免 JSON 请求误走 Protobuf 路径导致 panic - 响应侧同理：用
proto.Marshal生成[]byte，设w.Header().Set("Content-Type", "application/protobuf")，再w.Write()
为什么不能直接用 net/http + protobuf 而要加一层中间件
因为 net/http 的 HandlerFunc 没有内置协议协商能力。JSON 可以靠结构体 tag 和默认 marshaler “蒙混过关”，但 Protobuf 需要显式绑定 message 类型，而每个 endpoint 的入参、出参类型不同。
典型踩坑：写一个全局 protoDecoder 中间件，却没按 path 或 method 区分 target message，结果 A 接口传了 B 的 proto binary，proto.Unmarshal 不报错但字段全零值——Protobuf 解码容忍未知字段，静默失败比 panic 更难排查。
立即学习“go语言免费学习笔记（深入）”；
- 每个 handler 应该持有自己对应的
*pb.LoginRequest或*pb.UserResponse类型指针，不能泛化成proto.Message后乱 cast - 如果用 Gin/Echo，别依赖第三方 protobuf middleware（多数硬编码单类型或忽略 size limit），自己写 10 行
Bind就够用 - 注意
proto.Size()：大消息不设读取上限，io.ReadAll可能 OOM；建议用http.MaxBytesReader包一层
gRPC-Web 和纯 HTTP+Protobuf 的关键区别
如果你只是想提效，别碰 gRPC-Web。它引入 grpcwebproxy、额外 Content-Type（application/grpc-web+proto）、base64 编码、状态码映射等一堆复杂度，而传输效率提升几乎为零——真正省的是 JSON 解析开销，不是网络字节。
真实收益场景只有两个：1）移动端弱网下反复传同一结构体（如 IoT 设备心跳）；2）后端服务间高频小包通信（如微服务链路）。浏览器端用 Protobuf，反而因缺失原生支持，要多载 google-protobuf JS 库、手动处理 binary arraybuffer，得不偿失。
- 纯 HTTP+Protobuf：Go server 端改 20 行，curl 测试用
--data-binary @file.bin -H "Content-Type: application/protobuf" -
gRPC-Web：需额外 proxy、前端 fetch 改造、错误码转义、streaming 支持残缺 - Protobuf 的压缩率优势在 payload > 1KB 时才明显；小数据（如
{"id":123}）JSON 反而更短
Go 里 protobuf 编译和 import 路径容易错哪几处
最常卡住的是 protoc 生成代码后，Go 找不到 pb 包。根本原因不是插件没装，而是 go_package option 和实际文件路径不一致。
比如 user.proto 里写了 option go_package = "myapp/pb";，但生成的 user.pb.go 放在 ./proto/user/ 下，Go build 就会报 cannot find package "myapp/pb"——它真会按字符串去 GOPATH 或 module root 下找目录。
-
protoc命令必须带--go_opt=module=myapp，否则go_package会被忽略 - 生成目录结构应严格匹配
go_package：若值为"myapp/pb"，就该生成到$MODROOT/myapp/pb/ - 别用相对路径如
./pb；模块名中含.（如example.com/repo）会导致 import 失败，改用短名
Protobuf 提效的前提是：你已经压测过 JSON 路径，确认瓶颈在序列化/反序列化，而不是数据库或网络延迟。盲目替换，可能换来更难 debug 的二进制错误和更脆的前后端协作流程。
