grpc内置round_robin轮询策略在实例动态变化时失效，因其仅在dial初始化时获取一次地址列表，不感知服务发现变更；需配合支持watch的resolver并主动调用updatestate()，且权重更新须原子操作、实例列表不可缓存副本、ttl宜设5~10秒。
gRPC内置轮询策略为什么在实例动态变化时失效
因为round_robin策略本身不感知服务发现变更——它只在grpc.Dial初始化时从resolver拿到一次地址列表，后续即使注册中心更新了实例，客户端也不会自动刷新balancer内部的节点池。
常见错误现象：rpc error: code = Unavailable desc = connection refused持续出现，但Consul里该实例早已下线；或新扩容的实例长期收不到请求。
- 必须配合支持watch机制的
resolver（如etcd或Consul resolver），且resolver需主动触发cc.UpdateState() - 不能依赖
grpc.WithDefaultServiceConfig里的静态配置，要确保resolver返回的resolver.Address包含ServerName和健康元数据 - gRPC v1.60+默认禁用
pick_first作为fallback，若resolver未正确上报状态，round_robin可能卡在空列表上
加权轮询实现中权重更新不生效的典型原因
权重不是写死在代码里的数字，而是需要随实例健康度、响应延迟等指标实时调整——但多数人只做了“读取权重”，没做“原子更新权重”。
使用场景：某服务实例CPU使用率飙升到95%，应临时将其权重从Weight: 10降到Weight: 2，但请求仍按旧权重分发。
-
Weight字段必须存在并发安全的更新路径，比如用atomic.StoreInt64(&inst.Weight, newWeight)而非直接赋值 - 轮询逻辑里不能缓存
instances切片副本，否则权重变更无法被Select()函数看到；应通过atomic.Value包裹整个实例列表 - 权重归一化计算（如总权重为100）要在每次
Select()前重算，避免浮点精度累积误差导致分配倾斜
本地缓存服务实例列表时TTL设置过长的后果
缓存不是越久越好。TTL设成30秒看似稳妥，但在高频扩缩容场景下，会导致最多30秒内请求持续打到已下线的IP上。
性能影响：单个实例宕机后，平均失败率上升12%~18%，重试放大网络压力；更糟的是，缓存未失效期间，健康检查结果也被忽略。
- TTL建议设为
5s ~ 10s，配合长轮询（watch）机制——缓存仅作兜底，变更由事件驱动实时更新 - 缓存key必须包含服务名+集群标识（如
"user-service-prod"），避免跨环境混用 - 不要用
time.Now().Unix()做简单过期判断，应使用time.Since(entry.timestamp) ，防止系统时间回拨导致缓存永久有效
最少连接数策略在HTTP长连接场景下的陷阱
LeastConnections听起来很合理，但HTTP/1.1默认复用连接，net/http.Transport维护的连接池会让“当前连接数”严重失真——一个实例可能只维持2个TCP连接，却承载了200个并发HTTP请求。
真实错误现象：监控显示A实例连接数=3，B实例=5，但A的CPU已达90%，B才30%；负载反而往A上倾斜。
- 不要直接统计
http.Transport.IdleConn，而应对接应用层指标（如Prometheus暴露的http_in_flight_requests） - 若必须用连接数，需在HTTP client层透出每个host的活跃请求数（例如用
RoundTripper包装器计数） - 优先考虑
LeastLoad变种：综合响应延迟、错误率、CPU使用率加权计算“负载分值”，比单纯连接数更可靠
Select()调用时并不等待检查结果——这意味着刚被标记为“不健康”的实例，下一毫秒还可能被选中。真正有效的做法是，在Select()入口处同步校验最近一次检查时间戳是否超限，并跳过过期节点，而不是依赖后台清理。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
