Go标准库net/rpc默认短连接，高并发下性能差；应改用长连接复用rpc.Client（线程安全），或构建带健康检查的连接池；更优方案是升级至gRPC，其ClientConn天然支持多路复用与自动连接管理。
Go 语言标准库的 net/rpc 默认基于短连接（每次调用新建 TCP 连接），在高并发或高频调用场景下开销大、延迟高。要提升 RPC 效率，核心是改用长连接 + 连接池，避免反复建连/断连。Go 本身不直接提供 RPC 连接池，但可通过封装 net.Conn 和复用 rpc.Client 实现。
使用长连接：复用单个 Client 实例
rpc.Client 是线程安全的，只要底层 net.Conn 保持活跃，就能持续发送请求。关键不是“每次 new Client”，而是“复用一个 Client 对应一个持久连接”。
- 创建连接时用
rpc.Dial或rpc.DialHTTP，返回的*rpc.Client可长期持有（例如作为全局变量或依赖注入） - 确保服务端也支持长连接（如 HTTP/1.1 Keep-Alive，或自定义 TCP 协议不主动关闭）
- 手动控制连接生命周期：调用
client.Close()仅在确定不再使用时才执行，不要每次调用后关闭
实现简单连接池：管理多个长连接 Client
当单连接成为瓶颈（如服务端单连接吞吐有限，或需故障隔离），可维护一组预建立的 *rpc.Client，按需获取/归还。
- 用
sync.Pool管理空闲 Client，但注意：Pool 不保证对象存活，且不适合带状态的对象；更稳妥的是用带健康检查的自定义池（如基于 channel 或结构体字段控制） - 典型做法：启动时建立 N 个连接，存入切片或 channel；调用前
Select或轮询取一个可用 Client；调用后放回（不 Close） - 必须做连接健康检查：调用前尝试发一个轻量 ping 请求，或捕获
io.EOF/net.ErrClosed等错误，自动重建失效连接
配合 HTTP/2 或 gRPC 更自然地支持复用
如果可以升级协议，gRPC-Go（基于 HTTP/2）天然支持多路复用和连接复用，无需手动管理池。
立即学习“go语言免费学习笔记（深入）”；
- 一个
grpc.ClientConn实例可并发承载成百上千 RPC 调用，底层自动复用 TCP 连接 - 连接池逻辑由 gRPC 内置的
ClientConn管理（含重连、负载均衡、健康探测） - 只需复用同一个
ClientConn，再从中 New 出 service client（如pb.NewUserServiceClient(conn)）即可
注意事项与常见坑
长连接和连接池能提效，但也引入新问题，需主动规避：
- 连接泄漏：忘记归还 Client 到池，或未 close 导致 fd 耗尽 → 池中每个 Client 应配超时/最大使用次数限制
-
粘包/阻塞：TCP 长连接下，若服务端处理慢或挂起，Client 可能阻塞在
Call()→ 设置合理的context.WithTimeout并显式传入 - 序列化兼容性：复用 Client 时，服务端升级接口可能引发解码失败 → 保证 RPC 编解码协议向后兼容（如用 protobuf + 显式字段 tag）
-
资源回收：进程退出前，应主动
Close()所有 Client，避免 TIME_WAIT 占满端口
基本上就这些。标准 net/rpc 复用不难，重点在连接生命周期管理和错误恢复；真要上生产，推荐直接用 gRPC —— 复用、重试、鉴权、监控都已内置，省心不少。
