容器中go微服务网络性能差主因是net.conn未复用、http.transport配置错误或grpc.dial频繁调用，易触发“too many open files”或“cannot assign requested address”，需显式配置连接池、keepalive及分层超时。
容器里Go微服务的网络性能差，八成不是代码问题，而是net.Conn没复用、http.Transport配错了、或grpc.Dial被反复调用——这些在宿主机上不明显的问题，在容器里会立刻触发too many open files或connect: cannot assign requested address。
HTTP客户端必须显式配置http.Transport
默认http.DefaultClient在容器中极易耗尽文件描述符：ulimit 1024 下，几十个并发请求就可能打满。它默认MaxIdleConns和MaxIdleConnsPerHost都是0，意味着不复用连接。
- 务必禁用
DisableKeepAlives: true（常见误设） - 显式设置
MaxIdleConns和MaxIdleConnsPerHost，例如都设为100 - 设置
IdleConnTimeout（如30s），避免空闲连接长期占位 - 若服务间调用固定，可考虑用
http.RoundTripper封装复用逻辑，而非每次新建http.Client
gRPC连接池要全局复用且配keepalive
跨机房或Service Mesh场景下，grpc.Dial若每次请求都调用，会导致TCP重建+TLS协商+DNS解析叠加，单次延迟飙升150–300ms。更糟的是，未配keepalive时，SLB/NAT网关60秒静默断连，下次请求必重连。
-
grpc.Dial只应在启动时调用一次，返回的*grpc.ClientConn全局复用 - 必须传
grpc.WithKeepaliveParams，Time建议30s，Timeout设10s，避免被防火墙限频 - 服务端同步配
keepalive.ServerParameters，否则客户端保活无效 - 避免用
context.Background()传给client.Method()，每个调用必须带context.WithTimeout，值略大于下游P95（如P95=950ms → 设1200ms）
容器内无法改内核参数，得从socket层绕过
想调/proc/sys/net/ipv4/tcp_tw_reuse？Docker默认不挂载/proc/sys为可写，且该参数对单个连接无效。错误地在entrypoint里加sysctl -w只会失败并掩盖真实问题。
- 对
net.Listener或net.Conn底层调用SetKeepAlive(true)和SetKeepAlivePeriod(30*time.Second) - 若用
http.Server，可通过自定义net.Listener在Accept后对conn.(*net.TCPConn)设选项 - 用
golang.org/x/net/http2时需谨慎：高并发短连接（如Istio sidecar）下，HTTP/2多路复用反而因流控缓冲积累引发延迟毛刺
DNS解析不能依赖系统缓存
容器里getaddrinfo行为不可控：glibc缓存TTL、macOS有独立缓存，且无法感知DNS记录变更。一旦解析到已下线实例IP，就会随机超时或connection refused。
- 用
grpc.WithResolvers替换默认resolver，自己实现Resolver接口 - resolver内部调用
net.DefaultResolver.LookupHost并设Context超时（如2s），防卡死 - 缓存DNS结果时，严格按DNS记录原始
TTL过期，不用固定时间 - HTTP场景同理，可用
http.Transport.DialContext注入自定义DNS逻辑
最常被忽略的一点：所有超时控制必须分层——http.Client.Timeout只管建连和读header，grpc.Dial的timeout只管建连，真正业务调用的deadline必须靠context.WithTimeout层层透传，漏一层就可能goroutine泄漏或雪崩扩散。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
