Node.js短信验证码登录实战：免费短信接入与安全防刷策略

做验证码登录这个事，本来挺常规的，但真到自己上手 Node.js 从零写一遍，还是踩了不少坑。尤其是标题里那个“免费短信”，里面门道不少——平台送的测试条数到底能不能撑起日常开发，验证码存内存还是 Redis，接口被脚本刷了怎么办，这些东西文档里通常不会讲全。

这篇就把完整的实现过程拆开揉碎了说一遍，从流程设计、技术选型到核心代码、安全加固，再到我实测中遇到的各种报错和排查思路，全部分享出来。适合刚接触 Node.js 想做个带短信登录功能的同学，也适合后端转前端、想把登录逻辑彻底搞清楚的开发者。你照着捋一遍，基本能把这条链路上的每个环节都弄明白。

1. 登录功能的整体设计与流程拆解

1.1 短信验证码登录到底做了什么

很多刚接触的人会以为短信登录就是“填手机号，点击发送，输入收到的验证码，进系统”这么简单。真实的后端设计里，这背后至少涉及四段交互：

• 前端提交手机号，后端先做格式校验和频率检查；
• 后端生成六位随机验证码，带上过期时间存起来；
• 后端调用短信服务商的接口，把验证码通过短信发给用户手机；
• 用户拿到验证码填回表单，后端再拿这个验证码和之前存的比对，匹配且未过期，就签发登录凭证。

这里最容易忽略的是“存储”和“校验”这两个环节。验证码不是发出去就完事了，你得在一个地方记住它，而且这个记录必须能跟手机号对应上。同时校验动作不是简单的“相等就通过”，还要考虑过期、重复尝试、是否被篡改等边界情况。

1.2 技术选型：为什么是 Node.js + Express + Redis

主流程既然用 Node.js，后端框架选 Express 是最稳妥的选择，生态成熟、中间件丰富、出问题随便一搜都是答案。比 Koa 少折腾，比 NestJS 少套一层抽象，对大多数想快速落地的人来说，Express 完全够用。

存储方案这里我建议分两个阶段：

• 开发调试阶段，直接用一个内存 Map 存验证码，简单直观，重启就清空，不担心脏数据；
• 部署上线阶段，换成 Redis，设置键的过期时间让旧验证码自动失效，还能做发送频率计数，性能也远好于数据库查询。

你可能想问，为什么不用 MySQL？验证码本身就是“短命”数据，放 MySQL 还得定期手动清理，又慢又费劲。Redis 自带的 TTL 过期机制，天然就是为这种场景准备的。存储层的选择直接决定后续代码的复杂度，这一步想清楚，后面能省不少事。

短信平台的选择，核心看三点：是否有免费测试额度、API 签名是否容易申请、文档是否清晰。免费短信不是无限量，通常平台会送你几十条到几百条测试额度，够你在开发环境联调。真到了生产环境，该充值还是得充值，但这不妨碍你把整套逻辑跑通。

2. 免费短信平台的选择与接入

2.1 免费短信的真相：测试额度与替代方案

“免费短信”这四个字很容易让人误解。我在实际开发中确认过，市面上的主流短信服务商，免费部分基本都是“测试赠送条数”，常见的是送 10 到 100 条不等。这个量级拿来验证接口通不通、跑通登录流程是足够的，但如果你指望一直免费发下去，那肯定不现实。

除了平台赠送额度，还有一种开发期常用的替代方案：把验证码打到日志里，或者直接返回给前端展示。比如写代码时，发短信这个动作先走一个 mock 接口，网站控制台直接打印验证码，这样联调完全不花钱，也方便做自动化测试。等到真正要上线了，再切换成真实短信服务商。这个方案对省钱和调试非常友好，唯一的注意点是千万别忘了切回真实通道。

还有一点需要提前搞清楚，绝大多数短信平台的签名和模板是要审核的。签名就是短信前面那个【某某应用】，模板就是带变量的短信内容。审核一般几小时到一天不等，别等到上线当天才去申请。我见过太多项目因为签名没批下来，联调阶段全卡在发送环节。

2.2 对接短信平台的通用步骤

虽然各家平台的 API 长得不完全一样，但对接套路其实是通用的。我用一个通用的网关逻辑来说明，你替换成自己选的那家即可。

第一步，注册平台账号，完成企业或个人认证，然后新建一个应用，拿到 AccessKey 和 SecretKey。这两个凭证要放在后端环境变量里，绝对不要写进前端代码或传到仓库。

第二步，申请短信签名和模板。签名一般写产品名，模板里用占位符代替验证码内容。比如模板内容可以是“您的验证码是${code}，5分钟内有效”。审核通过后你会拿到模板ID。

