17370845950

Go 的 net/rpc 不支持原生流式调用，仅限请求-响应模型；真正流式场景应使用 gRPC，其通过 proto 中 stream 关键字实现双向流，并内置生命周期、错误传播与上下文取消等机制。

Go 的 net/rpc 本身不支持流式调用

标准库 net/rpc 是基于请求-响应（request-response）模型的，每次调用必须有明确的输入参数和单一返回值。它没有内置的流式（streaming）能力，比如像 gRPC 那样支持 server streaming、client streaming 或 bidi streaming。如果你看到有人用 net/rpc “实现流式”，大概率是手动封装了连接复用、分帧或 goroutine 协作逻辑，而非原生支持。

用 gRPC-Go 实现双向流式调用最直接

真正需要流式 RPC，应切换到 gRPC —— 它是 Go 生态中事实标准的流式 RPC 方案。定义一个双向流式方法只需在 .proto 文件中声明 stream 关键字：

service ChatService {
  rpc Chat(stream Message)
 returns (stream Message);
}

生成代码后，服务端实现类似：

func (s *chatServer) Chat(stream pb.ChatService_ChatServer) error {
  for {
    msg, err := stream.Recv()
    if err == io.EOF {
      return nil
    }
    if err != nil {
      return err
    }
    // 处理收到的消息，并可随时 Send()
    if err := stream.Send(&pb.Message{Content: "echo: " + msg.Content}); err != nil {
      return err
    }
  }
}

• stream.Recv() 和 stream.Send() 可交替调用，无固定顺序
• 客户端同样用 stream.Send() 发送、stream.Recv() 接收，各自独立 goroutine 更安全
• 注意：不要在同一个 stream 上并发调用 Send()，需加锁或串行化

强行在 net/rpc 上模拟流式的风险点

若因历史原因必须用 net/rpc，常见“模拟”方式是把 io.ReadCloser 或 chan 作为参数/返回值传入。但这类做法极易出错：

• RPC 编码器（如 gob）无法序列化 chan 或未导出字段，会 panic 或静默失败
• 传入 io.Reader 时，net/rpc 会尝试读取全部内容再发，导致阻塞或超时
• 服务端 goroutine 泄漏：如果 client 提前断开，服务端可能还在往已关闭的 conn 写数据
• 没有流控、背压机制，发送方容易压垮接收方

可行的折中方案是：用 net.Conn 手动建长连接，自定义帧格式（如 length-prefixed），再起 goroutine 跑 rpc.ServeConn —— 但这已脱离 net/rpc 的设计初衷，维护成本高。

流式场景下选型关键看协议与生态兼容性

是否用 gRPC 不只取决于“能不能流”，更要看上下游是否支持：

• 如果客户端是 Python/Java/JS，且已有 gRPC stub，直接上 grpc-go 几乎零成本
• 如果必须走 HTTP/1.1 或要浏览器直连，gRPC-Web 是选项，但需 proxy（如 envoy）
• 若仅限 Go 内部通信，且对性能极度敏感，可考虑 twirp（基于 JSON over HTTP）或自研二进制协议 + gorilla/websocket
• net/rpc 唯一优势是零依赖、启动快，但流式需求出现时，这个优势通常已不成立

真正麻烦的不是怎么写流式逻辑，而是如何让流的生命周期、错误传播、重连、超时、取消（context.Context）在两端保持语义一致 —— gRPC 把这些都封装进 Stream 接口里了，自己造轮子时最容易在这些细节上翻车。