<p>最简前端抽奖逻辑是点击按钮后随机选取奖品并立即刷新页面：先用Math.floor(Math.random() * prizes.length)获取索引，textContent显示结果，随即执行window.location.reload()清空状态，按钮点击后设disabled防连点。</p>
用 window.location.reload() 实现点击即抽奖的最简逻辑
不需要后端、不依赖框架，纯前端抽奖的核心就是「随机选一个」+「刷新页面重置状态」。关键不是炫酷动画，而是让用户清楚当前没抽过、点一下就出结果。用 window.location.reload() 是最快落地的方式——它天然清空所有 JS 状态和 DOM 变化，避免重复点击或状态残留。
常见错误是用 Math.random() 生成一次就缓存结果，导致刷新后还是同一个；或者用 setTimeout 模拟转盘但没禁用按钮，用户连点多次触发多个定时器。
- 把所有奖品写死在数组里，比如
const prizes = ["一等奖", "二等奖", "谢谢参与"] - 点击按钮时只做一件事：调用
Math.floor(Math.random() * prizes.length)取索引，然后显示对应项 - 显示完立刻执行
window.location.reload()，而不是等几秒再 reload —— 否则用户可能看到结果又点一次
用 disabled 和 textContent 控制按钮与结果区域
HTML 里按钮和结果区必须可被 JS 直接操作，且交互反馈要即时。不能靠 CSS 隐藏按钮来防重复点击，得用原生 disabled 属性，否则键盘仍可触发（Enter 键），也不符合可访问性要求。
常见场景是用户点太快，按钮还没变灰就又点了一次；或者结果文字用 innerHTML 插入带标签的内容，结果被 XSS 注入（哪怕只是本地测试也该养成习惯）。
立即学习“前端免费学习笔记（深入）”；
- 按钮初始不加
disabled，但点击后立刻设btn.disabled = true - 结果区域用
textContent赋值，比如resultEl.textContent = prizes[index] - 不要在 JS 里拼 HTML 字符串，例如避免
resultEl.innerHTML = "<strong>" + prize + "</strong>"
为什么不用 CSS 动画或 Canvas 做转盘？
因为“简单抽奖页面”的第一需求是功能确定、逻辑透明、调试方便。CSS 动画转盘需要精确控制旋转角度、 easing、结束回调，还要处理 Safari 的 transform 兼容性；Canvas 更要自己算扇形坐标、监听点击位置、处理 DPR 缩放 —— 这些都和“简单”相悖。
真正容易踩的坑是：为了视觉效果引入第三方库（如 spin.js），结果发现它依赖 jQuery 或 require.js，而你的 index.html 是直接双击打开的本地文件，直接报 CORS 或 require is not defined。
- 如果真要动效，用 0.3s 的
opacity渐显比旋转更稳 - 所有样式写在
<style>标签里，不外链 CSS 文件，避免本地打开时 404 - 测试务必用
file://协议双击打开，而不是靠 VS Code Live Server 自动起服务 —— 后者默认开 CORS，会掩盖真实限制
localStorage 不适合记录“已抽中”，但可以存历史记录
用户关掉页面再打开，理应能重新抽；所以不能用 localStorage 锁定“今日已抽”，那违背了“每次都是新开始”的预期。但可以存最近 5 次结果，用于展示小历史栏，这属于锦上添花。
容易被忽略的是 localStorage 的容量限制（通常 5MB）和同步写入阻塞主线程的问题。高频点击下连续 setItem 可能卡住 UI，尤其在旧版 iOS Safari 上。
- 存历史用
JSON.stringify([...history, newItem].slice(-5))，避免无限增长 - 读取时用
try...catch包裹，防止 JSON 解析失败导致整个脚本中断 - 别用
localStorage判断是否允许抽奖 —— 它不可信，用户清缓存就失效，逻辑不该依赖它
实际最简可用的 index.html 就三块：一个 <button>、一个 <div id="result"></div>、一段内联 <script>，20 行以内能跑通。复杂点永远在“怎么让用户信这是真随机”，而不是“怎么让转盘转得像 Vegas”。
