应配置客户端keepalive参数并匹配服务端空闲超时：go设clientparameters{time:30s,timeout:10s,permitwithoutstream:true}，java设keepalivetime≥30s、keepalivetimeout≤服务端读超时且禁用keepalivewithoutcalls。
gRPC客户端空闲超时后请求直接报 UNAVAILABLE 怎么办
这是最典型的空闲断连表现：连接没显式关闭，但发请求时突然返回 UNAVAILABLE + transport is closing 或 connection reset by peer。根本原因不是网络抖动，而是服务端或客户端主动踢掉了长时间无数据的连接。
关键要分清谁在超时：gRPC本身不维护心跳，真正起作用的是底层 HTTP/2 连接的保活机制，而它依赖两端配置——尤其是服务端（如 nginx、envoy、或 gRPC Server 自身）的空闲超时设置往往比客户端更短。
- 检查服务端反代（如 nginx）的
keepalive_timeout，默认常为 60s，低于 gRPC 客户端的keepalive_time就必然断连 - Go gRPC Server 默认无 keepalive，需显式调用
grpc.KeepaliveParams()设置MaxConnectionIdle - Java Netty Server 要留意
NettyServerBuilder.keepAliveTime()和keepAliveTimeout()的配对关系
Go 客户端怎么配 keepalive 才不被服务端甩掉
Go 的 grpc.Dial() 里 keepalive 参数容易误解：它只控制“客户端主动发 ping”，不保证连接永存；是否被服务端接受、是否被中间设备拦截，全看服务端配合。
必须同时设三个参数，缺一不可：
-
keepalive.ClientParameters{Time: 30 * time.Second, Timeout: 10 * time.Second, PermitWithoutStream: true}——Time是发 ping 间隔，建议设为服务端空闲超时的 1/2～2/3；Timeout必须小于服务端读超时，否则 ping 超时会被当异常断连 -
PermitWithoutStream: true很关键：允许在没有活跃 RPC 的情况下发 keepalive ping；不设这个，空闲时根本不会发 ping - 还要加
grpc.WithBlock()+grpc.FailOnNonTempDialError(true)避免 dial 返回假成功，掩盖连接实际已断的问题
Java 客户端 keepAliveTime 设太小反而更频繁断连
Java 的 ManagedChannelBuilder.keepAliveTime() 如果设成 5s，看起来很“勤快”，但实际可能触发服务端限流或连接复用策略失效——尤其当服务端是 C++ 或 Rust 实现时，对高频 ping 敏感。
典型症状：日志里反复出现 PING frame received 后紧跟着 GOAWAY，说明服务端主动拒收。
- 推荐起步值：30～45 秒；先确认服务端最大空闲时间（查部署配置或抓包看 GOAWAY 帧里的
last-stream-id和error-code） - 务必同步设
keepAliveTimeout(10, TimeUnit.SECONDS)，超时值要明显短于服务端读超时（如服务端 read timeout=15s，则 client timeout ≤10s） - 禁用
keepAliveWithoutCalls(false)（默认值），否则空闲时完全不发 ping —— 这是 Java 客户端默认行为，也是多数人踩坑的根源
为什么加了 keepalive 还是隔几小时就断？
因为中间网络设备（防火墙、云厂商 LB、k8s Service）普遍有连接跟踪（conntrack）超时，常见 3600s（1 小时），且不识别 HTTP/2 ping，只看 TCP 层是否有数据包。gRPC keepalive ping 是 HTTP/2 PING 帧，某些旧设备直接忽略。
这时仅靠应用层 keepalive 不够，得结合连接池和重试：
- 客户端启用连接复用：Go 用
grpc.WithTransportCredentials()默认开启；Java 确保没设usePlaintext()导致降级到 HTTP/1.1 - 对幂等 RPC，加
grpc.WaitForReady(true)（Go）或withWaitForReady()（Java），让请求阻塞直到新连接建好，避免裸抛UNAVAILABLE - 终极兜底：在业务层捕获
UNAVAILABLE并做指数退避重试，但注意别重试非幂等操作（如 CreateOrder）
真正的难点不在配参数，而在于你得知道整个链路上哪一环在断——服务端？反代？LB？还是客户端自己没发 ping？抓包看 TCP FIN 和 HTTP/2 GOAWAY 才算真正定位到根因。
