proto.Marshal会panic或返回空字节，因不接受nil指针、不自动初始化repeated/map嵌套字段，且不处理time.Time等自定义类型；必须显式构造合法消息并校验。
proto.Marshal 是 Go 语言中对 protobuf 消息做二进制编码的唯一推荐入口，它不接受 nil 指针、不自动初始化嵌套字段、也不处理自定义类型（如 time.Time），直接调用前必须确保消息结构体已合法构造。
为什么 proto.Marshal 会 panic 或返回空字节
常见现象是程序 crash 报 panic: proto: nil pointer to struct，或返回 nil, nil 而不是错误。这不是 bug，而是设计约束：
-
repeated字段（对应 Go 的 slice）若未显式初始化（如req.Items = make([]*Item, 0)），某些版本会静默跳过该字段，导致序列化结果不完整 - 嵌套 message 字段（如
req.Detail *Detail）为nil时，proto.Marshal允许，但反序列化后仍是nil—— 这是预期行为，不是错误 - 使用
new(MyMsg)构造后未赋值任何字段，会导致所有字段保持零值；而 proto3 中“未设置”和“设为零值”无法区分，proto.Marshal仍会编码这些零值字段 - 若从 JSON 反序列化后再传给
proto.Marshal，务必先调用proto.Validate(msg)（需启用go_proto_validate插件），否则非法字段（如负数 enum）可能在 Marshal 时 panic
如何安全构造并编码 protobuf 消息
避免靠猜或试错，按以下顺序操作：
- 用字面量构造：优先写
&MyMsg{Field1: "x", Nested: &Nested{...}}，而非new(MyMsg)后逐个赋值 - 对
repeated字段，显式初始化为空切片：req.Tags = []string{}或req.Children = make([]*Child, 0) - 对
map字段，**绝不能**用msg.GetLabels()修改 —— 它返回深拷贝，改了也白改；必须用msg.MutableLabels()获取可写引用 - 对
google.protobuf.Timestamp，别直接赋time.Now()；要用timestamppb.New(t)转换后赋值 - 对 UUID，存为
bytes字段，用uuid.MustParse("...").Bytes()赋值
proto.Size 和 binary.Size 别混用
预估缓冲区大小或判断传输开销时，必须用 proto.Size(msg)（v1）或 msg.ProtoSize()（v2）：
-
binary.Size是 Go 标准库对任意结构体的粗略估算，忽略 protobuf wire type、varint 压缩、字段编号编码等细节，结果常比真实编码长度小 20%–50% -
proto.Size不触发实际编码，性能开销极低，且结果与len(proto.Marshal(msg))一致 - 注意：
proto.Size不校验字段合法性（比如 enum 值越界），非法值仍会返回“看似合理”的 size；真要调试，直接len(proto.Marshal(msg))最可靠，但别在高频路径反复调用
HTTP 传输 protobuf 二进制数据时容易漏掉的关键点
前端收不到、显示乱码、截断，90% 是因为没对齐传输协议：
立即学习“go语言免费学习笔记（深入）”；
- 响应头必须设
Content-Type: application/x-protobuf（标准 MIME）或至少application/octet-stream；设成text/plain或不设，浏览器就当文本解析 - Go 服务端别用
json.NewEncoder(w).Encode(msg)—— 这会把 struct 当普通 map 打 JSON，字段全丢；必须用proto.Marshal后直接w.Write(data) - 前端 fetch 要配
responseType: 'arraybuffer'，axios 需设responseType: 'arraybuffer'，否则拿到的是被转义的字符串 - 如果走 gRPC-Web，必须用
grpcweb代理 +application/grpc-web+proto头，不能裸传 protobuf 字节流
proto.Marshal”，而是构造消息时字段是否初始化、嵌套是否非空、时间/UUID 是否手动转换、以及传输链路每一步是否都按 protobuf 的语义走 —— 少一个环节，字节流就失效。 
