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 作为参数/返回值传入。但这类做法极易出错：
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
立即学习“go语言免费学习笔记（深入）”；
- 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 接口里了，自己造轮子时最容易在这些细节上翻车。
