轮盘转动应封装函数维护当前角度并累加随机偏移量（1080–1440°），末段200ms切ease-out减速；定位需用getBoundingClientRect()和Math.atan2()计算扇区，起始边为-90°；中奖逻辑须后端先返回ID、前端反推目标角度并容错±1.5°；移动端用touchstart/touchend防误触并加防抖，Safari需will-change: transform优化。
轮盘转动靠 transform: rotate()，但别直接改 style
直接操作 element.style.transform = 'rotate(360deg)' 看似简单，实际会覆盖原有旋转状态，导致连续抽奖时角度错乱。正确做法是用 CSS transition 配合动态计算目标角度，或用 requestAnimationFrame 手动插值。更稳妥的是封装一个转动函数，内部维护当前角度，每次累加随机偏移量（比如 1080–1440 度），再加一段“减速”区间（最后 200ms 切换为 ease-out）。
getBoundingClientRect() 比 offsetLeft/Top 更可靠地获取点击位置
做指针定位或中奖区域判定时，很多人用 event.offsetX，但它在缩放或 transform 后失效。真实场景中轮盘常被 scale() 或放在 flex 容器里，此时必须用 getBoundingClientRect() 计算鼠标相对于轮盘中心的坐标，再用 Math.atan2() 算出弧度，映射到对应扇区。注意：扇区角度要按顺时针排列，且起始边默认在 12 点方向（即 -90°），否则算出来的 sectorIndex 会整体偏移。
中奖逻辑不能只看最终角度，得结合「惯性停转」和「格子对齐」
用户看到的“停在某格”其实是视觉效果，后端返回的中奖 ID 必须与前端扇区严格对应，否则出现“显示中 iPhone，实际发了优惠券”的事故。常见错误有：
• 扇区划分用整数除法（如 Math.floor(angle / 30)）但没处理负角度
• 转动结束时角度是 1079.8°，而扇区边界在 1080°，结果归到上一格
• 没做容错偏移（建议加 ±1.5° 的 tolerance）
• 抽奖请求发出去之后才开始转，导致网络延迟时用户看到“空转”
推荐流程：先调用后端接口拿到中奖编号 → 根据编号查出对应扇区索引 → 反推目标角度（含偏移补偿）→ 触发转动动画。
立即学习“前端免费学习笔记（深入）”；
移动端 touchstart + touchend 替代 click，但需防误触
在 iOS Safari 上，click 有 300ms 延迟，且轮盘区域小、手指大，容易触发多次。必须用 touchstart 绑定，并在 touchend 里判断位移是否小于 10px 才执行抽奖。同时加一层防抖：if (isSpinning) return;。另外，Safari 对 transform 动画的硬件加速支持不稳定，建议给轮盘容器加上 will-change: transform;，并避免同时动画多个大图层。
复杂点在于：不同机型屏幕密度、touch-action 行为不一致，真机测试比模拟器重要得多；轮盘图片若用 base64 内嵌，首次加载可能卡顿，建议用 img 标签 + onload 回调控制启动时机。
