<p>用 Math.random() 做权重抽奖总抽不到低概率奖品，因其返回 [0,1) 导致最后一区间长度缺失；正确做法是预计算前缀和，用 Math.random() * totalWeight 后二分查找。</p>
用 Math.random() 做权重抽奖，为什么总抽不到低概率奖品？
因为直接乘权重再取整会破坏概率分布——比如权重 [1, 9]，你生成 0~1 的随机数，乘以 10 得到 0~9 整数，再按区间映射，看似合理，但 Math.random() 返回的是 [0, 1) 开闭区间，0 可能被包含而 1 永远不出现，导致最后一个区间实际长度少了一丁点。
正确做法是预计算前缀和，用 Math.random() * totalWeight 得到一个浮点目标值，再二分查找它落在哪个区间：
double r = Math.random() * totalWeight;
int idx = 0;
for (int i = 0; i < prefixSum.length; i++) {
if (r < prefixSum[i]) {
idx = i;
break;
}
}- 必须用
prefixSum[i-1] <= r < prefixSum[i]逻辑（或等价的「首次大于」），不能写成<= r <= - 前缀和数组
prefixSum长度应与奖品数一致，prefixSum[0] == weight[0]，不是从 0 开始累积 - 如果奖品数多（>1000），建议改用
Arrays.binarySearch()，避免线性扫描
Spring Boot 项目里怎么把权重配置从代码里抽出来？
硬编码权重等于锁死业务规则。推荐用 @ConfigurationProperties 绑定 YAML 列表，但要注意字段类型和结构匹配：
lottery:
prizes:
- id: "iphone"
weight: 5
- id: "coupon_5"
weight: 80
- id: "thanks"
weight: 15对应 Java 类字段必须是 List<PrizeConfig>，且 PrizeConfig 中 weight 用 int 或 long，别用 Integer（否则空值报错）。
立即学习“Java免费学习笔记（深入）”；
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- YAML 中数字不要加引号，
weight: "5"会导致类型转换失败，抛出Failed to bind properties - 启动时校验总权重是否 > 0，可在
@PostConstruct里加断言，避免上线后抽不到任何奖 - 如果运营要动态调权，别 reload YAML，改用 Spring Cloud Config +
@RefreshScope，但注意RefreshScope不支持静态内部类绑定
并发抽奖时，Random 和 ThreadLocalRandom 怎么选？
用 new Random() 是最常见错误——每次新建实例会复用系统时间做 seed，高并发下大量实例几乎同时创建，seed 相同，导致随机序列重复。
ThreadLocalRandom.current().nextDouble() 是唯一安全选择，它为每个线程维护独立种子，无锁且比 Random 快。
- 千万别在循环里反复调用
ThreadLocalRandom.current()，虽然不报错，但没必要；存一次引用即可 - 如果用了 Redis 分布式锁控制抽奖入口，仍需在锁内用
ThreadLocalRandom，因为锁只保原子性，不保随机性 - 测试时若想复现某次中奖结果，可临时换成
new Random(12345L)固定 seed，但上线必须删掉
MySQL 存奖品配置，查权重时 COUNT(*) 为什么越来越慢？
当奖品配置表只有几十行时，SELECT * 没问题；但一旦加了运营后台允许增删奖品，表变大、加了索引、甚至分库分表后，每次抽奖都查库就成瓶颈。
权重数据本质是低频更新、高频读取的元信息，应该加载进 JVM 内存，用 ConcurrentHashMap 缓存，并监听配置变更事件刷新。
- 缓存 key 推荐用
"prize:config:version"+ 版本号，而不是直接缓存整个列表，便于灰度发布 - 数据库加
updated_at字段，应用启动时查最大版本，之后定时轮询（如每 30 秒）该字段变化，避免长连接监听的复杂性 - 如果用 MyBatis，别在
@Select方法上加@CacheNamespace，它的默认 LRU 清理策略可能误删正在用的权重数据
权重逻辑看着简单，真正卡住人的永远不是算法，而是边界：浮点精度、并发安全、配置热更、缓存一致性——这些地方一漏，中奖率就悄悄偏移，而且很难监控到。
