简介这是一份面向前端开发者的JavaScript手机号批量滚动抽奖实现方案常用于年会、晚会、现场互动等活动场景解决的是在大量手机号中随机且不重复产生中奖号码的核心问题。资源以单个PDF文档形式提供压缩包大小约56KB文档通过原理讲解和关键代码片段结合的方式说明了随机索引生成、已选号码去重、setInterval定时器控制滚动、每轮中奖人数限制以及由后台系统最终确认中奖号码以确保公平性等实现要素。内容中还展示了包含奖项等级、中奖人数、金额设置项的页面界面示意。示例代码使用数组加includes方法规避重复逻辑清晰便于读者迁移到自己的项目中。目前已有368人学习浏览适合想快速理解手机号批量滚动抽奖并动手实现类似功能的开发者。1. JS手机号批量滚动抽奖为什么说它不只是「让数字滚起来」活动现场最让人捏把汗的往往不是网络而是那块大屏上的号码能不能正常滚动、停下来时会不会出错。JS手机号批量滚动抽奖实现代码解决的是运营把一批手机号粘贴进来、点一下开始、屏幕滚动刷号、喊停落定、再导出中奖名单这一整套流程。它不复杂但细节非常多号码可能带着空格、横线甚至科学计数法状态一乱会连续开奖后台标签页切走动画就停最后导出的 CSV 还可能乱码。这套代码适合三类人前端要搭内部活动页的开发运营想用静态页面救场的非技术同学以及想搞明白滚动抽奖前端实现的新手。读完这一篇你能从空白的 HTML 文件一路写到能上台抽奖的完整版本。2. 手机号怎么进抽奖池粘贴解析、去重过滤与批量校验先做一个最小页面把入口定下来。我一般用三个按钮加一个大屏区域导入、开始、停止中间一块显示号码的 screen底部放中奖列表。代码结构不必酷炫活动页面求的是稳。div idapp textarea idrawInput rows6 placeholder粘贴手机号每行一个支持逗号、分号、空格分隔/textarea button idimportBtn导入号码/button button idstartBtn disabled开始/button button idstopBtn disabled停止/button div idscreen--/div ul idwinners/ul button idexportBtn disabled导出中奖名单/button /div这里有个细节开始和停止按钮初始是 disabled 的只有导入号码后才放开开始只有滚动中才放开停止。这个习惯能挡住一多半误操作。下面把导入逻辑写出来它决定了后面所有环节的数据质量。2.1 从粘贴文本里解析手机号一条正则和它的四个边界条件运营从 Excel 或通讯录里复制出来的文本格式永远比想象中乱有每行一个的有用逗号、分号、顿号分隔的还有中间带横线和空格的。我一般先用一条分隔正则切分再做清洗。const rawInput document.getElementById(rawInput); const importBtn document.getElementById(importBtn); const screenEl document.getElementById(screen); let pool []; let winners []; function parsePhones(text) { const parts text.split(/[\s,;、\n]/); const phones []; const seen new Set(); for (const part of parts) { const p part.replace(/[-\s]/g, ); if (/^1[3-9]\d{9}$/.test(p) !seen.has(p)) { seen.add(p); phones.push(p); } } return phones; } importBtn.addEventListener(click, () { const phones parsePhones(rawInput.value); if (phones.length 0) { screenEl.textContent 没有解析到有效手机号请检查输入格式; return; } pool phones.slice(); winners []; screenEl.textContent 已导入 ${pool.length} 个号码; });分隔正则里的\s覆盖空格、Tab 和换行再把中英文逗号、分号、顿号都列进去基本能兼容主流粘贴格式。replace(/[-\s]/g, )处理的是138-1234-5678这类带横线的号码先把横线去掉再校验否则会被拦在外面。正则^1[3-9]\d{9}$是 11 位手机号的常见校验第二位限制在 3 到 9能覆盖当前主流号段同时过滤掉一长串数字的座机或乱粘贴的文本。最后用Set去重重复号码只保留第一个。这里要特别提醒如果粘贴进来的内容已经变成1.38123E10这种科学计数法前端是救不回来的。Excel 默认把长数字显示为科学计数法复制出来的就是显示值低位数字已经丢了一部分。遇到这种情况只能让运营回到 Excel 里把那一列改成文本格式再重新复制没有后悔药。2.2 导入时的三个默认动作去重、过滤空行、按来源保留顺序解析函数其实已经同时做了三件事去重、过滤空行、过滤非手机号文本。保留顺序这一点容易被忽略它其实很重要。运营拿到的名单往往有排序意义比如按部门、按报名时间排好解析时从头到尾 push 进数组保持了原始顺序绘制大屏时不按这个顺序显示但导入预览和中奖导出会沿用这个顺序运营核对起来更方便。有些做法会在解析后调用Array.sort把号码排序我建议不要。排序会让同样的三个号在不同的输入顺序下产生完全相同的展示序列反而容易让观众觉得「每次刷过去的顺序都一样」。「看起来随机」不仅取决于抽样算法也取决于基础数组的顺序是否自然保留原始顺序是最省事的。导入预览可以做一层校验让运营在抽奖之前看到有效号码数和中奖列表占用情况function renderPreview(phones) { const preview document.getElementById(preview); if (!preview) return; preview.textContent 解析成功 ${phones.length} 个号码已自动去重、过滤空行和非 11 位手机号; }如果号码数量少于 10 个我会直接在导入后提示「号码太少滚动效果会很差建议至少 20 人参与」。这不是代码问题是现场体验问题号码池只有 5 个时滚动屏翻来覆去就那几个号观众一眼就能看出规律抽奖的紧张感就没有了。2.3 没有 Excel 也能先跑通内置测试数据与导入预览开发阶段最怕的就是手上没有真实号码数据。我习惯在页面里放一个「填入测试数据」按钮点一下自动生成 50 个假手机号。这样不用打开 Excel不用问运营要名单就能把滚动、停止、导出整条链路跑一遍。function fillDemoData() { const demo Array.from({ length: 50 }, (_, i) { const suffix String(i).padStart(4, 0); return 1381234${suffix}; }); rawInput.value demo.join(\n); screenEl.textContent 已填入 ${demo.length} 个测试号码请点击导入; }padStart(4, 0)保证从13812340000到13812340049都是完整的 11 位。测试数据要避免真的手机号段被抽到真实用户头上所以固定用1381234前缀的虚构号码。等到彩排时再换成运营提供的脱敏或者测试名单。这个内置测试数据还有个额外用途给新人做演示。有一次活动前运营临时要看看效果整个流程从打开页面到跑完一轮不到一分钟靠的就是这个按钮。不要把 Demo 数据当成正式数据留着正式活动导入前会先清空 textarea免得两个名单混在一起。3. 滚动动画与抽取逻辑让屏幕快速刷号又要停得让人信服导入号码之后核心问题变成两块屏幕上的号码怎么滚以及最终停在中奖者身上的那一瞬间逻辑上怎么保证公平。这两件事要分开想否则代码写出来容易变成「滚动是随机停了再随机一次」导致视觉和中奖结果脱节。活动场景下观众对滚动动画的预期是开始后号码快速刷新主持人喊停后速度明显慢下来最后定格的号码就是中奖者。如果停止瞬间才用Math.random抽取那滚动过程就只是装饰谈不上公平性信任问题如果滚动过程中已经确定好中奖者只是通过减速把它展示出来逻辑上更完整。所以我倾向于在点击「开始」的那一刻就锁定本轮的 index滚动只是把最终结果「演」出来。3.1 刷号动画用 requestAnimationFramesetInterval 的问题在哪滚动刷号最直接的写法是setInterval每 60ms 换一个号码。它也能跑但有两个问题一是浏览器对定时器有嵌套调用限制二是后台标签页会把定时器降到每秒一次甚至暂停。活动大屏如果切到别的窗口再切回来动画节奏会变得很奇怪。requestAnimationFrame跟随屏幕刷新率执行通常 60Hz也就是每帧约 16.7ms。我们不每帧都换号而是记录上次换号的时间真正按时间间隔刷新这叫「基于时间戳控制」。这样即使某一帧卡顿后续也不会累积偏差。const FAST_GAP 60; const STOP_DURATION 2600; const MIN_GAP 60; const MAX_GAP 220; let mode idle; let finalIndex -1; let lastShownIndex -1; let lastUpdateTime 0; let stopStartTime 0; let frameId null; function mask(phone) { return phone.replace(/^(\d{3})\d{4}(\d{4})$/, $1****$2); } function updateScreen() { let idx; do { idx Math.floor(Math.random() * pool.length); } while (idx lastShownIndex pool.length 1); lastShownIndex idx; screenEl.textContent mask(pool[idx]); }代码里do...while防止同一个号码连续出现在大屏上。Math.random抽中同一个 index 的概率约 1/N号码池小的时候几乎必然发生观众直接会喊「假的吧」。重复抽一次虽然不能保证全局不重复但能消除最刺眼的连续重复。mask把手机号中间四位换成星号大屏上只显示138****5678这是活动场景下的隐私习惯。3.2 从全部号码里抽当前显示号中奖者必须从剩余池子里选滚动显示过程中updateScreen是从整个pool里随机取一个来做展示。这里有个容易踩坑的边界如果pool只有 1 个号do...while会死循环。代码里的pool.length 1条件就是为了挡住这个边界。如果只剩最后一个人那他就是本轮中奖者直接展示即可。现在看核心的中奖锁定逻辑。点击「开始」的那一刻我们用Math.floor(Math.random() * pool.length)锁定一个下标这个下标对应的就是本轮中奖者。之后整个过程里无论是快速滚动还是减速停止真正的结果都已经是这个下标。谁也不知道这个下标对应哪个号码因为pool有几十上百个元素操作员从屏幕上也看不出规律所以它仍是一个公平的黑匣子。function startRoll() { if (mode ! idle || pool.length 0) return; finalIndex Math.floor(Math.random() * pool.length); mode running; lastShownIndex -1; lastUpdateTime performance.now(); frameId requestAnimationFrame(rollLoop); } function finishRoll() { const winner pool.splice(finalIndex, 1)[0]; winners.push(winner); screenEl.textContent mask(winner); renderWinners(); mode idle; }finishRoll里做两件事把pool[finalIndex]从池中移除push 进winners。splice之后的数组长度少了 1下一轮抽奖无论怎么随机都不会再抽到这个人。这是「中奖不重复」的关键比每次去比较 winners 列表要可靠得多。那滚动过程中updateScreen也会随机到pool[finalIndex]这个号码也就是最终中奖者会提前出现在屏幕上几次。这没问题反而增加了真实性。如果滚动过程中绝不出现中奖者懂行的人一眼就知道这轮是谁悬念就没了。3.3 滚动速度三段式快速扫描、减速逼近、锁定定格滚动速度的设计直接决定现场气氛。我习惯分成两段点开始后保持恒定快速刷新点停止后进入一段 2.6 秒的减速区减速区里刷新间隔从快到慢最终定格。function stopRoll() { if (mode ! running) return; mode stopping; stopStartTime performance.now(); } function rollLoop(timestamp) { if (mode running) { if (timestamp - lastUpdateTime FAST_GAP) { updateScreen(); lastUpdateTime timestamp; } frameId requestAnimationFrame(rollLoop); } else if (mode stopping) { const progress Math.min((timestamp - stopStartTime) / STOP_DURATION, 1); const gap MIN_GAP (MAX_GAP - MIN_GAP) * progress; if (timestamp - lastUpdateTime gap) { updateScreen(); lastUpdateTime timestamp; } if (progress 1) { finishRoll(); } else { frameId requestAnimationFrame(rollLoop); } } }progress从 0 到 1 线性增长gap也随之从 60ms 增长到 220ms。60ms 时每秒刷新约 16 次220ms 时每秒只剩约 4 次人眼能明显感觉到号码越滚越慢。最后progress 1时直接调用finishRoll屏幕上定格的就是最终中奖者。这里的关键参数是STOP_DURATION2.6 秒是反复试出来的范围太短显得仓促太长观众等着着急。如果主持人习惯喊「3、2、1」可以把它调到 3 秒。如果希望停止后立刻出结果可以缩短到 1.5 秒但减速会不够明显少了悬念感。还有一个细节stopRoll在stopping状态下再次点击不会生效这避免了现场紧张时连点按钮导致状态错乱。4. 开始停止批量开奖把按钮、状态机和结果导出串起来滚动逻辑写好后按钮和状态管理是另一块翻车高发区。很多同学把代码写成「点击开始执行一个函数点击停止执行另一个函数」看起来能跑但一旦快速连点、批量抽奖、抽完再抽状态就乱了。我习惯先用状态机把整个生命周期定死再写事件绑定。4.1 抽奖按钮只有三个状态却有四个先画状态机再写事件完整的状态不是「开始」和「停止」两个而是 idle、running、stopping 三种互相制约的状态。idle 可以开始running 可以停止stopping 不可打断定格后自动回到 idle。还有一个隐性状态是「无号码」但这种情况连开始按钮都不会放开所以不需要单列。const startBtn document.getElementById(startBtn); const stopBtn document.getElementById(stopBtn); const exportBtn document.getElementById(exportBtn); function updateButtons() { startBtn.disabled mode ! idle; stopBtn.disabled mode ! running; importBtn.disabled mode ! idle; exportBtn.disabled winners.length 0; } startBtn.addEventListener(click, () { startBatch(1); }); stopBtn.addEventListener(click, stopRoll); function renderWinners() { const winnersEl document.getElementById(winners); winnersEl.innerHTML winners .map((phone, i) li${i 1}. ${mask(phone)}/li) .join(); updateButtons(); }updateButtons根据当前 mode 控制三个按钮的可用性这样从 UI 上就杜绝了连点。导入按钮在抽奖过程中也被禁用防止有人中途把号码池换掉。mask展示是为了投屏安全但要注意结果列表如果只显示掩码运营无法直接核对完整号码所以导出 CSV 时必须导出完整手机号这个区分要想清楚。4.2 批量抽奖的实现一次抽多个号码还要保证不重复活动里经常有「三等奖 5 名」这种批量需求。最简单粗暴的做法是一次性从 pool 里随机取 5 个但这失去了滚动抽奖的仪式感。我一般把批量实现成「排队逐轮执行」每轮走一遍完整的滚动、停止、定格流程自动进入下一轮。这样大屏上始终只有一个号码在滚节奏和单抽一样。let batchQueue 0; function startBatch(count) { if (mode ! idle || pool.length 0) return; batchQueue count; runNextBatch(); } function runNextBatch() { if (batchQueue 0) { batchQueue--; startRoll(); } } function finishRoll() { const winner pool.splice(finalIndex, 1)[0]; winners.push(winner); screenEl.textContent mask(winner); renderWinners(); mode idle; if (batchQueue 0) { runNextBatch(); } }finishRoll在推入中奖名单后检查队列如果还有剩余轮次就继续startRoll。因为每轮结束后pool已经少了中奖者下一轮再次随机时不会抽到重复号码。这就是批量不重复的机制不需要额外的if判断或临时数组。这里有个边界如果请求抽 5 个但 pool 里只剩 2 个怎么办startBatch只检查了 pool 非空没检查数量。常见的做法是在runNextBatch里加一层判断号码不足时直接结束队列并提示。function runNextBatch() { if (batchQueue 0 || pool.length 0) { batchQueue 0; if (pool.length 0) screenEl.textContent 号码已全部抽完; return; } batchQueue--; startRoll(); }这个处理比在弹窗里阻止更平静抽到哪算哪剩余的人自动不参与名单照常导出。4.3 中奖结果收集与 CSV 导出让运营可以直接拿走名单中奖名单最终要给运营他们最习惯用的是 Excel。浏览器导出 CSV 是最省事的路径但有两个坑中文或特殊字符乱码以及大屏掩码被导出去。我统一在导出时写完整手机号并在 CSV 头部加 UTF-8 BOM。function exportCsv() { const header 序号,手机号,中奖时间\n; const rows winners.map((phone, index) { const time new Date().toLocaleString(zh-CN); return ${index 1},${phone},${time}; }); const csv \uFEFF header rows.join(\n); const blob new Blob([csv], { type: text/csv;charsetutf-8 }); const a document.createElement(a); a.href URL.createObjectURL(blob); a.download 中奖名单.csv; document.body.appendChild(a); a.click(); document.body.removeChild(a); URL.revokeObjectURL(a.href); } exportBtn.addEventListener(click, exportCsv);\uFEFF是 Byte Order MarkExcel 打开 CSV 时用它识别 UTF-8 编码不加的话中文列名和备注大概率乱码。document.body.appendChild(a)再移除这一步老版本浏览器里不把a挂进 DOM 就触发不了下载加上没有坏处。导出按钮在 winners 为空时是 disabled 的防止运营导出空文件。到这个阶段一个可用的页面已经成型。剩下的问题不是功能缺失而是边界条件——下面这章集中写我踩过最深的几个坑。5. 手机号滚动抽奖避坑排查号码显示、随机性、掉帧与重复开奖功能写完不等于能上活动。以下几条都是真实出现过的问题按「现象、原因、解决」的方式记录。每一条背后都是现场的血泪经验。5.1 号码显示不全的坑空格、横线和科学计数法混入现象是屏幕上的号码经常短一截比如138123 45678显示成1381234567或者直接显示1.38E10。原因是 Excel 默认处理长数字复制时要么把空格去掉要么把超过 11 位的数字转成科学计数法粘贴进 textarea 后已经不是原始的 11 位文本。解决分两层。第一层是解析时做replace(/[-\s]/g, )去掉横线和空格第二层是在导入预览里直接提示号码数量如果数量比 Excel 里的行数少很多立即检查源头格式。科学计数法一旦出现就无解因为丢失的位数是永久性的唯一的办法是调整 Excel 列格式为文本后重新复制。我后来每次都把这条写进活动前的邮件里让运营提前转文本省得现场手忙脚乱。5.2 滚动抽奖「看起来不随机」的真相连续重复和固定序列现象是弹幕里有人刷「怎么又是这个号」。从概率上看号码池 50 人随机滚动时同一个号码短时间内再次出现是完全正常的概率约 1/50。但观众不认概率只看观感。而且如果滚动更新逻辑每帧都从数组头部取号或者随机源写法写成了Math.random() * pool.length忘记取整展示序列就会有明显规律。解决手段有两层。代码层updateScreen里用do...while避免连续两次显示同一个号。流程层导入时保留原始顺序而不排序让每次滚动的起始序列不同。还有一个容易忽略的点多个浏览器标签页同时打开同一个页面每个页面的滚动序列完全不同主持人看到的是当前页面的滚动导出的却是另一页的中奖结果两头对不上这是另一种「看起来不随机」。活动前只保留一个标签页或者锁定大屏页面不被误开。5.3 动画掉帧与页面卡住后台标签页的定时器限制现象是抽奖进行中切到别的窗口回来发现屏幕已经定格或者停在半路不再滚动。原因是requestAnimationFrame在后台标签页会被浏览器暂停performance.now()在切回时会瞬间跨过很大一段时间progress直接变成 1finishRoll被立即触发。解决有两个方向。第一个方向是接受现实在visibilitychange里取消当前滚动把状态重置为 idle本次抽奖作废重新开始。这样最安全不会在没人操作的情况下偷偷开奖。document.addEventListener(visibilitychange, () { if (document.hidden mode ! idle) { cancelAnimationFrame(frameId); mode idle; screenEl.textContent 页面切走本次抽奖已取消请重新开始; updateButtons(); } });第二个方向是活动开始前把大屏页面设为焦点窗口并锁掉多窗口误操作。现场设备如果不够熟悉我建议两个都用。要注意如果finishRoll已经把中奖者写进 winners这个取消只影响当前未完成的一轮已中奖名单不会丢失。5.4 中奖名单重复的坑连点、刷新和多开窗口现象是第二轮抽出来的号码和第一轮重复或者刷新页面后曾经中奖的人又出现在号码池。原因有三个中奖者没有从 pool 移除、刷新导致内存里的 pool 重置、多个标签页各自维护一份 pool。第一点靠splice解决。后面两点需要做一层本地持久化。前端没有数据库但至少可以把已中奖名单写进localStorage导入号码时自动过滤掉这些号码。const STORAGE_KEY draw_winners_v1; function saveWinners() { try { localStorage.setItem(STORAGE_KEY, JSON.stringify(winners)); } catch (e) {} } function loadWinners() { try { winners JSON.parse(localStorage.getItem(STORAGE_KEY)) || []; } catch (e) { winners []; } } function importFiltered(phones) { const used new Set(winners); pool phones.filter(p !used.has(p)); }localStorage只能挡住同一浏览器里的刷新和多开页面跨设备或多人同时操作时它并不安全。如果活动奖品比较正式中奖名单必须以服务端为准前端只负责展示。这个边界要在需求阶段跟运营讲清楚别让前端代码去承担它扛不起的事务一致性。我习惯在finishRoll里加一行断言console.assert( !pool.includes(winner), 中奖号码仍在抽奖池中逻辑错误 );断言在开发阶段帮了大忙有一次我重构批量逻辑时把splice写成了slice就是靠它发现的。上线活动时开着控制台跑几轮比肉眼检查可靠得多。6. 让这个 Demo 真正上线活动参数表、验证方法与验收习惯前面几章把功能写出来了但一台活动电脑上的运行表现和开发机往往差别很大。最后把可调参数和验收步骤整理成一张表这算是从 Demo 到上线之间最后一道工序。参数推荐范围说明FAST_GAP50~80ms快速滚动期的刷新间隔太快看不清太慢没紧张感STOP_DURATION2200~3200ms点停止到定格的总时长正常活动建议 2600msMIN_GAP / MAX_GAP60 / 220ms减速期刷新间隔的上下限末期每秒约 4 次刷新号码池数量至少 20 个少于 10 个时滚动几乎看不出效果单轮批量上限1~10 个超过 10 个建议改为连续多轮而不是一屏多号参数不是越大越好。FAST_GAP调到 20ms 时屏幕反而闪得让人头晕STOP_DURATION超过 4 秒观众会忍不住催。最佳做法是活动前用测试数据把参数固定下来现场不要再动。验证方法我用两步。第一步是随机分布抽查在控制台跑一段模拟确认随机源没有明显偏向。真正的抽奖流程不需要跑 1000 次因为每轮都会从 pool 移除一个号码分布验证针对的是Math.random本身。function verifyRandom(times 10000) { const n 100; const counter new Array(n).fill(0); for (let i 0; i times; i) { counter[Math.floor(Math.random() * n)]; } const avg times / n; const max Math.max(...counter); const min Math.min(...counter); console.log(平均 ${avg} 次最大 ${max}最小 ${min}偏差 ${((max - min) / avg * 100).toFixed(1)}%); }偏差在 15% 以内都算正常超过这个范围说明随机算法写歪了。第二步是断网试跑把所有 JS 和样式放在本地文件里打开 DevTools 的网络面板切到 Offline导入 50 个测试号连抽三轮导出 CSV检查行数、重复和中文乱码。活动大屏最怕临时依赖外部资源断网验证能提前暴露所有本地化问题。我现在的固定习惯是正式活动前一晚用测试号码把「导入 → 抽三轮 → 导出 CSV → 检查重复」完整跑一遍然后关掉页面重新打开再导入真实名单确认 localStorage 里恢复的中奖名单已经把已抽中的人过滤掉。做完这一轮心里才有底。这套流程也推荐给你毕竟抽奖页面是现场出错成本最高的那类页面宁可多花十分钟准备。希望帮到你。本文还有配套的精品资源点击获取
