grpc连接超时本质是客户端无法建立tcp连接，需从连接建立环节排查：1. grpc.dial须显式配置withtimeout和withblock；2. 验证服务端是否启用反射及地址是否正确；3. 双端配置keepalive参数防空闲断连；4. 优先用telnet/nc确认tcp可达性。
gRPC连接超时问题本质是客户端连不上服务端，不是请求超时，得从连接建立环节下手。
grpc.Dial 时没设 WithTimeout 或 WithBlock 导致卡死
默认情况下 grpc.Dial 是异步建连：它立即返回一个 *grpc.ClientConn，但底层 TCP 握手、TLS 协商、服务端响应可能还在进行。如果服务端没起来或网络不通，conn.Ready() 会一直为 false，后续第一次 RPC 调用就卡在 context deadline exceeded——这不是业务超时，而是连接根本没建好。
- 必须显式加
grpc.WithTimeout(5 * time.Second)控制建连总耗时 - 搭配
grpc.WithBlock()让Dial阻塞直到成功或超时，避免后续调用时才暴露问题 - 不要依赖
context.WithTimeout包裹第一次 RPC 调用——那只是等请求，不等连接 - Kratos 项目中通常在
internal/client/grpc.go的grpc.Dial调用处补上这两项
服务端未开反射且客户端直连地址写错，误判为连接超时
用 grpcurl -plaintext localhost:9000 list 测试时，报 Failed to list services: server does not support the reflection API，很多人以为是连接超时，其实是服务端没启用反射，或者客户端连的地址根本不是 gRPC 监听地址（比如连了 HTTP 端口 8000 而非 gRPC 端口 9000）。
- 检查
internal/server/grpc.go是否传入grpc.ReflectionProvider(reflection.GRPCServerReflector(srv)) - 确认
grpc.Dial地址是"127.0.0.1:9000"这类直连地址，而非"discovery:///xxx.service"（后者走服务发现，失败路径更隐蔽） - 本地调试优先用直连 + 反射，排除注册中心干扰
- 若用明文连接，
grpc.WithTransportCredentials(insecure.NewCredentials())必须存在，漏掉会导致握手卡住，表现和超时一致
Keepalive 配置不当引发“假超时”
连接看似建好了，但空闲几秒后发第一个请求就报 connection closed before server preface received 或 transport is closing——这不是建连超时，是中间件（防火墙/NAT/SLB）静默断开了空闲连接，而 gRPC 两端没协商好心跳保活。
- 服务端必须设
grpc.KeepaliveParams，至少配MaxConnectionIdle: 30 * time.Second - 客户端对应配
grpc.WithKeepaliveParams，Time建议 ≤ 15s，PermitWithoutStream: true - 只配客户端不配服务端，心跳发出去没人回，照样断；只配服务端不配客户端，客户端压根不发心跳
- HTTP/2 层 keepalive 和 TCP
SO_KEEPALIVE不是一回事，别指望改系统参数解决
连接超时问题最麻烦的点在于现象相似但根因分散：可能是 DNS 解析慢、目标端口没监听、TLS 握手卡住、防火墙拦截、服务端进程崩溃……务必先用 telnet 127.0.0.1 9000 或 nc -zv 127.0.0.1 9000 确认 TCP 层通不通，再往上排查 gRPC 协议层配置。