第三步，后端封装一个发送函数。内部其实就是用 HTTPS 请求 POST 一条 JSON 到平台的发送接口，带上手机号、模板ID、模板参数和签名。平台返回 code 字段表示是否成功。

核心请求代码大致是这个样子：

const axios = require('axios'); const SMS_CONFIG = { accessKey: process.env.SMS_ACCESS_KEY, secretKey: process.env.SMS_SECRET_KEY, signName: process.env.SMS_SIGN_NAME, templateId: process.env.SMS_TEMPLATE_ID }; async function sendSmsCode(phone, code) { const url = 'https://sms.example.com/v1/send.json'; const params = { accessKey: SMS_CONFIG.accessKey, signName: SMS_CONFIG.signName, templateId: SMS_CONFIG.templateId, mobile: phone, param: JSON.stringify({ code }) }; // 实际平台需要对参数做签名校验，这里示意 params.signature = generateSignature(params); const resp = await axios.post(url, params); if (resp.data.code !== 200) { throw new Error(`短信发送失败: ${resp.data.msg}`); } return resp.data; }

不同平台在签名算法上有差异，有的是 MD5、有的是 HMAC-SHA256，这个没有通用解，照着平台文档实现就行。我提醒一点：先把最简单的请求跑通，再加签名逻辑，分开调试，问题更容易定位。上来就一定要全套，报错时反而分不清是参数问题还是签名问题。

3. Node.js 核心代码实现

3.1 验证码的生成与存储

验证码看起来就是Math.random()拼个六位数，但这个看似简单的操作里也有讲究。直接用Math.random()生成验证码是可以的，因为验证码有效期短、猜测成本高，并发量也不大，安全风险有限。但你最好用无重复数字或不容易混淆的组合，避免用户输错。

我习惯用生成随机六位数字字符串的函数，然后保证在并发下不重复：

function generateSmsCode() { return String(Math.floor(100000 + Math.random() * 900000)); }

这个函数返回的是 100000 到 999999 之间的整数，正好六位，前导零的情况也规避了。你可以先打印几次看看分布，一般都不会出问题。

存储我用一个封装好的验证码管理器，开发期用内存 Map，同时接口设计成跟存储实现解耦，方便以后换 Redis：

const codeStore = new Map(); function saveCode(phone, code, ttlSeconds = 300) { codeStore.set(phone, { code, expiresAt: Date.now() + ttlSeconds * 1000 }); } function getCode(phone) { const record = codeStore.get(phone); if (!record) return null; if (Date.now() > record.expiresAt) { codeStore.delete(phone); return null; } return record.code; }

如果切 Redis，只需要把 saveCode 换成set(phone, code, 'EX', ttlSeconds)，getCode 换成get(phone)，业务代码完全不用动。这种轻量的接口隔离，是我在实际项目里比较推荐的写法，成本极低，收益却很大。

3.2 短信发送接口封装

发送接口不能谁都能调，首先要做的是给前端暴露一个请求接口，由前端触发发送。后端在这个接口里做以下几件关键的事：

• 校验手机号格式是不是大陆手机号；
• 检查该手机号是否在 60 秒内已经发送过，避免恶意循环发送，白烧短信费；
• 检查当天发送次数是否超限；
• 生成验证码，存起来；
• 调用 sendSmsCode 真正发出短信；
• 把“已发送”状态和当前时间记录到存储里。

发送接口的代码大致如下：

const express = require('express'); const router = express.Router(); const SEND_COOLDOWN_MS = 60 * 1000; const DAILY_LIMIT = 10; router.post('/sms/send', async (req, res) => { const { phone } = req.body; if (!/^1[3-9]\d{9}$/.test(phone)) { return res.status(400).json({ code: 400, msg: '手机号格式不正确' }); } const lastSent = codeStore.get(phone + ':lastSent'); if (lastSent && Date.now() - lastSent < SEND_COOLDOWN_MS) { return res.status(429).json({ code: 429, msg: '发送太频繁，请稍后再试' }); } const today = new Date().toISOString().split('T')[0]; const dailyCount = await getDailyCount(phone, today); if (dailyCount >= DAILY_LIMIT) { return res.status(429).json({ code: 429, msg: '今日发送次数已用尽' }); } const code = generateSmsCode(); saveCode(phone, code); await sendSmsCode(phone, code); codeStore.set(phone + ':lastSent', Date.now()); await incrDailyCount(phone, today); res.json({ code: 200, msg: '验证码已发送' }); });

这里值得展开的是 60 秒冷却限制。没做过实际项目的人可能觉得“用户发起请求就会收到验证码”天经地义，但真实线上环境里，这条限制直接决定你的短信资费。一个手机号如果能在几分钟内无限触发，几百条测试额度瞬间就没了。除了冷却，每天配额、同一 IP 配额也都值得加，后面安全部分再细说。

3.3 验证码校验与登录逻辑

短信发送只是前半场，用户拿到验证码之后填回来校验，这部分才是登录的核心逻辑。校验接口做的事情必须严格：

• 取出用户提交的手机号和验证码；
• 从存储里取出之前存的验证码；
• 比对两者是否一致；
• 如果一致，清理掉这个验证码，防止重复使用；
• 签发一个登录凭证，比如 JWT；
• 返回给前端存起来。

代码如下：

const jwt = require('jsonwebtoken'); const JWT_SECRET = process.env.JWT_SECRET || 'your-secret-key'; router.post('/sms/verify', (req, res) => { const { phone, code } = req.body; if (!/^1[3-9]\d{9}$/.test(phone)) { return res.status(400).json({ code: 400, msg: '手机号格式不正确' }); } const storedCode = getCode(phone); if (!storedCode || storedCode !== code) { return res.status(400).json({ code: 400, msg: '验证码错误或已过期' }); } codeStore.delete(phone); const token = jwt.sign( { phone, loginAt: Date.now() }, JWT_SECRET, { expiresIn: '7d' } ); res.json({ code: 200, msg: '登录成功', data: { token, phone } }); });

校验失败会清掉验证码吗？我的建议是不清，但是要做失败次数限制。比如同一个手机号同一个验证码允许错 5 次，超过直接作废，必须重新获取。这样可以防止有人拿到你的手机号后，在没有短信验证码的情况下暴力穷举那 6 位数字。因为 6 位数字总共只有 90 万个组合，但没有限制地无限试的话，理论上是能试出来的。所以限制尝试次数这件事非常实际。

3.4 前端调用示例

前端逻辑简单，就是两个按钮两个表单。用户点“获取验证码”调发送接口，倒计时 60 秒；拿到验证码填进输入框，点“登录”调校验接口，成功后存 token，跳转首页。

用最朴素的 fetch 来实现：

async function sendSms() { const phone = document.getElementById('phone').value; const resp = await fetch('/api/sms/send', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ phone }) }); const data = await resp.json(); if (data.code === 200) { alert('验证码已发送，请查收短信'); startCountdown(60); } else { alert(data.msg); } } async function login() { const phone = document.getElementById('phone').value; const code = document.getElementById('code').value; const resp = await fetch('/api/sms/verify', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ phone, code }) }); const data = await resp.json(); if (data.code === 200) { localStorage.setItem('token', data.data.token); location.href = '/dashboard'; } else { alert(data.msg); } }

