直接用 rand.Float64() 累加权重会出错，因浮点精度累积误差导致最后一项常抽不到，且权重为0时未跳过易引发逻辑错误；更隐蔽的是 int64 权重总和超 math.MaxFloat64 时转 float 失真。
为什么直接用 rand.Float64() 累加权重会出错
很多人一上来就写个循环，对每个奖品的权重除以总和算概率，再用 rand.Float64() 生成 [0,1) 的数去比——这本身没错，但容易忽略两个关键点：浮点精度累积误差导致最后一项永远抽不到，以及权重为 0 时没做跳过处理。更隐蔽的问题是，如果权重是 int64 且总和超 math.MaxFloat64（虽然少见），转成 float 会失真。
实操建议：
- 用整数累加法替代浮点归一化：先算总权重
total，再用rand.Int63n(total)生成整数随机偏移 - 遍历奖品列表，维护一个运行和
sum，当sum 时命中（注意边界是左闭右开） - 跳过权重 ≤ 0 的项，避免逻辑短路或 panic
- 如果奖品列表固定且数量大（比如上千），可预构建前缀和数组 + 二分查找，但日常几十个奖品线性扫描更清晰、无额外内存开销
如何安全地支持动态权重更新而不锁整个池
游戏里常有运营实时调高某道具掉率，若每次抽都重新算总权重并加锁，高并发下会成为瓶颈。直接读写共享变量又可能读到中间态（比如总和已更新但某个权重还没更新）。
实操建议：
- 把权重切片和总权重封装成只读结构体，每次更新时原子替换整个结构体指针（用
sync/atomic存unsafe.Pointer或用RWMutex保护指针） - 抽样函数只读该指针指向的不可变切片，完全无锁
- 避免在结构体里存“当前生效时间”之类字段——它不解决并发问题，反而增加判断分支
- 如果必须热更新且不能接受短暂不一致（比如刚更新权重就立刻要 100% 命中），那就得上读写锁，但应明确标注这是低频操作
rand.Int63n() 在权重总和为 0 时 panic 怎么办
当所有奖品权重都是 0，total == 0，此时调 rand.Int63n(0) 会 panic: "n must be positive"。线上服务遇到这个错误基本等于直接 crash。
实操建议：
- 初始化奖品池时就校验
total > 0，否则返回 error 或 panic 并带上具体奖品 ID 列表 - 抽样函数入口加防御：if
total == 0{ return nil, errors.New("no valid prize with positive weight") } - 不要试图用
rand.Int63() % total替代——模运算在total不是 2 的幂时引入偏差，且% 0同样 panic - 测试用例必须覆盖全零权重、单个非零权重、权重含负数等边界场景
为什么不用 golang.org/x/exp/rand 而坚持用标准库 math/rand
新 rand 包提供了更好的随机质量与并发安全的全局实例，但实际项目里换它并不划算。
实操建议：
- 抽样逻辑本身不依赖全局随机源——你传入自己的
*rand.Rand实例即可，标准库完全够用 -
x/exp/rand尚未进入稳定版本，API 可能变动；而math/rand的Int63n行为定义明确、文档完整 - 真正需要高随机质量的场景（如加密用途）本就不该用这类奖品抽取——那是业务逻辑，不是密码学原语
- 如果项目已用
x/exp/rand，只需确保传入的Rand实例非 nil，其余逻辑不变
最易被忽略的一点：权重数据来源如果是 JSON 配置文件，记得用 json.Number 解析整数权重字段，避免 float64 解析导致大整数截断（比如 9223372036854775807 变成 9223372036854776000）。
