net/http 本身不支持权重调度，其 Handler 仅处理请求，不管理后端实例流量分配；需额外实现配置查询、权重计算与目标选择逻辑，否则无法动态分流。
为什么直接用 net/http 做路由转发不够用
因为权重调度不是 http 路由本身的能力，net/http 的 handler 只负责处理请求，不管理后端实例的流量分配。你得在转发前插入一层决策逻辑：收到请求后，查配置、算权重、选目标地址。否则所有请求都走固定 roundtrip，根本谈不上“动态”。
常见错误是把权重写死在代码里，比如用 if rand.Float64() 模拟 7:3，但这样改权重就得重新编译上线；或者用全局变量存权重 map，却没加锁，导致并发更新时 <code>map iteration modified concurrently panic。
实操建议：
- 权重配置必须可热更新，推荐用
sync.Map存服务名 → 权重切片（含地址和 weight 字段），避免读写锁阻塞 - 不要在每次请求里解析 YAML/JSON 配置，而是起一个 goroutine 监听文件变化或配置中心（如 etcd），只在变更时重建权重结构
- 权重归一化要放在加载阶段做，而不是每次选节点都算 sum，否则高并发下重复浮点运算+循环求和会拖慢延迟
如何用 http.RoundTripper 实现带权重的负载均衡
Go 的 http.Transport 是默认 RoundTripper，但它只管连接复用和超时，不参与目标选择。你需要包装它：自己实现 RoundTrip 方法，在里面调用权重选择逻辑，再把请求交给下游 Transport。
关键点在于「选节点」不能只看权重数值，还要考虑健康状态。比如某节点权重 50，但连续 3 次失败，就该临时剔除。这时候需要维护一个带状态的节点列表，而不仅是静态配置。
实操建议：
- 定义结构体
WeightedBackend，字段包含Addr string、Weight int、FailCount uint32、LastFailTime time.Time - 选节点时先过滤掉
FailCount > 0 && time.Since(LastFailTime) 的节点，再对剩余节点做加权随机（例如 alias method 或累积权重二分） - 每次
RoundTrip返回非 nil error 且是连接类错误（如net.OpError、context.DeadlineExceeded）时，原子递增对应节点的FailCount - 成功响应后，记得用
atomic.StoreUint32(&node.FailCount, 0)清零，别漏掉
配置热更新时怎么避免请求中断或脏读
最典型的坑是：新配置刚加载完，旧的 http.Client 还在用老的 RoundTripper，或者多个 goroutine 同时读写权重 map 导致 panic。Go 没有“原子替换整个结构”的内置机制，得靠设计规避。
实操建议：
- 把整个权重数据封装成不可变结构（例如
type WeightConfig struct { Backends []Backend }），每次更新都生成新实例，用atomic.Value存储指针 - 在
RoundTrip开头调用v.Load().(*WeightConfig)获取当前快照，全程只读，完全避免锁 - 配置监听 goroutine 里，先解析新配置 → 构建新
WeightConfig→ 调用v.Store(newCfg)，三步必须原子完成 - 别用
os.Notify捕获 SIGHUP 做 reload，容易和 k8s 的 liveness probe 冲突；改用 inotify 或定期 stat 文件 mtime
为什么不用第三方库如 gorilla/handlers 或 traefik
它们要么不支持运行时权重调整（gorilla/handlers 的 ProxyHandler 是静态转发），要么太重（traefik 自带 UI、metrics、CRD，你只是想嵌入一个轻量网关模块）。如果你的网关要跑在边缘设备或函数计算里，启动一个 traefik 实例比业务代码还占内存。
更现实的问题是调试成本：traefik 报错时日志里一堆中间件链路，你根本不知道是你的权重配置格式错了，还是它内部的 consul watcher 失败了。而自己写的 RoundTripper，panic 直接打在你自己的代码行号上。
实操建议：
- 如果团队已有 Istio，优先用 VirtualService 的
weight字段，别重复造轮子 - 如果必须自研，控制核心逻辑在 200 行以内，把健康检查、权重计算、转发三块拆成独立函数，方便单元测试
- 留一个 debug 接口（如
/debug/backends），返回当前生效的后端列表和权重，别等线上出问题才去 ssh 查进程
权重配置真正难的不是算法，而是怎么让“动态”不变成“不可控”——配置推送到一半时请求进来了怎么办，节点反复上下线导致权重抖动怎么抑制，失败熔断后恢复的时机怎么定。这些边界情况比选哪个随机算法重要得多。
