Go微服务依赖管理需显式控制连接行为、超时、重试、熔断与服务发现；HTTP/gRPC调用必须使用带截止时间的context，禁用硬编码地址，区分错误类型重试，保障幂等性，并通过真实业务路径健康检查。
Go 本身没有内置的“微服务依赖管理”机制——go mod 管理的是代码包依赖，不是运行时服务依赖。真正要控制的是服务间调用的**连接行为、超时、重试、熔断和发现方式**。
服务调用前必须显式配置超时与上下文取消
Go 的 http.Client 和 gRPC 客户端默认不设超时，一次卡死会拖垮整个调用链。所有出向请求都应绑定带截止时间的 context.Context。
- HTTP 调用：用
http.NewRequestWithContext()，不要用http.Get()这类便捷函数 - gRPC 调用：每个
CallOption都需传入grpc.WaitForReady(false)+grpc.Timeout(5 * time.Second) - 避免在 handler 中直接用
context.Background()构造子 context；应从入参ctx派生
req, _ := http.NewRequestWithContext(ctx, "GET", "http://user-svc:8080/profile/123", nil) resp, err := httpClient.Do(req) // httpClient 应复用，且 Transport 已配好 IdleConnTimeout
不要在代码里硬编码服务地址
写死 "http://order-svc:9001" 或 "order-svc:9001" 会导致环境迁移失败、无法做灰度、难以 mock 测试。
- 通过环境变量注入，如
ORDER_SERVICE_ADDR，启动时校验非空 - 或使用服务发现客户端（Consul、Nacos、etcd）动态拉取，但需封装重试+缓存逻辑，避免每次调用都查注册中心
- Kubernetes 环境下优先用 DNS 名（
order-svc.default.svc.cluster.local），由 kube-dns 解析，无需额外组件
重试策略必须按错误类型区分，不能无脑重试
对 400、404、501 这类语义明确的错误重试毫无意义；而连接拒绝、超时、503 才值得重试。gRPC 的 RetryPolicy 或 HTTP 中间件需精细控制。
立即学习“go语言免费学习笔记（深入）”；
- HTTP：用
retryablehttp.Client，设置RetryMax和RetryBackoff，并自定义CheckRetry函数过滤状态码 - gRPC：启用
grpc.WithDefaultCallOptions(grpc.RetryPolicy(...))，但注意 v1.54+ 后该 API 已标记为实验性，生产建议用中间件封装 - 幂等性必须由业务保证：GET /idempotent-order?token=xxx 比盲目重试 POST /order 更可靠
retryClient := retryablehttp.NewClient()
retryClient.RetryMax = 2
retryClient.CheckRetry = func(ctx context.Context, resp *http.Response, err error) bool {
if err != nil || resp.StatusCode == 400 || resp.StatusCode == 404 {
return false // 不重试
}
return resp.StatusCode >= 500
}依赖健康检查不能只 ping 端口，要走真实业务路径
只用 tcp.Dial 检查 order-svc:9001 是否通，掩盖了服务已启动但 DB 连接池耗尽、Redis 拒绝新连接等问题。
- 暴露
/health接口，内部执行关键依赖探活（如 SELECT 1、PING Redis、调用下游/ready） - 调用方在初始化 client 时，可同步发起一次
HEAD /health，失败则 panic 或降级到备用地址 - K8s 的
livenessProbe和readinessProbe应指向该接口，避免流量打入未就绪实例
最容易被忽略的是：依赖控制不是加几个库就能解决的，它要求每个服务明确声明自己依赖谁、以什么方式调用、失败后如何退化。一个没写 context.WithTimeout 的 HTTP 调用，可能让整个请求链在等待下游时静默卡住 30 秒——而监控里只看到“慢”，看不到根因。
