grpc客户端应根据服务端配置选择withinsecure()（明文，服务端监听非tls端口）或withtransportcredentials()（tls/mtls，需匹配ca证书），并配合withblock()、withkeepaliveparams()等确保连接可用性和稳定性。
gRPC客户端初始化时，WithInsecure() 和 WithTransportCredentials() 到底该选哪个
用明文连接（比如本地开发）却硬套 TLS 配置，会直接报 connection error: desc = "transport: authentication handshake failed"；反过来，服务端开了 TLS 却只传 WithInsecure()，连都连不上。关键不在“安全不安全”，而在两端是否对齐。
- 本地调试、Docker Compose 内网通信、测试环境没配证书 → 用
WithInsecure()，但必须确认服务端也监听在非 TLS 端口（如:8080而非:443） - 生产环境、Kubernetes Ingress 后置、或服务明确要求 mTLS → 必须用
WithTransportCredentials(credentials.NewTLS(...))，且传入的*tls.Config要包含服务端 CA 证书（RootCAs），否则握手失败 - Go 1.20+ 默认禁用不安全的 TLS 版本和弱密码套件，如果服务端用的是老版本 OpenSSL，可能需要显式配置
MinVersion: tls.VersionTLS12
自定义 WithDialer() 绕过 DNS 或控制连接超时，但别漏掉 WithBlock()
常见需求是直连 Pod IP、跳过 DNS 解析，或者限制 dial 阶段最长等 3 秒。但只设 WithDialer() 不加 WithBlock()，grpc.Dial() 会立刻返回一个“正在后台建连”的 client，后续第一次 RPC 可能卡住或 panic。
-
WithDialer()的函数签名里，第三个参数timeout是单次 dial 的超时，不是整个连接建立上限；真正控制“阻塞直到连上或失败”的是WithBlock() - 若搭配
WithTimeout(5 * time.Second)初始化 client，但没加WithBlock()，超时只作用于 dial 函数本身，不保证 client 可用 - 示例：直连 10.1.2.3:9000 且最多等 2 秒：
grpc.Dial("10.1.2.3:9000", grpc.WithTransportCredentials(insecure.NewCredentials()), grpc.WithDialer(func(addr string, timeout time.Duration, _ func(network, addr string) (net.Conn, error)) (net.Conn, error) { return net.DialTimeout("tcp", addr, timeout) }), grpc.WithBlock(), grpc.WithTimeout(2*time.Second))
选项模式里传 WithUnaryInterceptor()，但拦截器没生效？检查顺序和嵌套层级
拦截器不触发，大概率是选项传错位置，或者多个拦截器互相覆盖。gRPC 的选项是按顺序应用的，且 WithUnaryInterceptor() 只影响 unary RPC，stream 类型得用 WithStreamInterceptor()。
- 拦截器函数必须符合
func(ctx context.Context, method string, req, reply interface{}, cc *ClientConn, invoker UnaryInvoker, opts ...CallOption) error签名，少一个参数类型就静默失效 - 如果同时用了
WithChainUnaryInterceptor()和WithUnaryInterceptor()，后者会被前者覆盖——因为链式拦截器内部会重置 unary 拦截器字段 - 日志类拦截器建议包一层
logrus.Entry或zap.Logger作为闭包变量传入，别在拦截器里现场取全局 logger，否则 context cancel 后可能 panic
用 WithKeepaliveParams() 控制心跳，但连接还是被中间设备断开
设置了 time.Second * 30 的 keepalive 时间，结果 5 分钟后请求仍报 rpc error: code = Unavailable desc = transport is closing，问题往往出在 LB 或防火墙的空闲连接踢出策略比 gRPC 更激进。
立即学习“go语言免费学习笔记（深入）”；
-
WithKeepaliveParams()里的Time是发送 keepalive ping 的间隔，Timeout是等待响应的超时，二者都要小于中间设备的 idle timeout（比如 AWS NLB 默认 350 秒） - 某些代理（如 Envoy）默认不转发 keepalive ping，需显式开启
http2_protocol_options: { keepalive: { ... } } - 更稳妥的做法是：客户端侧
Time设为 20s，Timeout设为 5s；服务端同步配keepalive.ServerParameters{MaxConnectionIdle: 30 * time.Second}，避免单边心跳
选项模式本身不难，难的是每个选项背后都绑着网络栈、TLS 握手、代理行为、甚至 Go runtime 的 goroutine 调度逻辑。改一个参数前，先想清楚它在哪个环节起作用、谁在看这个值、谁又可能把它忽略掉。
