HTTP客户端未设超时和连接池参数易致延迟突增；gRPC需禁用WithBlock并为每次调用设独立超时；JSON序列化应换jsoniter并避免map[string]interface{}；context中少用WithValue嵌套，改用自定义key类型。
为什么 http.DefaultClient 在微服务间调用时容易拖慢响应
默认的 http.Client 没有设置超时、连接复用限制松散、空闲连接不及时回收，导致在高并发微服务调用中频繁新建 TCP 连接，或卡在等待旧连接释放上。常见现象是 P95 延迟突增、偶发 2–3 秒超时，但日志里查不到明确错误。
-
Timeout和IdleConnTimeout必须显式设值，否则依赖系统默认（可能长达 30 秒） -
MaxIdleConns和MaxIdleConnsPerHost不设会导致连接池无上限，内存涨+调度开销大 - 复用
http.Client实例，不要每次请求都&http.Client{}新建
client := &http.Client{
Timeout: 3 * time.Second,
Transport: &http.Transport{
IdleConnTimeout: 30 * time.Second,
MaxIdleConns: 100,
MaxIdleConnsPerHost: 100,
TLSHandshakeTimeout: 3 * time.Second,
ExpectContinueTimeout: 1 * time.Second,
},
}gRPC 调用延迟高，先检查 WithBlock() 和 WithTimeout() 的组合用法
同步阻塞式 Dial（grpc.WithBlock()）在 DNS 解析慢、后端未就绪时会卡死整个连接初始化过程；而 WithTimeout() 若只设在 Dial() 阶段，无法约束后续 RPC 调用本身的耗时。
- 生产环境禁用
WithBlock()，改用异步连接 + 健康检查兜底 - 每个
ctx传入grpc.Invoke()或grpc.NewStream()时，必须带独立超时：如ctx, cancel := context.WithTimeout(ctx, 800*time.Millisecond) - 避免全局共用一个 long-lived
context.Background()作 gRPC 上下文
JSON 序列化成性能瓶颈？换 jsoniter 并禁用反射
标准 encoding/json 在 struct 字段多、嵌套深时，反射开销显著；微服务高频小 payload 场景下，序列化/反序列化可占单次调用耗时 15%–40%。
- 用
jsoniter.ConfigCompatibleWithStandardLibrary替代原生包，零代码改动即可提速 2–3 倍 - 若可控结构体定义，加
//go:generate jsoniter -i $GOFILE生成静态编解码器（需配合jsoniter.RegisterTypeEncoder注册） - 禁止对 map[string]interface{} 频繁编解码——它强制走反射路径，换成预定义 struct
跨服务传递 traceID 时，别在 context.WithValue() 里塞字符串切片
看似只是存个 ID，但若中间件层层 WithValue() 堆叠（比如鉴权→限流→日志→metric），context 内部会形成链表，每次 Value() 查找都是 O(n)。实测 5 层嵌套后，取值耗时从 20ns 升至 300ns+。
立即学习“go语言免费学习笔记（深入）”；
- 只存必要字段：traceID、spanID、采样标志，且用自定义 key 类型（非
string）避免冲突 - 用
context.WithValue(ctx, traceKey, "abc123")，其中traceKey是 unexported struct{} 变量 - 避免在 HTTP handler 中反复
context.WithValue(r.Context(), ...)—— 提前在 middleware 里注入一次即可
Golang 微服务延迟优化不是堆参数，而是揪出那几个「默认放任不管就会出事」的点：HTTP 客户端配置、gRPC 上下文生命周期、序列化路径、context 使用方式。这些地方一旦写错，压测时看不出问题，上线后流量一波动就暴露。
