Go rpc.Client 默认不复用连接，需手动长期持有同一实例并发调用，并在连接异常时重建；HTTP 模式下须自定义 http.Transport 启用连接池，且需主动健康检查与错误重试。
Go rpc.Client 默认不复用连接，需手动管理
Go 标准库的 net/rpc 包中，rpc.Dial（如 rpc.DialHTTP 或 rpc.Dial）每次调用都会新建 TCP 连接，不会自动复用。这意味着频繁调用 rpc.Dial 会快速耗尽本地端口、触发 TIME_WAIT、增加 handshake 开销。真正的“长连接复用”必须由使用者显式持有并重复使用同一个 *rpc.Client 实例。
复用 *rpc.Client 的正确姿势
核心原则：一个连接对应一个 *rpc.Client，该实例可安全并发调用（内部已加锁），且应长期复用直至服务不可达或主动关闭。
- 不要在每次 RPC 调用前
rpc.Dial，也不要在调用后立刻client.Close() - 应在初始化阶段建立连接，保存为包级变量、结构体字段或通过依赖注入传递
- 连接异常（如网络中断）时，
Call或Go方法会返回错误，此时应重建*rpc.Client并替换旧实例（需加锁保护） -
*rpc.Client不是线程安全的 Close —— 多个 goroutine 同时调用Close()可能 panic，确保仅由单一控制流关闭
var client *rpc.Client
func initClient() {
var err error
client, err = rpc.Dial("tcp", "127.0.0.1:8080")
if err != nil {
log.Fatal(err)
}
}
func CallService(method string, args interface{}, reply interface{}) error {
return client.Call(method, args, reply)
}
HTTP 模式下复用更需注意 http.Transport
若使用 rpc.DialHTTP，底层走 HTTP/1.1，复用依赖于 http.Transport 的连接池。但标准 rpc.DialHTTP 创建的是无配置的默认 client，其 transport 不启用 KeepAlive 或复用。必须手动构造带复用能力的 *http.Client，再传给 rpc.NewClient。
- 直接调用
rpc.DialHTTP仍会新建连接，无法复用 - 应使用
rpc.NewClient+ 自定义*http.Client，其中Transport配置MaxIdleConns和MaxIdleConnsPerHost - HTTP RPC 的
client.Close()实际关闭底层 HTTP 连接，复用时切勿频繁关闭
transport := &http.Transport{
MaxIdleConns: 100,
MaxIdleConnsPerHost: 100,
}
httpClient := &http.Client{Transport: transport}
conn, _ := httpClient.Post("http://127.0.0.1:8080/_goRPC_", "application/json", nil)
client := rpc.NewClient(conn)
连接健康检查与自动重连容易被忽略
复用连接不等于永不失败。网络抖动、服务重启、防火墙超时都会让已有连接静默失效。仅靠 Call 返回 error 是被动响应，无法提前剔除坏连接。生产环境需配合主动探测或失败回退策略。
立即学习“go语言免费学习笔记（深入）”；
- 不要假设
client != nil就代表连接可用 ——Write可能阻塞或返回io.EOF/connection refused - 可在调用前发轻量
ping方法（服务端实现空逻辑），或对错误类型做判断（如net.OpError表示底层连接异常） - 建议封装一层
CallWithRetry，在首次失败后重建 client 并重试一次（避免雪崩） - 连接复用周期越长，越需要考虑服务发现与 endpoint 变更 —— 静态地址复用可能指向已下线实例
复用本身很简单，难的是在连接失效边界上保持行为稳定；多数问题不出在 Dial，而出在 Close 和错误处理的时机。