前端这里需要关注的细节不多，唯一要提醒的是倒计时不能只靠前端拦截。很多人以为按钮置灰就够了，实际上用户可以绕过前端直接调接口，所以真正的频率限制必须在后端做，前端只是体验上的配合。

4. 安全加固与踩坑实录

4.1 防刷操作：频率限制、IP限制、黑名单

免费额度被刷是个必经的教训。我测试的时候，曾因为没加任何限制，一下午被脚本刷掉了 100 多条短信。短信验证码登录面向公网，暴露在公网就意味着随时可能被脚本扫。加防刷不是可选项，而是必须项。

第一层，单手机号 60 秒冷却，已加过。第二层，单手机号每天限制 10 次，这层也加过。第三层，同一 IP 每天限制 30 次。第四层，可以用一个简单的计数器记录失败次数，达到阈值就拉入黑名单一段时间：

const ipFailMap = new Map(); function failRecord(ip) { const count = ipFailMap.get(ip) || 0; ipFailMap.set(ip, count + 1); } function isBlocked(ip) { const count = ipFailMap.get(ip) || 0; return count >= 10; }

要注意，IP 限制对移动网络用户不太友好，因为很多人会共享出口 IP，一个出口 IP 下有大量用户。所以 IP 的限制阈值应该比手机号宽松一些，宁可放宽一点，也别误伤正常用户。我实际用下来，单 IP 每天 30 到 50 次是比较合适的区间。

还有一点，短信验证码接口可以加一个简单的图形验证码或滑块验证，在发送前让用户先验证，这是行业内比较标准的做法。但为了保持登录体验流畅，很多小项目会省略这一步，自己权衡即可。省略的话，至少频率限制必须做扎实。

4.2 常见问题速查表

我把实际开发中高频出现的报错和排查思路整理成一张速查表，对照着解决问题会快很多。

