用 transform: rotate() 配合 transition 和 JS 控制替代纯 CSS animation，动态计算目标角度、校准扇区中线、强制重绘并状态锁控，可实现精准、不卡顿、防连点的转盘抽奖。
animation + transform 实现转盘旋转不卡顿
转盘抽奖本质是让一个 .wheel 元素做「长时长、单次、顺时针」的旋转动画，但直接用 animation: spin 10s linear 会遇到两个现实问题：一是 Safari 下超过 6s 容易掉帧，二是用户连续点击时动画无法中断重置。根本原因在于 CSS 动画不是“运动控制”，而是“时间轴声明”。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
transform: rotate()配合transition替代纯animation，把旋转逻辑收归 JS 控制，更可控 - 动画时长不要硬写死，按目标角度动态算：比如要停在第 5 个奖品（共 8 等份），基础圈数 + 偏移角 =
360 * 3 + (360 / 8) * 5 - 务必加
transform-origin: center，否则旋转中心偏移会导致视觉错位 - 移动端记得加
will-change: transform触发 GPU 加速，但别滥用——只在开始旋转前加，结束后立刻移除
如何让转盘“真正停在指定奖品位置”
用户看到的是“指针固定、转盘转动”，但实际停准依赖两件事：一是角度计算必须对齐扇区中心，二是浏览器渲染存在四舍五入误差。常见错误是直接用 rotate(45deg) 去对齐第 1 个奖品，结果指针尖总差 2–3px。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 扇区角度 =
360 / prizeCount，但“停靠点”应是每个扇区的中线，即offset = (index + 0.5) * sectorAngle - 用
getBoundingClientRect()测出指针尖坐标，反向校准旋转角度，比纯数学计算更可靠 - 动画结束时，用
setTimeout(() => { element.style.transform = 'rotate(Xdeg)' }, 0)强制重绘，避免浏览器缓存旧 transform 值 - 别信 CSS 的
animationend：它可能在动画被 JS 中断后仍触发，优先监听transitionend并校验getComputedStyle的transform值
IE11 或低端安卓 WebView 怎么兼容
IE11 不支持 transform: rotateZ() 的小数角度（如 rotate(123.4deg)），部分安卓 4.x WebView 对 transition: transform 有 100ms 以上延迟。这不是“加前缀”能解决的。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 降级方案不是改用 JS 动画库，而是用
@keyframes预定义 360 个整数角度的帧（实际只需 36 帧：每 10° 一帧），通过 class 切换触发 - 检测
CSS.supports('transform', 'rotateZ(1deg)')决定走 transition 还是 keyframes 分支 - 所有旋转角度统一用
Math.round(angle) + 'deg'，杜绝小数 - 避免在动画中同时修改
width或opacity，这会让老浏览器强制回退到 CPU 渲染
抽完奖怎么防止用户连点导致状态错乱
连点不是 UI 问题，是状态机没建好。典型现象：第一次点击刚触发旋转，第二次点击又覆盖了 transform，结果停在半路，且后续回调全乱。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用一个布尔值
isSpinning锁住按钮，但别只靠它——JS 中断动画后，DOM 的transform值可能还是旧的，得配合getComputedStyle校验 - 每次点击先调
element.style.transition = 'none'瞬间清空当前动画，再设新transform，最后恢复transition - 后端返回中奖结果前，按钮禁用；返回后，等动画彻底结束（
transitionend+transform值确认）才允许下一次点击 - 别在
click回调里直接写rotate(…)，封装成startSpin(targetIndex)函数，入口处统一做防抖和状态检查
角度计算要扣到像素级，指针和扇区的视觉对齐比动画流畅度更难搞。很多人卡在“看起来停了，但其实差 0.3°”，这时候得拿 devtools 量 DOM 元素的实际 render 位置，而不是信代码里的数字。
