Go 标准库无 rand.Choice，需用 rand.Float64() 结合累积权重数组与二分查找实现加权随机选择；须过滤权重≤0项、避免浮点误差、支持动态更新。
Go 里用 rand.Choice？没有这个函数，别被误导
Go 标准库不提供开箱即用的加权随机选择函数，rand.Choice 是 Python 或其他语言的概念，硬套会直接编译失败。实际得靠 rand.Float64() + 累积权重手动实现。
常见错误是试图用 rand.Intn(len(servers)) 然后按权重重复塞数组（比如权重 3 就塞 3 次），这浪费内存、扩容慢、无法动态更新权重。
- 正确做法：预计算累积权重数组（如
[2, 5, 9]表示三台服务器权重 2/3/4），再用随机值二分查找落点 - 务必对权重做归一化或直接用整数累加——浮点误差在高并发下可能让最后一位永远选不到
- 如果服务器列表频繁增删，别每次重算整个累积数组；改用带平衡结构的库（如
github.com/emirpasic/gods/trees/redblacktree）代价太高，不如加读写锁+小批量更新
权重为 0 的服务器会被跳过，但得你自己写逻辑
标准加权算法默认假设所有权重 > 0。一旦某台机器临时下线、权重设为 0，不加判断就会导致 rand.Float64() * totalWeight 可能落在空区间，二分查找不到有效索引，panic 或死循环。
使用场景很现实：K8s 中 Pod 就绪探针失败时，你可能想把它的权重动态置 0，而不是立刻从列表里删除（避免重建累积数组）。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 构建累积数组前先过滤掉权重 ≤ 0 的项，或在查找后加校验：
if weight[i] - 不要依赖 “权重和为 0 时返回空” 这种行为——
totalWeight == 0时rand.Float64() * 0恒为 0，容易误命中第一个元素 - 建议在选取前加兜底：
if len(validServers) == 0 { return nil, errors.New("no available server") }
并发安全不能靠运气，sync.RWMutex 得锁对地方
负载均衡器实例通常是全局单例，权重可能由健康检查 goroutine 动态更新，而请求路由在 HTTP handler 中高频读取——读多写少，但写操作（如更新某台机器权重）必须原子。
容易踩的坑是只给“更新权重”上锁，却忘了“构建累积数组”这个动作本身也依赖当前全部权重快照。如果写锁只包住单个 weights[i] = newW，读侧可能拿到新旧混杂的中间态。
- 读操作（选服务器）只需
RLock()，但必须确保读的是完整、不可变的累积数组副本 - 写操作应锁住整个权重切片更新 + 重建累积数组两个步骤，然后原子替换指针：
lb.mu.Lock(); lb.cumulative = rebuild(lb.weights); lb.mu.Unlock() - 别用
sync.Map存权重——它适合键值独立更新，不适合需要整体一致性的累积计算
测试时用固定 seed，否则权重偏差根本看不出来
加权随机算法的正确性没法靠单次运行验证。跑 10 次选中 A 7 次，不代表权重设置对了；可能只是随机数碰巧集中。真正要看的是大样本分布是否趋近理论概率。
性能影响常被忽略：每万次请求做一次二分查找（O(log n)）完全没问题，但如果用线性扫描（O(n)），节点超 100 个时延迟毛刺明显。
- 单元测试第一行必须是
rand.Seed(42)（或任何固定值），再跑 10000 次统计频次，和期望值比对误差是否 - 用
sort.Search而不是手写二分——少一个等号就可能越界，而且可读性差 - 如果权重变化极少（如配置启动时定死），把累积数组做成
sync.Once初始化，避免每次请求都检查是否要重建
事情说清了就结束。最麻烦的从来不是算法本身，而是权重怎么来、什么时候变、变了之后怎么不卡住读请求——这些没对齐，再漂亮的二分也没用。
