grpc客户端无需手动实现连接池，因*grpc.clientconn本身线程安全、可复用且内置http/2多路复用与连接管理；手动池易致泄漏、误关和并发竞争。
gRPC 客户端连接池必须显式初始化，不能复用 grpc.Dial 每次调用
微服务间高频调用下，反复调用 grpc.Dial 会导致文件描述符耗尽（too many open files），且连接未复用、重试逻辑缺失。这不是性能问题，是稳定性红线。
-
grpc.Dial返回的*grpc.ClientConn是长连接通道，应全局复用，而非每次 RPC 都新建 - 必须配
grpc.WithBlock()：否则首次连接失败时Invoke直接 panic，报rpc error: code = Unavailable desc = connection closed - 生产环境必须设
grpc.WithTransportCredentials；本地开发用insecure.NewCredentials()可以，但上线后若漏配 TLS，gRPC 会静默降级为明文，不报错也不连通 - 加
grpc.WithKeepaliveParams：K8s Pod 重启或网络抖动时，空闲连接靠 keepalive 探活，否则出现大量transport is closing
别用 Gin/Echo 封装服务间 HTTP 调用，用 net/http.Client + 自定义 http.Transport
Web 框架的便利性在服务间通信里全是陷阱：中间件链干扰超时控制、JSON 编解码隐藏错误细节、连接池不可控、可观测性字段无法注入。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
gin.Context无法直接透传context.WithTimeout，容易绕过超时导致级联雪崩 - 第三方 REST 接口返回 400 时，Gin 默认 JSON 解码会吞掉具体字段校验失败信息，只剩模糊的
json: cannot unmarshal - 默认
http.Client无连接池配置，高频调用下频繁建连，很快触发net/http: connection refused - OpenTelemetry 的 trace context 依赖
http.RoundTripper注入，Gin 中间件会覆盖原始 transport，导致 span 断链
http.Client 超时必须分三层设，不能只设一个 Timeout
单点超时既保不住下游，也救不了自己——3 秒总超时里，DNS 解析、TCP 建连、TLS 握手、首字节响应时间全混在一起，故障定位困难，熔断策略失效。
-
Timeout：整个请求生命周期上限，建议 ≤ 3s，防慢下游拖垮本服务 -
Transport.DialContext超时：控制 DNS + TCP + TLS 阶段，建议 ≤ 1s -
Transport.ResponseHeaderTimeout：从建连完成到收到响应头的时间，建议 ≤ 1.5s，避免卡在流式响应开头
订单服务聚合根必须隔离库存扣减，不能跨服务直连 DB
电商系统最常踩的坑：订单服务里直接查库存表、扣减库存字段。这破坏自治性，导致事务边界模糊、数据库锁竞争加剧、扩容受限。
- 订单服务只管生成订单状态和流水，不碰库存数据
- 库存扣减必须走独立
InventoryService的 gRPC 接口，哪怕只是同步调用 - 库存变更通过 Kafka 异步广播，订单服务监听事件更新自身缓存，避免强依赖
- 秒杀场景下，库存预扣必须用 Redis 原子操作（
DECR+EXPIRE），DB 层仅做最终一致性落库
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
