Go服务发现网关需自行实现动态权重支持，因net/http.RoundTripper默认不感知实例权重；必须在每次请求时通过加权轮询等策略实时解析并联动服务发现列表，否则权重字段形同虚设。
Go 服务发现网关本身不内置动态权重支持，必须自己实现权重解析、实时更新和负载均衡策略的联动 —— 否则注册中心传来的权重只是摆设。
为什么 net/http.RoundTripper 默认不感知服务实例权重
标准 HTTP 客户端底层用 http.Transport 管理连接池，它只按域名做连接复用，完全不关心后端节点是否有权重、是否在线、是否刚被降权。你传给 http.Client 的是一个固定 *url.URL，它不会自动从服务发现列表里挑“权重最高的那个”。
- 常见错误：把服务名直接塞进
http.Client的Transport.DialContext，却没在每次请求前查一次带权重的实例列表 - 真实场景：Eureka/Nacos 返回的实例列表含
weight字段（如 Nacos 的metadata.weight），但 Go SDK 通常不自动映射该字段到结构体 - 关键点：权重决策必须发生在每次请求路由时，不能只在初始化时做一次快照
用 roundrobin + 权重采样实现可热更的负载均衡器
别写复杂算法，用「加权轮询（Weighted Round Robin）」最稳妥：先按权重展开成虚拟节点列表，再用原子计数器轮询 —— 支持运行时替换整个节点列表，天然支持动态权重变更。
- 示例逻辑：
["a:8080"(w=3), "b:8080"(w=1)]→ 展开为["a","a","a","b"]，每次取atomic.AddUint64(&idx, 1) % len(list) - 注意：权重必须是整数，且不宜过大（避免内存膨胀），建议归一化到 1–100 范围
- 更新时机：监听服务发现事件（如 Nacos 的
Watch回调），收到新实例列表后，原子替换内部[][]string或预构建的[]*instance - 不要在
RoundTrip里做锁或网络调用，否则拖慢整个网关吞吐
如何让服务发现客户端输出带权重的实例列表
Nacos 和 Consul 的 Go SDK 默认不暴露权重字段，得手动解析元数据；Eureka 更麻烦，权重得靠自定义 metadata 注入。
- Nacos：检查返回的
nacos_client.Instance结构体，读Instance.Metadata["weight"]，转成int；若为空，默认设为 1 - Consul：用
api.Health().Service(..., true)获取健康服务，遍历Checks找ServiceMeta里的weight - Eureka：注册时必须显式设置
metadata，例如{"weight": "5"}，客户端需从InstanceInfo.Metadata提取 - 坑点：不同注册中心对权重字段命名不一致（
weight/priority/loadFactor），建议统一封装一层GetWeight(inst interface{}) int
网关路由层如何安全注入动态权重逻辑
别改 http.ServeMux，用中间件模式，在 http.Handler 的 ServeHTTP 里做实例选择和反向代理。
- 核心结构体：定义
type WeightedBalancer struct { instances atomic.Value }，instances存[]*weightedInstance - 每次请求：调用
balancer.Next()拿一个实例，构造*httputil.ReverseProxy的Director函数，改写req.URL.Host - 务必加 panic 恢复：如果权重列表为空，
Next()必须返回默认实例或返回 503，不能 panic 导致整个网关挂掉 - 调试技巧：在日志里打上
reqID → instance:port (weight=3)，比看 metrics 更快定位权重没生效的问题
权重不是配置写进去就完事的，它必须贯穿「发现→解析→加载→路由→上报」全链路；最容易漏的是注册中心元数据字段没正确提取，或者更新实例列表时没用原子操作，导致某次请求看到新旧混合的权重状态。
