必须用 context.withtimeout 控制 rpc 调用生命周期，http/grpc 均需传入 ctx；合理设超时（略大于 p95）、避免 handler 阻塞、复用 grpc 连接并配置 keepalive、干预 dns 解析与缓存。
用 context.WithTimeout 主动控制 RPC 调用生命周期
微服务间调用不设超时，是延迟雪崩最常见的起点。Go 的 net/http 和 gRPC 默认无超时，一旦下游卡住或网络抖动，上游 goroutine 就会无限等待，连接池耗尽、内存上涨、请求堆积。
必须在每次发起调用前绑定带截止时间的 context：
ctx, cancel := context.WithTimeout(parentCtx, 2*time.Second) defer cancel() resp, err := client.DoSomething(ctx, req)
注意：context.WithDeadline 和 context.WithTimeout 效果等价，但后者更直观；cancel() 一定要 defer，否则可能泄漏 timer。
- HTTP 客户端需传入
ctx到Do()，不能只设http.Client.Timeout—— 后者只管连接建立和读响应头，不覆盖整个请求周期 - gRPC 客户端必须把
ctx传给每个方法调用，如client.GetUser(ctx, req)；仅设置grpc.Dial(..., grpc.WithBlock())无法替代业务层超时 - 超时值不是越小越好：要略大于 P95 延迟（比如压测得到下游 P95 是 800ms，可设 1.2s），太激进会导致正常慢请求被误杀
避免在 HTTP handler 中直接调用长耗时下游服务
Go 的 HTTP server 默认复用 goroutine 处理请求，如果在 http.HandlerFunc 里同步调用一个平均耗时 1.5s 的 gRPC 接口，那么该 goroutine 在这 1.5s 内无法处理新请求，QPS 直接受限。
立即学习“go语言免费学习笔记（深入）”；
这不是并发模型问题，而是阻塞点没做解耦：
- 对非关键路径（如埋点、日志上报、异步通知），改用
go func() { ... }()启动协程，但务必加context控制生命周期，避免 goroutine 泄漏 - 对必须同步返回的调用，确保已设合理超时，并考虑是否能降级（例如缓存兜底、返回默认值）
- 禁止在 handler 里做数据库直连查询 + 下游 HTTP 调用 + 文件 IO 的三连操作——这类组合延迟不可控，应拆成独立服务或预加载
gRPC 连接复用与 Keepalive 配置不当会放大延迟波动
短连接频繁重建会引入 DNS 查询、TCP 握手、TLS 协商开销，实测在跨 AZ 场景下单次新建连接可能增加 50–200ms 延迟。而长连接若未配置 keepalive，中间网络设备（如 SLB、NAT 网关）可能在空闲 60s 后静默断连，导致下一次调用触发重连并失败。
正确做法是复用 *grpc.ClientConn 实例，并开启保活：
conn, err := grpc.Dial("backend:9000",
grpc.WithTransportCredentials(insecure.NewCredentials()),
grpc.WithKeepaliveParams(keepalive.ClientParameters{
Time: 30 * time.Second,
Timeout: 5 * time.Second,
PermitWithoutStream: true,
}),
)-
Time设为小于中间设备 idle timeout（通常查云厂商文档，AWS NLB 是 3500s，阿里云 SLB 默认 60s，所以设 30s 较安全） -
PermitWithoutStream: true允许在无活跃 stream 时也发 keepalive ping，否则空闲连接不会触发探测 - 不要为每个请求新建
grpc.Dial，应在应用启动时初始化连接并全局复用
忽略 DNS 缓存与解析失败重试机制
Go 默认使用系统 DNS 解析器，net.Resolver 不缓存结果，每次 grpc.Dial 或 http.Get 都可能触发一次 DNS 查询。若 DNS 服务不稳定，单次解析失败就会拖慢整个请求，且 Go 标准库默认不重试（glibc 可能重试，但 musl 不会）。
生产环境必须干预：
- 使用
grpc.WithResolvers配合自定义 resolver，或直接在服务发现层（如 Consul、Nacos）做客户端缓存 + TTL 刷新 - HTTP 客户端可通过
http.DefaultClient.Transport.(*http.Transport).DialContext注入带本地缓存的net.Dialer - 避免在代码里硬编码 IP 或域名字符串，尤其不要写
"http://user-service:8080"—— 应通过环境变量或配置中心注入解析后地址
延迟问题从来不是单点故障，而是多个看似“应该没问题”的默认行为叠加后的必然结果。最常被跳过的其实是 DNS 缓存和 keepalive 配置，它们不出错时不显眼，一出错就表现为随机性高延迟，排查成本远高于提前加几行配置。
