优化Golang微服务网络通信需优先采用HTTP/2+gzip/zstd压缩响应体，并复用HTTP连接池；gRPC+Protobuf适用于高吞吐场景；须避免重复压缩、TLS层压缩及局部创建http.Client。
在 Golang 微服务架构中，优化网络通信的关键在于减少传输体积（压缩）和降低连接开销（复用），这两者能显著提升吞吐、降低延迟和节省资源。核心不是“要不要做”，而是“在哪做、怎么配、注意什么”。
优先用 HTTP/2 + gzip/zstd 压缩响应体
HTTP/2 天然支持多路复用和头部压缩，避免了 HTTP/1.1 的队头阻塞和重复连接；配合响应体压缩，可大幅减少带宽占用。Gin、Echo 等框架默认支持 HTTP/2（需启用 TLS），压缩需手动配置：
- 服务端：使用
gzip.Handler或更高效的zstd（如github.com/klauspost/compress/zstd）包装 handler，对 JSON/XML 等文本型响应启用压缩（二进制如 Protobuf 一般不压，本身已紧凑） - 客户端：确保请求头带上
Accept-Encoding: gzip,zstd，并正确解压响应（http.DefaultClient默认处理 gzip，zstd 需自定义Transport或手动解压） - 注意阈值：只压缩 >1KB 的响应，避免小数据压缩反而膨胀；禁用对 already-compressed 类型（如
image/*,application/pdf）的二次压缩
复用 HTTP 连接池，禁用短连接
每次请求新建 TCP 连接开销大（三次握手 + TLS 握手），尤其高频调用时。Go 的 http.Transport 提供连接池，必须显式调优：
- 设置
MaxIdleConns和MaxIdleConnsPerHost（建议 ≥20～50），避免连接频繁创建销毁 - 启用
KeepAlive（默认开启），并设合理IdleConnTimeout（如 30s）和TLSHandshakeTimeout（如 10s） - 微服务间调用务必复用同一个
*http.Client实例（全局或依赖注入），切勿为每次请求 new client - 若用 gRPC，其底层基于 HTTP/2，默认复用连接，只需关注
grpc.WithTransportCredentials和grpc.WithBlock()的合理性（生产环境避免阻塞初始化）
对高吞吐场景，考虑 Protocol Buffers + gRPC 流式通信
JSON over HTTP/1.1 或 HTTP/2 虽通用，但序列化/解析慢、体积大。gRPC（基于 Protobuf + HTTP/2）天然具备二进制高效编码、强类型、流式 RPC 等优势：
立即学习“go语言免费学习笔记（深入）”；
- Protobuf 序列化体积通常比 JSON 小 3–10 倍，解析快 2–5 倍
- gRPC 客户端自动管理连接池和重试，支持 unary、server-streaming、client-streaming、bidi-streaming
- 配合
grpc-go的WithKeepaliveParams可精细控制心跳与空闲超时，进一步保活长连接 - 注意：跨语言调用需生成对应语言 stub；调试不如 REST 直观，建议搭配
grpcurl或启用了反射的服务
避免压缩反模式和连接误用
常见踩坑点往往抵消优化效果：
- 在负载均衡层（如 Nginx）和应用层重复压缩——选一层即可，推荐应用层（更可控）
- 对 TLS 已加密流量再启用压缩（如早期 CRIME 攻击利用点），现代 Go 标准库已禁用 TLS 压缩，但自定义 crypto 层需确认关闭
- 把
http.Client当局部变量使用，导致连接池失效、TIME_WAIT 暴增 - 忽略服务发现与健康检查，连接池复用健康节点，但未及时剔除故障实例，造成请求堆积失败
不复杂但容易忽略：压缩和连接复用是基础项，真正起效依赖配置落地和监控验证。上线前用 net/http/pprof 查连接数、用 curl -v 看 Content-Encoding 和 Connection: keep-alive，再结合 Prometheus 抓取 http_client_duration_seconds 和 http_client_connections_idle，就能快速定位瓶颈。