第三条提醒一下，多实例部署是内存 Map 的“天坑”。本地单机跑完全没问题，一旦上了负载均衡、多个 Node 进程，用户 A 请求落在实例 1 存了验证码，校验时请求却打到实例 2，那当然永远校验失败。这也是我前面说上线换 Redis 的最大原因。

4.3 免费额度耗尽后的优雅降级

免费额度总有一天会用完，这个大家心里要有数。额度耗尽之后，接口并不会更聪明地告诉你，反而会让你的发送一直报错。此时有两种做法：

第一，在配置里维护一个每日发送量的计数器，接近免费额度上限时在后端日志里打警告，同时把短信发送开关自动降级为 mock 模式，验证码只在日志里输出，不再真实调用平台。这个方案适合全内网联调或演示环境。

第二，接入第二个备选短信平台，一个平台欠费或故障时自动切换。很多团队并不想多花钱，但只要你的业务量上来了，这个保障还是很有价值。备选平台可以只充值少量金额应急，不用保持同样的大额度。

我还试过一种更省钱的思路，用在内部测试环境：干脆不做真实发送，而是把验证码固定成123456，只对白名单手机号开放。这个方案适合小范围试用，上线前必须记得关掉，否则就相当于给账号开了个后门。

5. 实测中的代码级发现与细节补充

5.1 异步接口的正确处理

Node.js 里短信发送是一个耗时操作，通常在 200 毫秒到 1 秒不等。前端点击“获取验证码”时，后端不能因为等待短信平台返回就一直阻塞。上面代码里用了 async/await，这是最直接的解决方案。但有一点需要特别注意：发送失败时，之前存的验证码应该直接删掉，避免用户拿着一个未成功发送的验证码去登录。

可以用 try/catch 包裹发送逻辑，发送失败时清理存储并返回错误：

try { await sendSmsCode(phone, code); } catch (e) { codeStore.delete(phone); return res.status(500).json({ code: 500, msg: '短信发送失败，请稍后再试' }); }

这段代码看着小，但实际价值不小。不写的话，发送失败后用户依然能伪造一个验证码来撞校验，而且存储里留着无效记录，逻辑就处于一种脏状态。从失败状态里恢复得干净，这个习惯很重要。

5.2 验证码的安全存储与业务隔离

验证码本身不是机密，但它在登录链路中的角色很敏感。开发时为了方便，可能会把验证码直接打到日志里，这个在本地没问题，上线后一定要把日志级别调整好，不能把验证码打到生产日志。否则运维或拿到日志的人都能看到原始验证码。

另一个容易被忽略的点，是同一个手机号在“发送验证码”和“注册登录”两条业务上最好互相隔离。如果这个手机号已经被注册，走的是登录逻辑；如果没注册，走的是注册逻辑。不要因为验证码相同而混用两套流程，这样做容易在后续排查问题时产生混乱。

5.3 环境变量的管理

短信平台的密钥，JWT 的密钥，这些都不能写进代码里。我在项目里通常准备两个文件：.env.example提交到仓库，里面只放变量名不放真实值；.env本地保留而被 git 忽略。加载方式可以用 Node.js 自带的process.env配合 dotenv 解析，也可以用node --env-file=.env直接加载。Maintenance 上不用担心，唯一要保证的是提交代码时不要把.env误传上去。

这里补充一个真实遇到的事故：某次上线后一直报签名错误，查了三个小时发现是部署时环境变量没有注入。这个问题很常见，因为本地运行有默认值，部署平台却可能把变量名改掉了。建议上线前写两分钟的自检脚本，打印出短信配置里几个关键字段是否存在。

写在最后的一点心得

整个项目跑下来，我最大的感受是：验证码登录这个功能，代码量不大，但在工程上的边界却不少。它牵扯到防刷策略、存储选型、第三方依赖、密钥管理，每个点单独看都不难，组合起来就考验综合能力了。尤其“免费短信”这个点，其实更像是开发期的缓冲手段，真正要可靠地跑在生产环境，短信资费是必须考虑的预算项。

如果你是自己做小项目，我建议按这个顺序推进：先写 mock 通道把整个登录流程跑通，再把发送接口换成真实短信平台，最后把频率限制和防刷策略补上。别一上来就追求一步到位，迭代式开发带来的调试便利，远比一次写完带来的成就感更踏实。

最后再分享一个小技巧：测试短信接口时，用真实手机号会消耗额度，所以可以留一个专用的测试手机号，其他测试一律走 mock。等 mock 通道验证完所有流程，再拿测试手机号打一两条真短信确认平台链路没问题，这样的额度消耗是最省的。你自己动手做一遍，肯定能体会到这些细节的价值。