go语言无内置负载均衡框架，需手动实现：用httputil.newsinglehostreverseproxy配合自定义director和原子轮询选后端，重设url.scheme/host/path；gorilla/reverseproxy权重仅初始化生效且需显式配transport；grpc须用grpc.withbalancername("round_robin")及dns格式地址。
Go 语言本身没有“框架级负载均衡配置”这回事——所谓“负载均衡”，要么在 Go 进程外（如 Traefik、Envoy、Nginx），要么在 Go 进程内手动控制请求转发逻辑，不存在开个配置项就自动生效的魔法。
httputil.NewSingleHostReverseProxy 怎么改成多后端轮询
标准库 httputil.NewSingleHostReverseProxy 只接受一个 *url.URL，硬塞多个地址会 panic。必须自己实现 Director 函数，并用原子计数器选节点：
- 后端列表要用
[]*url.URL初始化，不能传字符串切片；否则req.URL.Host会被设成空，请求发到本地导致connection refused -
Director中必须重写req.URL.Scheme、req.URL.Host和req.URL.Path，尤其注意路径拼接：用singleJoiningSlash(u.Path, req.URL.Path)避免双/api/v1/api/v1 - 别复用同一个
http.Transport实例处理健康检查和代理流量——健康检查应走短连接，否则探活失败可能卡住主代理的连接池
gorilla/reverseproxy 的权重和 KeepAlive 为什么不生效
这个库封装了多后端和权重字段，但实际运行时容易踩两个坑：
-
Weight字段只在初始化时读取一次，运行时改结构体字段值完全无效；要动态调权，得重建整个Proxy实例并热替换 - 默认没开启连接复用：
http.Transport没配MaxIdleConns和MaxIdleConnsPerHost，高并发下很快触发too many open files；生产建议设MaxIdleConns = 1000、MaxIdleConnsPerHost = 200 - 它的
Director签名是func(*http.Request)，和标准库httputil.ProxyRequest不兼容，直接套用会编译失败
gRPC 客户端怎么启用 round_robin 负载均衡
HTTP 负载均衡靠自己写转发逻辑，但 gRPC 官方已内置支持，只要正确配置 Dial 参数：
- 必须用
grpc.WithBalancerName("round_robin")，不是"RoundRobin"或其他大小写变体；否则 fallback 到 pick_first - 目标地址必须用 DNS 解析格式，例如
"dns:///user-service.default.svc.cluster.local"；写成"user-service:8080"会跳过服务发现，始终打到第一个解析出的 IP - 如果后端启用了 TLS，需额外传
grpc.WithTransportCredentials(credentials.NewTLS(...))，否则握手失败报x509: certificate signed by unknown authority
Kubernetes 下 Go 服务扩容后流量不均的常见原因
扩容 5 个副本，但 80% 流量全打到其中 1 个实例上？大概率不是 Go 代码问题，而是基础设施层没对齐：
- 没暴露
/readyz接口，或返回非 200，K8s Service 的 Endpoint 列表里压根没加新 Pod，流量自然进不去 - 就绪探针（readinessProbe）超时时间设得太长（比如 10s），而 Pod 启动实际只要 2s，导致 K8s 认为它“还没准备好”，持续漏掉流量
- Service 的
sessionAffinity: ClientIP开着，且没配sessionAffinityConfig，小规模集群中 IP 哈希容易集中到单个后端 - 客户端（比如前端或另一个微服务）自己做了 HTTP 连接池复用，没走 K8s Service DNS，而是直连某个旧 Pod IP，扩容后也没刷新连接
真正难的不是写几行轮询代码，而是让健康检查不误判、连接池不泄漏、TLS 握手不静默失败、K8s 探针不拖后腿——这些细节堆在一起，才构成一个能跑通的负载均衡链路。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
