Go后端gRPC服务Add方法接收React前端传入参数始终为0的问题求助

核心问题定位 #

你遇到的服务端接收参数始终为0的问题，绝大多数场景下是前端构造protobuf请求对象的逻辑错误导致的，剩余少量场景为前后端代码绑定版本不匹配、类型校验缺失引发。 #

分步修复指引 #

1. 修正前端请求对象的构造逻辑 #

这是gRPC前端开发最常见的初学者踩坑点：protobuf工具链生成的JS消息类，不支持按字段顺序作为构造参数传值，构造函数只接收一个和消息字段一一对应的对象字面量。
你当前的错误写法：

// 无效写法：按位置传参无法绑定到消息字段
let additionRequest = new AdditionRequest(param1, param2);

这种写法下，你传入的两个值只是被临时存在构造函数的入参内存里，根本没有被绑定到param1、param2消息字段上，自然不会被序列化到实际发送的请求体中。你在浏览器抓包时看到的参数值，只是JS内存里的临时变量，不是真正发送的protobuf请求内容，服务端解析时自然会读到proto3定义的字段默认值0。
正确写法：

// 有效写法：传入字段映射的对象，显式做类型转换
let additionRequest = new AdditionRequest({
  param1: parseInt(param1, 10),
  param2: parseInt(param2, 10)
});

注意：前端从输入框、state中拿到的参数大多是字符串类型，哪怕构造请求时忘了转整数，protobuf也可能因类型不匹配静默解析成0，必须显式转成整数再传入。

2. 重新生成前后端的代码绑定文件 #

你当前定义的AdditionRequest消息，字段编号从2开始（跳过了编号1）：

message AdditionRequest {
    int64 param1 = 2;
    int64 param2 = 3;
}

如果之前修改proto前生成过旧版本的客户端/服务端代码，比如旧版本里param1的字段编号是1，现在没有重新执行protoc生成流程，前后端解析时会因为字段编号不匹配，拿到完全错乱的值，其中就包括参数恒为0的情况。

• 重新执行protoc命令生成Go端的服务桩代码
• 重新执行protoc命令生成JS端的客户端桩代码
• 清理前端项目里旧的生成代码文件，避免新旧文件混淆

3. 补充服务端日志定位 #

你当前的日志只单独打印了param1的值，可以调整Add方法的日志逻辑，直接打印完整请求结构体，快速定位问题：

func (s *Server) Add(ctx context.Context, request *pingpong.AdditionRequest) (*pingpong.AdditionResponse, error) {
  // 打印完整请求结构，清晰看到每个字段的实际值
  log.Printf("收到的原始请求: %+v", request)
  output := request.GetParam1() + request.GetParam2()
  // ... 原有逻辑
}

如果打印出来的完整请求里param1、param2两个字段都是0，就可以确认是前端构造请求的问题，不是网络传输丢包、代理转发破坏请求体的问题。

4. 注意int64类型的JS兼容问题 #

JS原生的Number类型是双精度浮点数，最大可安全表示的整数范围是±2^53-1。如果你的业务参数超过这个范围，需要确认protobufjs的编译配置，不要强制把int64转成Number类型，否则会出现值解析错误甚至恒为0的问题。 #

内容的提问来源于stack exchange，提问作者Lal Kumar Rai