简介：这是一份面向前端开发者的JavaScript手机号批量滚动抽奖实现方案，常用于年会、晚会、现场互动等活动场景，解决的是在大量手机号中随机且不重复产生中奖号码的核心问题。资源以单个PDF文档形式提供，压缩包大小约56KB，文档通过原理讲解和关键代码片段结合的方式，说明了随机索引生成、已选号码去重、setInterval定时器控制滚动、每轮中奖人数限制，以及由后台系统最终确认中奖号码以确保公平性等实现要素。内容中还展示了包含奖项等级、中奖人数、金额设置项的页面界面示意。示例代码使用数组加includes方法规避重复，逻辑清晰，便于读者迁移到自己的项目中。目前已有368人学习浏览，适合想快速理解手机号批量滚动抽奖并动手实现类似功能的开发者。

1. JS手机号批量滚动抽奖：为什么说它不只是「让数字滚起来」

活动现场最让人捏把汗的往往不是网络，而是那块大屏上的号码能不能正常滚动、停下来时会不会出错。JS手机号批量滚动抽奖实现代码，解决的是运营把一批手机号粘贴进来、点一下开始、屏幕滚动刷号、喊停落定、再导出中奖名单这一整套流程。它不复杂，但细节非常多：号码可能带着空格、横线甚至科学计数法，状态一乱会连续开奖，后台标签页切走动画就停，最后导出的 CSV 还可能乱码。这套代码适合三类人：前端要搭内部活动页的开发，运营想用静态页面救场的非技术同学，以及想搞明白滚动抽奖前端实现的新手。读完这一篇，你能从空白的 HTML 文件一路写到能上台抽奖的完整版本。

2. 手机号怎么进抽奖池：粘贴解析、去重过滤与批量校验

先做一个最小页面，把入口定下来。我一般用三个按钮加一个大屏区域：导入、开始、停止，中间一块显示号码的 screen，底部放中奖列表。代码结构不必酷炫，活动页面求的是稳。

<div id="app"> <textarea id="rawInput" rows="6" placeholder="粘贴手机号，每行一个，支持逗号、分号、空格分隔"></textarea> <button id="importBtn">导入号码</button> <button id="startBtn" disabled>开始</button> <button id="stopBtn" disabled>停止</button> <div id="screen">--</div> <ul id="winners"></ul> <button id="exportBtn" 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.38123E+10这种科学计数法，前端是救不回来的。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 刷号动画用 requestAnimationFrame，setInterval 的问题在哪

滚动刷号最直接的写法是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_DURATION：2.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;charset=utf-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 Mark，Excel 打开 CSV 时用它识别 UTF-8 编码，不加的话中文列名和备注大概率乱码。document.body.appendChild(a)再移除这一步，老版本浏览器里不把<a>挂进 DOM 就触发不了下载，加上没有坏处。导出按钮在 winners 为空时是 disabled 的，防止运营导出空文件。

到这个阶段，一个可用的页面已经成型。剩下的问题不是功能缺失，而是边界条件——下面这章集中写我踩过最深的几个坑。

5. 手机号滚动抽奖避坑排查：号码显示、随机性、掉帧与重复开奖

功能写完不等于能上活动。以下几条都是真实出现过的问题，按「现象、原因、解决」的方式记录。每一条背后都是现场的血泪经验。

5.1 号码显示不全的坑：空格、横线和科学计数法混入

现象是屏幕上的号码经常短一截，比如138123 45678显示成1381234567，或者直接显示1.38E+10。原因是 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直接变成 1，finishRoll被立即触发。

解决有两个方向。第一个方向是接受现实，在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_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 里恢复的中奖名单已经把已抽中的人过滤掉。做完这一轮，心里才有底。这套流程也推荐给你，毕竟抽奖页面是现场出错成本最高的那类页面，宁可多花十分钟准备。希望帮到你。

本文还有配套的精品资源，点击获取