go无开箱即用负载均衡器，需基于httputil.newsinglehostreverseproxy自研；注意url格式、header克隆、健康检查、线程安全轮询及故障传播控制。
Go 本身不提供开箱即用的「负载均衡器」组件，net/http 的 Server 是单实例 HTTP 服务，要实现负载均衡，必须自己构造反向代理逻辑或集成第三方库——这不是语法问题，而是架构选择问题。
用 httputil.NewSingleHostReverseProxy 做基础反代
这是最轻量、最可控的起点。Go 标准库的 httputil 提供了可定制的反向代理能力，但注意：它默认只支持单后端，多后端需手动轮询或加策略。
-
NewSingleHostReverseProxy接收一个*url.URL，不是字符串；传错会 panic，常见错误是漏掉http://前缀导致parse "127.0.0.1:8080": first path segment in URL cannot contain colon - 每次请求都要克隆
req.Header，否则多个 goroutine 并发修改会引发 data race；标准写法是req = req.Clone(req.Context()) - 后端健康检查需自行实现，
ReverseProxy不自动剔除宕机节点；简单轮询下，一个挂掉就会持续返回 5xx
实现轮询（Round Robin）需自己维护后端列表和状态
没有全局锁、不带重试、不处理连接超时的轮询很容易写出线程不安全或阻塞版本。
- 用
sync/atomic管理当前索引比sync.Mutex更轻量，例如：idx := atomic.AddUint64(&rr.counter, 1) % uint64(len(rr.backends)) - 后端地址建议封装为结构体，包含
*url.URL和healthy bool字段，避免每次都在字符串和 URL 间转换 - 不要在
Director函数里做网络 I/O（比如调用http.Head检查健康），这会让每个请求都变慢；健康检查应走独立 goroutine 定期探测
为什么不用 gorilla/reverseproxy 或 traefik？
第三方库确实省事，但引入它们往往带来隐式复杂度：
-
gorilla/reverseproxy已归档，不再维护；其 fork 版本如goproxy缺少文档，Director行为与标准库不一致，容易踩到 header 透传 bug -
traefik或nginx是完整控制平面，适合生产网关，但作为嵌入式 LB 过重——你只是想把流量分给 3 个本地http.Server，却要学 ACME、middleware chain、dynamic config - 真正需要的是「可调试、可打点、可灰度」的小型 LB，这种场景下，百行以内的自研反代 +
expvar暴露计数器，比 YAML 配置更可靠
负载均衡真正的难点不在转发逻辑，而在故障传播控制：超时怎么设、重试几次、是否重试幂等请求、后端失败时如何降级返回缓存或兜底页——这些没法靠一个 RoundRobin 结构体解决，得结合业务语义来定。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
