Go中需自实现带权重轮询：维护currentWeights数组，每次选最大值后减总权重、被选节点加自身权重；权重为正整数，需并发安全（推荐atomic），并正确改写req.URL.Host等字段对接RoundTripper。
Go 里怎么实现带权重的轮询（Weighted Round Robin）
直接用 net/http 自带的负载均衡器不行——它没权重支持。得自己写调度逻辑，核心是维护一个「当前权重」数组，每次选最大值，选完后减去总权重，被选中的节点加回自身权重。
常见错误是把「权重累加后随机选」当加权轮询，这会导致抖动大、分布不均；还有人用 rand.Intn() 按概率抽，本质是加权随机（Weighted Random），不是轮询，无法保证请求序列的平滑性。
- 权重必须是正整数，0 表示剔除节点（别设负数或浮点）
- 初始化时建议归一化：比如
[10, 20, 30]可缩为[1, 2, 3]，避免整数溢出 - 并发访问时，
currentWeights数组必须加锁，推荐用sync/atomic操作 int64 切片元素，比 mutex 更轻量
如何对接 http.RoundTripper 实现透明代理
Go 的 HTTP 客户端不直接暴露后端选择逻辑，得包装 http.RoundTripper，在 RoundTrip() 方法里做节点选取 + 请求改写。
典型坑是忘记重写 req.URL.Host 和 req.Host：不改的话，后端收到的 Host 头还是原始域名，可能 404 或路由错乱；另外，如果后端用 HTTPS，还得处理 req.URL.Scheme 从 http 改成 https。
立即学习“go语言免费学习笔记（深入）”；
- 用
url.URL解析目标节点地址，再用req.URL.Path拼接完整路径，别直接拼字符串 - 保留原始
User-Agent、X-Forwarded-For等头，但要覆盖Host和Connection - 不要在
RoundTrip()里做重试——那是上层逻辑，这里只负责「发给谁」和「怎么发」
为什么不用 nginx upstream？什么场景下 Go 自实现更合适
nginx 的 weight 是静态配置，reload 才生效；Go 实现可以动态调权（比如根据后端健康检查结果实时调整 weight 字段），适合需要秒级响应的服务治理场景。
但代价是：你得自己管连接池、超时、熔断、指标上报。nginx 开箱即用的 max_fails/fail_timeout 在 Go 里得靠 healthchecker 协程+原子计数器模拟，稍不注意就内存泄漏或 goroutine 泄漏。
- 小规模内部服务（
- 如果已有 nginx 做入口网关，Go 层再套一层加权转发属于冗余，反而增加延迟和故障点
- HTTP/2 或 gRPC 场景下，nginx 对 backend 的健康探测能力弱于 Go 自定义 client，这时值得自己写
weight=0 时的真实行为和 fallback 处理
weight=0 不等于“忽略”，而是参与调度但永远选不到——因为它的初始 currentWeight 是 0，而其他节点至少是正数。但如果所有节点 weight 都是 0，算法会卡死在无限循环里。
必须加兜底：遍历前先过滤出 weight > 0 的节点，为空时抛出明确错误（比如 ErrNoAvailableBackend），而不是静默 panic 或返回 nil。
- 别依赖 defer 恢复 panic 来兜底，HTTP handler 里 panic 会触发默认 500，掩盖真实问题
- 日志里记清楚当时各节点的
weight和currentWeight值，排查权重漂移时才看得见 - 如果用 Consul 或 Nacos 做服务发现，weight 字段来自元数据，要注意不同注册中心对空值/非法值的默认填充策略
