纯HTML无法实现抽奖逻辑，必须配合JavaScript；抽签式抽奖用Math.random()加数组实现，适合名单固定、人数不多的场景。
纯 HTML 无法实现抽奖逻辑，必须配合 JavaScript；所谓“HTML 抽奖页面”实际是用 HTML 搭结构、CSS 做视觉、JS 控制转盘/随机选中/动画等核心行为。
抽签式抽奖：用 Math.random() + 数组实现最简逻辑
适合名单固定、人数不多（
-
Math.random()本身没问题，但常见错误是写成Math.floor(Math.random() * arr.length) + 1——这会导致索引越界，正确是Math.floor(Math.random() * arr.length) - 抽过的人要从数组里剔除，不能只靠“标记已抽”，否则多人并发点击会重复中奖；推荐用
splice(index, 1)实时移除 - 如果需要“保底机制”（比如抽10次必中），得额外维护一个计数器，不能依赖视觉动画帧数或点击次数
const names = ["张三", "李四", "王五"];
function draw() {
if (names.length === 0) return "抽完了";
const idx = Math.floor(Math.random() * names.length);
return names.splice(idx, 1)[0];
}转盘式抽奖：CSS transform: rotate() 动画要绕开浏览器重绘陷阱
视觉上是转盘，底层仍是 JS 随机计算停在哪一格。难点不在“怎么转”，而在“怎么让转得自然、停得可信、不被用户预判”。
- 别直接用
transition: transform 3s+ 设置最终rotate()——这样无法控制减速过程，容易卡顿或突停；应改用animation配合cubic-bezier(.25,.1,.25,1)模拟惯性 - 每格角度必须严格等于
360 / 总格数，且起始偏移（background-position或初始rotate）要和视觉对齐，否则指针指向和实际中奖区错位 - 中奖结果不能在动画开始前就告诉用户，必须等
animationend事件触发后才显示，否则用户看到“还没转完就弹出恭喜”会觉得假
防刷与体验平衡：按钮禁用、请求节流、服务端校验缺一不可
前端抽奖 UI 再炫酷，没服务端约束就是摆设。用户 F12 改 JS 变量、连点、抓包重放，分分钟中奖翻倍。
立即学习“前端免费学习笔记（深入）”；
- 点击抽奖按钮后立即设为
disabled，并加 loading 状态；动画结束前不允许二次点击 - 即使单页应用，也必须调用后端接口（如
/api/draw）获取真实中奖结果，前端只负责展示；返回字段至少含prize_id和signature（防篡改） - 后端需限制 IP/用户 ID 的抽奖频次（如 1 小时 1 次），前端节流（
setTimeout锁住按钮 2 秒）只是辅助，不是防线
真正难的不是让指针转起来，而是让每次点击都对应一次不可抵赖的服务端原子操作；视觉动效可以后期优化，但请求链路、状态同步、错误回退这三块一旦漏掉，活动上线当天就会出问题。
