正确方法是先计算每格理论跨度360.0/n，再随机选取目标格index，最后在该格扇形内均匀采样角度：angle = index 360.0 / n + Math.random() 360.0 / n。
转盘角度怎么算才不会偏移一格？
转盘最终停在哪一格，本质是把随机数映射到角度区间。常见错误是直接用 Math.random() * 360 然后除以格子数取整——这会让每格实际占的角度不均等，尤其当格子数不能整除360时（比如8格是45°，但7格是约51.428°），边界处理稍有偏差就会跳格。
正确做法是先确定每格的「理论中心角」，再围绕它加一个微小随机扰动，确保落点严格落在该格对应扇形内：
- 设总格数为
n，则每格理论跨度为360.0 / n - 随机选中第
index格（0 ），其角度范围是 <code>[index * span, (index + 1) * span) - 最终停转角度取该区间内均匀随机值：
index * span + Math.random() * span
这样既保证每格概率完全均等，又避免因浮点精度或四舍五入导致的“视觉错位”。
Java里用Random还是ThreadLocalRandom？
抽奖是高频并发场景（比如直播间万人同时点击），用 Random 会因内部 CAS 重试产生竞争开销；而 ThreadLocalRandom 每线程独立实例，无锁，性能更稳。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 全局单例场景（如 Spring Bean）直接注入
ThreadLocalRandom.current()，别存为成员变量 - 不要在循环里反复调用
ThreadLocalRandom.current()，一次获取复用即可 - 如果需要可重现的测试结果（比如单元测试固定种子），才用
new Random(seed)，生产环境别这么干
示例：选中格子索引
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
int index = ThreadLocalRandom.current().nextInt(0, n);
为什么转盘动画结束角度总差那么几度？
前端转盘动画通常靠 CSS transform: rotate() 或 Canvas 绘制，后端只返回目标角度。但常见坑在于：后端传的 angle 是绝对角度（0~360），而前端动画常基于当前状态做相对旋转，若没归一化或忽略起始偏移，就会累积误差。
关键点：
- 后端返回角度务必归一化到
[0, 360)：用angle % 360，注意 Java 中负数取模结果可能为负，应写成((int) angle % 360 + 360) % 360 - 前端做动画时，要明确是以「顺时针最小路径」旋转，还是强制转满N圈再停——后者需在基础角度上叠加
360 * spinCount（如加3圈就是 +1080） - 别依赖 JS 的
getComputedStyle读取实时角度做判断，浮点渲染误差可达 ±0.01°，应以后端下发的目标值为准
奖品权重怎么和角度分配对齐？
真实业务里各奖项概率不同（比如一等奖 5%，安慰奖 60%），不能简单按格数均分角度。核心是把「概率分布」映射为「角度区间」。
做法是构建前缀和数组，再用二分查找定位：
- 假设奖品列表为
List<prize> prizes</prize>，每个Prize.weight表示百分比（如 5 表示 5%） - 预计算前缀和数组
double[] angles，其中angles[i]是前 i 项累计角度（= 累计权重 × 360） - 生成
[0, 360)随机数r，用Arrays.binarySearch(angles, r)找到插入位置，即中奖索引
注意：权重必须归一化（总和为100），且用 double 计算，避免整型累加丢失精度。
角度归一化、权重前缀和、线程安全随机源——这三个点漏掉任何一个，上线后都可能表现为“明明配置了1%中奖率，结果连抽50次全中安慰奖”。
