grpc通信需显式管理连接生命周期，生产环境禁用insecure并复用clientconn；服务发现优先etcd而非dns；http客户端须自定义配置；context必须全程透传以保障超时、取消及链路追踪有效性。
gRPC 通信必须显式处理连接生命周期
Go 的 grpc.Dial 默认不自动重连，服务端短暂不可用会导致客户端 panic 或阻塞。这不是 bug，而是设计选择：gRPC 希望你主动管理连接状态。
- 使用
grpc.WithTransportCredentials(insecure.NewCredentials())仅用于本地开发；生产环境必须配tls.Config，否则grpc.Dial会静默失败（尤其在 Kubernetes 中） - 连接应复用，避免每次请求都调
grpc.Dial；推荐在 service 初始化时建立单例*grpc.ClientConn，并用defer conn.Close()确保释放 - 加
grpc.WithBlock()会让Dial同步等待连接就绪，但可能卡死；更稳妥的是用grpc.WithTimeout()+ 异步重试逻辑
服务发现不能只靠 DNS，etcd 是更可控的选择
Kubernetes Service DNS 解析延迟高、TTL 不可控，且无法表达实例健康状态。真实微服务场景中，DNS 只能作 fallback，不能当主发现机制。
- 用
go.etcd.io/etcd/client/v3实现注册：服务启动时写入 key/services/order/{ip:port}，带 TTL；退出前主动 Delete，或依赖 TTL 自动过期 - 客户端监听
/services/order/前缀，用client.Watch获取实时变更，缓存健康节点列表，再配合 round-robin 或 least-loaded 做负载均衡 - 别直接把 etcd 地址硬编码进代码；通过环境变量传入，例如
ETCD_ENDPOINTS=etcd1:2379,etcd2:2379
HTTP/JSON API 调用要绕过 net/http 默认限制
Go 标准库的 http.DefaultClient 对并发连接数、空闲连接、超时控制非常保守，微服务高频调用下极易出现 dial tcp i/o timeout 或 too many open files。
- 自定义
http.Client：设置Timeout（建议 ≤ 3s）、MaxIdleConns（≥ 100）、MaxIdleConnsPerHost（≥ 100），并启用KeepAlive - 不要用
http.Get这类快捷函数，它们强制复用DefaultClient，而你无法修改其 Transport - 若调用第三方 HTTP 服务（如支付网关），务必单独配置 client，避免和内部 gRPC 流量争抢连接池
Context 传递必须贯穿全链路，否则超时和取消会失效
微服务调用链中，任意一环漏传 context.Context，上游发起的 cancel 就会断在那一层，下游继续执行，造成资源泄漏和雪崩。
立即学习“go语言免费学习笔记（深入）”；
- 所有对外 RPC 方法签名必须以
ctx context.Context开头；gRPC server 端用ctx := req.Context()接收，client 端用ctx, cancel := context.WithTimeout(ctx, 2*time.Second)控制本跳超时 - HTTP handler 中，从
r.Context()拿到 ctx，再透传给下游 gRPC 或 HTTP client；别用context.Background()替代 - 日志、metrics、tracing 的上下文绑定（如
log.WithContext(ctx)）也依赖这个 ctx，否则 trace ID 会丢失
