grpc传输体积大主因是proto定义错误：二进制数据误用string导致base64膨胀1.33倍，应改用bytes；go中避免冗余指针字段，优先用optional生成值类型；枚举代替字符串可省空间；gzip压缩需在每次调用显式启用。
gRPC传输体积大，先看是不是proto里用了string传二进制数据
很多同学把图片、PDF、加密密钥等直接塞进string字段，Protobuf会先UTF-8编码再Base64转义，体积直接膨胀≈1.33倍。这不是gRPC的问题，是proto定义错了。
- 二进制内容必须用
bytes类型，不是string -
bytes在序列化时按原始字节处理，零拷贝、无编码开销 - 如果后端或客户端已用
string存了base64字符串，得改协议+灰度升级，不能只改一端
message UploadRequest {
// ❌ 错误：触发UTF-8校验 + Base64编码
string file_data = 1;
// ✅ 正确：原始字节直传
bytes file_data = 1;
}
Go生成的proto结构体里有大量nil指针字段？关掉optional默认行为
Protobuf 3 默认所有字段都是“可选”，Go插件为每个字段生成*T指针类型（比如*int32），哪怕你从不设为nil。空指针本身不占序列化体积，但Go运行时会为每个字段分配指针内存，且反序列化时要判断nil再赋值——这拖慢速度，也间接影响GC压力。
- 在
.proto中显式加optional关键字（Protobuf 3.12+），让插件生成值类型（如int32）而非指针 - 旧版Protobuf需加
option go_package = "xxx;xxx";并配合--go_opt=paths=source_relative，否则插件仍可能退化为指针 - 注意：
optional字段设为零值（如0、""）时，Protobuf默认不序列化——体积确实小了，但接收方会收不到该字段（视为未设置），业务逻辑要兼容
反复传输相同字符串（如状态码、枚举名、固定ID）？用enum代替string
比如status = "success"每次传7字节，而status = SUCCESS（对应int32值0）只占1字节。Protobuf对小整数用Varint编码，值越小体积越小。
- 枚举值从0开始连续编号（
SUCCESS=0, FAILED=1, TIMEOUT=2），避免跳号导致Varint变长 - 别为了“语义清晰”把枚举值手动设成大数（如
FAILED=500），那反而比string还费字节 - 如果前端必须用字符串，服务端内部转
enum收发，JSON网关层再映射回来，别把妥协带到Protobuf层
Go服务启用了gzip压缩但体积没降？检查grpc.WithCompressor注册时机
gRPC Go的压缩是按Call启用的，不是全局开关。如果只在grpc.Dial时配了grpc.WithCompressor，但没在grpc.Invoke或grpc.NewClientStream里传grpc.UseCompressor选项，压缩根本不会生效。
立即学习“go语言免费学习笔记（深入）”；
- 服务端要在
grpc.Server创建时注册：grpc.KeepaliveParams不影响压缩，别混淆 - 客户端调用时必须显式传：
grpc.Invoke(ctx, method, req, resp, cc, grpc.UseCompressor("gzip")) - Gzip对纯文本（如JSON）效果好，但对已压缩过的二进制（如JPEG、ZIP）可能增肥，别盲目开
string和bytes混用、enum值乱设、压缩漏传选项，线上压测时才暴露。 
