1. 从一个真实需求说起为什么邮箱验证码模块值得自己写前阵子帮一个做独立开发的朋友处理注册流程他原本用的是某平台的短信验证码服务量一上来成本压不住而且海外用户收短信经常延迟。聊下来发现他的用户群体其实大部分都有邮箱注册场景对实时性要求没那么苛刻验证码晚到十几秒完全可以接受。于是我们决定把注册验证环节从短信切到邮箱自己写一个发送验证码的模块。这个模块听起来简单——不就是调个接口发封信吗但真动手写你会发现要处理的事情比想象中多验证码怎么生成才不容易被撞库、发送频率怎么限制、验证码存哪里、多久过期、怎么防止同一个邮箱被反复轰炸、前端怎么配合倒计时、发送失败了怎么重试、邮件进了垃圾箱怎么办。这些问题不解决上线就是给自己挖坑。这篇文章就是把这套东西从头到尾捋一遍。我会用一个 Web 端邮箱验证码模块作为主线把设计思路、核心代码、参数计算、踩过的坑都摊开讲。适合有一定后端基础、想自己实现验证码发送的开发者也适合正在做注册登录流程、纠结要不要接第三方服务的人。读完你至少能拿到一套可以直接改改就用的方案并且知道每个环节为什么这么设计。需要提前说明的是下面涉及的服务商配置、域名、账号信息我都会用占位符代替你替换成自己的即可。整个方案不依赖任何特定平台思路是通用的。2. 整体设计这个模块到底由哪些部分组成2.1 先想清楚一件事验证码的本质是什么很多人一上来就写代码结果写到一半发现逻辑对不上。我习惯先把本质想清楚。邮箱验证码的本质是一次有时效的、一次性的、绑定到某个邮箱地址的凭证。拆开看有三个关键词有时效过了时间就作废通常是 5 到 10 分钟。一次性用过一次就失效不能重复使用。绑定邮箱这个码只能用于验证这个邮箱换个邮箱就不认。理解了这三点后面所有的设计都是围绕它们展开的。比如“有时效”决定了你要存过期时间“一次性”决定了验证成功后要立刻删除“绑定邮箱”决定了存储的 key 里必须包含邮箱地址。2.2 模块的四个核心环节把整个流程拆开其实是四个环节在循环生成用户请求发送后端生成一个随机验证码。存储把验证码和邮箱、过期时间一起存起来。发送通过邮件服务把验证码投递到用户邮箱。校验用户提交验证码后端比对并决定是否通过。这四个环节里存储是最容易被忽视但最关键的。很多人图省事把验证码放在内存里单机跑没问题一上多实例就出问题——用户在 A 实例请求发送请求校验时负载均衡打到 B 实例B 实例内存里根本没有这个码直接验证失败。所以存储一定要用共享存储Redis 是最常见的选择。2.3 技术选型为什么是这套组合我把选型逻辑列一下你可以对照自己的场景调整环节选型理由验证码生成加密安全随机数普通随机数可预测容易被撞存储Redis TTL天然支持过期性能好多实例共享邮件发送SMTP 协议通用不绑定特定服务商频率限制Redis 计数器复用存储实现简单前端交互倒计时 防重复点击减少无效请求这里重点说下为什么用 SMTP 而不是某个服务商的 SDK。SMTP 是邮件发送的通用协议几乎所有邮件服务商都支持。用 SMTP 意味着你换服务商时只需要改配置不用改代码。SDK 虽然封装得好但一旦服务商调整接口或者你想换一家迁移成本就上来了。对于验证码这种标准化程度极高的场景SMTP 完全够用。2.4 一个容易被忽略的设计验证码要不要存明文这个问题我纠结过。存明文的好处是排查问题方便出问题时能直接看到用户收到的码是什么。坏处是一旦 Redis 被拖库攻击者能直接拿到所有待验证的码。我的做法是存明文但加短过期。原因是验证码本身时效极短5 分钟且一次性使用即使泄露攻击窗口也很小。相比之下排查问题的便利性更重要。如果你的场景安全要求极高可以存哈希值代价是排查时只能确认“对不对”而看不到原值。这个取舍没有标准答案看你的业务敏感度。3. 核心细节拆解每个环节的坑与解法3.1 验证码怎么生成才安全先看一段很多人会写的代码import random code random.randint(100000, 999999)这段代码的问题在于random模块是伪随机数生成器它的种子如果被猜到整个序列就能被预测。对于验证码这种安全凭证必须用加密安全的随机源。正确的写法import secrets code .join(secrets.choice(0123456789) for _ in range(6))secrets模块底层调用操作系统的加密随机源不可预测。位数上我建议6 位数字这是体验和安全的一个平衡点。4 位太容易被暴力破解一万种组合脚本几秒就跑完8 位用户输入起来嫌烦。6 位有 100 万种组合配合频率限制足够安全。注意不要用递增、时间戳、邮箱哈希等可推导的方式生成验证码。我见过有人用邮箱的 MD5 前 6 位当验证码这等于把验证码公开了。3.2 存储结构怎么设计Redis 的 key 设计直接决定了后续逻辑的复杂度。我用的结构是这样的verify:code:{email} - 验证码值TTL 300 秒 verify:limit:{email} - 发送次数计数TTL 60 秒 verify:lock:{email} - 发送锁TTL 60 秒三个 key 各司其职verify:code:{email}存验证码本身5 分钟过期。verify:limit:{email}做频率限制记录 60 秒内发了几次。verify:lock:{email}防止并发重复发送用户连点按钮时只有一个请求能真正发出去。为什么用邮箱而不是用户 ID 做 key因为注册场景下用户还没登录没有用户 ID邮箱是唯一标识。而且验证码本来就是绑定邮箱的用邮箱做 key 语义上也更自然。TTL 的设置有个细节验证码的 TTL 和频率限制的 TTL 要分开。验证码 5 分钟频率限制 60 秒。如果混用一个 TTL要么验证码过期太快要么频率限制形同虚设。3.3 频率限制的三种粒度只做一层频率限制是不够的。我实际用的是三层单邮箱 60 秒内只能发一次防止用户狂点。单邮箱 1 小时内最多发 5 次防止有人拿一个邮箱反复刷。单 IP 1 小时内最多发 20 次防止有人用脚本换邮箱批量刷。第一层用verify:lock实现第二层用一个带计数器的 key第三层按 IP 计数。三层叠加基本能挡住绝大多数滥用。这里有个参数计算的细节。为什么是 60 秒而不是 30 秒因为邮件投递本身有延迟用户点了发送后可能十几秒才收到。如果限制 30 秒用户等得不耐烦又点一次反而触发限制体验很差。60 秒给了足够的缓冲也和前端倒计时对齐。3.4 邮件内容怎么写才不容易进垃圾箱这是最容易被低估的环节。很多人代码写得没问题但邮件全进了垃圾箱用户根本收不到。影响进箱率的因素很多我挑几个可控的讲发件人域名要有 SPF 记录告诉收件方哪些服务器有权用你的域名发信。配置 DKIM 签名给邮件加上数字签名证明没被篡改。配置 DMARC 策略告诉收件方收到伪造邮件时怎么处理。邮件内容别太“营销”标题里别用“免费”“中奖”“限时”这类词正文别塞大量链接和图片。邮件正文我建议极简就一段话加一个验证码您的验证码是123456 5 分钟内有效请勿泄露给他人。 如非本人操作请忽略此邮件。标题用“您的验证码”或者“验证码”就行别搞花哨的。实测下来越朴素的邮件越容易进收件箱。提示SPF、DKIM、DMARC 这三项配置是邮件送达率的基础不做的话进垃圾箱的概率非常高。具体配置方法各家 DNS 服务商都有文档照着填就行。4. 实操过程从零把模块跑起来4.1 环境准备与依赖安装我用 Python 举例其他语言思路一样。需要两个核心库pip install redis pip install secure-smtplibredis用来操作存储secure-smtplib是标准库smtplib的增强版对 TLS 支持更好。如果你用其他语言找对应的 Redis 客户端和 SMTP 库即可。Redis 我建议本地起一个测试实例docker run -d -p 6379:6379 redis:7生产环境用云 Redis 或者自建集群都行关键是所有应用实例要连同一个 Redis这是多实例共享验证码的前提。4.2 配置邮件发送参数邮件发送的配置我抽成一个独立的配置块方便替换SMTP_CONFIG { host: smtp.example.com, # 替换成你的 SMTP 服务器 port: 465, # SSL 端口587 是 STARTTLS user: noreplyexample.com, # 发件邮箱 password: your_password, # 邮箱授权码不是登录密码 sender: noreplyexample.com, }这里有个大坑password 填的是授权码不是邮箱登录密码。绝大多数邮箱服务商都要求用授权码直接填登录密码会认证失败。授权码在邮箱设置里生成每个服务商位置不同找一下就有。端口的选择465 是 SSL 加密587 是 STARTTLS 加密。两者都安全465 更省事我一般用 465。4.3 核心发送逻辑实现把生成、存储、发送串起来核心函数大概长这样import secrets import redis import smtplib from email.mime.text import MIMEText from email.header import Header r redis.Redis(hostlocalhost, port6379, decode_responsesTrue) def send_verify_code(email): # 第一层并发锁 lock_key fverify:lock:{email} if not r.set(lock_key, 1, nxTrue, ex60): return {ok: False, msg: 请求过于频繁请稍后再试} # 第二层小时级频率限制 limit_key fverify:limit:{email} count r.incr(limit_key) if count 1: r.expire(limit_key, 3600) if count 5: return {ok: False, msg: 发送次数过多请一小时后再试} # 生成验证码 code .join(secrets.choice(0123456789) for _ in range(6)) # 存储5 分钟过期 r.set(fverify:code:{email}, code, ex300) # 发送邮件 try: send_email(email, code) except Exception as e: # 发送失败要回滚计数否则用户白白消耗一次额度 r.decr(limit_key) r.delete(lock_key) return {ok: False, msg: 发送失败请稍后重试} return {ok: True, msg: 发送成功}这段代码有几个关键点值得展开并发锁用set nx exnxTrue表示 key 不存在时才设置ex60是过期时间。这两者组合是一个原子操作能保证同一时刻只有一个请求能拿到锁。如果用先get再set的写法两个请求可能同时通过检查锁就失效了。计数器的过期设置incr之后判断是不是第一次是的话才设过期。如果每次都设过期计数永远不会归零用户会被永久限制。这个细节很多人会写错。发送失败要回滚邮件发送可能因为网络、认证等原因失败。失败时如果不把计数减回去用户明明没收到邮件却消耗了一次额度体验很差。回滚计数和删除锁是必要的补偿操作。4.4 邮件发送函数def send_email(to_email, code): msg MIMEText( f您的验证码是{code}\n5 分钟内有效请勿泄露给他人。\n如非本人操作请忽略此邮件。, plain, utf-8 ) msg[From] Header(SMTP_CONFIG[sender]) msg[To] Header(to_email) msg[Subject] Header(您的验证码, utf-8) with smtplib.SMTP_SSL(SMTP_CONFIG[host], SMTP_CONFIG[port]) as server: server.login(SMTP_CONFIG[user], SMTP_CONFIG[password]) server.sendmail(SMTP_CONFIG[sender], [to_email], msg.as_string())用SMTP_SSL而不是SMTP因为 465 端口需要 SSL 连接。如果用 587 端口要改成SMTP加starttls()。4.5 校验逻辑实现校验比发送简单但有个细节要注意def verify_code(email, input_code): key fverify:code:{email} stored r.get(key) if not stored: return {ok: False, msg: 验证码已过期或未发送} if stored ! input_code: return {ok: False, msg: 验证码错误} # 验证成功立刻删除保证一次性 r.delete(key) return {ok: True, msg: 验证成功}验证成功后立刻删除是保证“一次性”的关键。如果不删同一个码在 5 分钟内可以反复使用安全性大打折扣。还有个进阶做法错误次数限制。如果同一个邮箱连续输错 5 次直接把这个码作废要求重新发送。这能防止有人暴力枚举。实现上可以加一个verify:fail:{email}计数器每次错误加一超过阈值就删掉验证码。4.6 前端配合倒计时与防重复点击后端做再多限制前端不配合体验也会差。前端要做两件事点击后立刻禁用按钮开始 60 秒倒计时。倒计时结束才允许再次点击。倒计时期间按钮显示剩余秒数让用户知道还要等多久。let counting false; async function sendCode() { if (counting) return; counting true; const btn document.getElementById(sendBtn); btn.disabled true; const res await fetch(/api/send-code, { method: POST, headers: {Content-Type: application/json}, body: JSON.stringify({email: getEmail()}) }); const data await res.json(); if (!data.ok) { alert(data.msg); counting false; btn.disabled false; return; } let left 60; btn.textContent ${left} 秒后重试; const timer setInterval(() { left--; if (left 0) { clearInterval(timer); btn.textContent 发送验证码; btn.disabled false; counting false; } else { btn.textContent ${left} 秒后重试; } }, 1000); }前端的倒计时和后端的 60 秒锁是对齐的。这样用户看到倒计时结束时后端的锁也刚好过期点击就能成功不会出现“倒计时结束了但后端还提示频繁”的尴尬。5. 常见问题与排查技巧实录5.1 邮件发送失败排查表邮件发不出去是最常见的问题我整理了一张排查表现象可能原因排查方法认证失败用了登录密码而非授权码检查配置里的 password连接超时端口或 host 错误确认 465/587 和 SMTP 地址被拒收发件域名无 SPF/DKIM检查 DNS 记录进垃圾箱内容触发垃圾规则简化正文去掉营销词部分收不到收件方服务器限流降低发送频率加退避重试5.2 验证码收不到但接口返回成功这个问题的迷惑性很强。接口返回成功只代表邮件提交给了 SMTP 服务器不代表用户收到了。中间可能经过好几跳任何一跳出问题都收不到。排查思路是分层确认先确认 SMTP 服务器有没有接受看返回码再确认对方邮件服务器有没有接收看发件箱的投递状态最后确认用户是不是在垃圾箱里。大部分“收不到”其实是进了垃圾箱。5.3 多实例部署后验证码失效这是前面提过的经典问题。单机测试一切正常一上多实例就出现“发送成功但验证失败”。根因是验证码存在了某个实例的本地内存里。解法就是用共享存储。Redis 是最常见的选择也可以用数据库或者专门的缓存服务。核心原则是所有实例读写同一份数据。5.4 用户狂点导致收到多封邮件前端禁用按钮能挡住大部分但挡不住直接调接口的。后端的并发锁是最后一道防线。set nx ex保证同一时刻只有一个请求能真正执行发送逻辑其他请求直接返回“请求过于频繁”。实操心得并发锁的过期时间要和前端倒计时对齐都是 60 秒。如果锁设成 30 秒用户倒计时还没结束锁就过期了狂点又能发出去。5.5 验证码被暴力枚举6 位数字有 100 万种组合看起来很多但如果没有任何限制脚本每秒试几百次几个小时就能跑完。防护手段有两个一是错误次数限制同一个邮箱错 5 次就作废二是IP 级频率限制单个 IP 的验证请求也要限速。这两个限制叠加暴力枚举的成本会高到不划算。记住一个原则任何可以被反复尝试的接口都必须有限速。6. 一些让模块更稳的进阶做法6.1 异步发送别阻塞请求上面的代码是同步发送邮件的用户请求后要等邮件发完才返回。SMTP 发送有时候要几秒用户会感觉卡。更好的做法是把发送任务丢到队列里接口立刻返回“发送中”后台 worker 慢慢发。实现上可以用 Celery、RQ 这类任务队列也可以用简单的线程池。对于验证码这种量不大的场景线程池就够了。量大了再上专业队列。6.2 发送失败的重试与降级邮件发送偶尔失败是正常的网络抖动、对方服务器临时不可用都会导致失败。加一个简单的重试机制能显著提升成功率失败后隔几秒重试一次最多重试两次。如果还是失败返回明确的错误提示让用户稍后再试。重试要注意幂等别因为重试导致用户收到多封邮件。可以在重试前检查验证码是否还在在的话说明还没发成功可以重发。6.3 监控与告警上线后要盯着几个指标发送成功率、平均送达时间、验证成功率。发送成功率突然下降可能是 SMTP 配置出问题或者被限流了。验证成功率低可能是邮件进垃圾箱了。这些指标能帮你第一时间发现问题。我一般会在发送成功和失败的地方打点统计每分钟的成功率。低于某个阈值就告警。这个投入不大但能省很多排查时间。6.4 验证码的清理策略Redis 的 TTL 会自动清理过期的验证码不用手动删。但有个细节如果用户请求发送后一直不验证验证码会在 5 分钟后自动消失这是符合预期的。不需要额外的清理任务。唯一要注意的是频率限制的 key。如果用户发了一次就再也不来了那个计数 key 会在 1 小时后自动过期也不会堆积。所以整个方案的存储是自清理的不需要维护定时任务。7. 关于这套方案我踩过的几个坑第一个坑是授权码和登录密码搞混。第一次配置时我直接填了邮箱登录密码认证一直失败排查了半天才反应过来要用授权码。这个错误很低级但很常见配置时一定要确认。第二个坑是忘了配 SPF 记录。代码跑通了邮件也发出去了但用户反馈收不到。查了半天发现全进了垃圾箱。配好 SPF 和 DKIM 之后进箱率立刻上来了。邮件送达这件事代码只占一半域名配置占另一半。第三个坑是并发锁的过期时间设太短。一开始设了 30 秒结果用户倒计时还没结束锁就过期了狂点又能发出去。后来统一成 60 秒和前端对齐问题解决。第四个坑是发送失败没回滚计数。有次 SMTP 服务商临时故障用户点了发送邮件没发出去但计数被消耗了。用户重试几次后就被限制了一小时投诉说“明明没收到却说发太多次”。加上失败回滚之后就正常了。这些坑都不复杂但都是实际跑起来才会遇到的。写代码时多想想异常路径能省很多事后排查的功夫。8. 后续可以怎么扩展这套模块跑通之后扩展方向挺多的。比如把邮件模板抽出来做成可配置的不同场景用不同模板比如加上多语言支持海外用户收到英文邮件比如把发送渠道抽象成接口邮件、短信、站内信都能接业务代码不用改。再往深了做可以加行为风控。比如同一个 IP 短时间内注册大量账号自动提高验证门槛比如检测邮箱格式和域名拦截明显的垃圾邮箱。这些都属于锦上添花核心的发送和校验逻辑稳了其他都好加。我个人在实际操作中的体会是验证码模块看着简单但它是注册登录流程的第一道门稳定性直接影响转化率。宁可前期多花点时间把频率限制、异常处理、邮件送达这些细节做扎实也别等上线后用户投诉了再回头补。这套方案我用了挺久量级从每天几百到几万都没出过问题你可以放心参考。 
长河君 · 2026/10/15 14:03:21 · 阅读 1.2k 从零实现邮箱验证码模块：Redis存储、SMTP发送与频率限制
1. 从一个真实需求说起为什么邮箱验证码模块值得自己写前阵子帮一个做独立开发的朋友处理注册流程他原本用的是某平台的短信验证码服务量一上来成本压不住而且海外用户收短信经常延迟。聊下来发现他的用户群体其实大部分都有邮箱注册场景对实时性要求没那么苛刻验证码晚到十几秒完全可以接受。于是我们决定把注册验证环节从短信切到邮箱自己写一个发送验证码的模块。这个模块听起来简单——不就是调个接口发封信吗但真动手写你会发现要处理的事情比想象中多验证码怎么生成才不容易被撞库、发送频率怎么限制、验证码存哪里、多久过期、怎么防止同一个邮箱被反复轰炸、前端怎么配合倒计时、发送失败了怎么重试、邮件进了垃圾箱怎么办。这些问题不解决上线就是给自己挖坑。这篇文章就是把这套东西从头到尾捋一遍。我会用一个 Web 端邮箱验证码模块作为主线把设计思路、核心代码、参数计算、踩过的坑都摊开讲。适合有一定后端基础、想自己实现验证码发送的开发者也适合正在做注册登录流程、纠结要不要接第三方服务的人。读完你至少能拿到一套可以直接改改就用的方案并且知道每个环节为什么这么设计。需要提前说明的是下面涉及的服务商配置、域名、账号信息我都会用占位符代替你替换成自己的即可。整个方案不依赖任何特定平台思路是通用的。2. 整体设计这个模块到底由哪些部分组成2.1 先想清楚一件事验证码的本质是什么很多人一上来就写代码结果写到一半发现逻辑对不上。我习惯先把本质想清楚。邮箱验证码的本质是一次有时效的、一次性的、绑定到某个邮箱地址的凭证。拆开看有三个关键词有时效过了时间就作废通常是 5 到 10 分钟。一次性用过一次就失效不能重复使用。绑定邮箱这个码只能用于验证这个邮箱换个邮箱就不认。理解了这三点后面所有的设计都是围绕它们展开的。比如“有时效”决定了你要存过期时间“一次性”决定了验证成功后要立刻删除“绑定邮箱”决定了存储的 key 里必须包含邮箱地址。2.2 模块的四个核心环节把整个流程拆开其实是四个环节在循环生成用户请求发送后端生成一个随机验证码。存储把验证码和邮箱、过期时间一起存起来。发送通过邮件服务把验证码投递到用户邮箱。校验用户提交验证码后端比对并决定是否通过。这四个环节里存储是最容易被忽视但最关键的。很多人图省事把验证码放在内存里单机跑没问题一上多实例就出问题——用户在 A 实例请求发送请求校验时负载均衡打到 B 实例B 实例内存里根本没有这个码直接验证失败。所以存储一定要用共享存储Redis 是最常见的选择。2.3 技术选型为什么是这套组合我把选型逻辑列一下你可以对照自己的场景调整环节选型理由验证码生成加密安全随机数普通随机数可预测容易被撞存储Redis TTL天然支持过期性能好多实例共享邮件发送SMTP 协议通用不绑定特定服务商频率限制Redis 计数器复用存储实现简单前端交互倒计时 防重复点击减少无效请求这里重点说下为什么用 SMTP 而不是某个服务商的 SDK。SMTP 是邮件发送的通用协议几乎所有邮件服务商都支持。用 SMTP 意味着你换服务商时只需要改配置不用改代码。SDK 虽然封装得好但一旦服务商调整接口或者你想换一家迁移成本就上来了。对于验证码这种标准化程度极高的场景SMTP 完全够用。2.4 一个容易被忽略的设计验证码要不要存明文这个问题我纠结过。存明文的好处是排查问题方便出问题时能直接看到用户收到的码是什么。坏处是一旦 Redis 被拖库攻击者能直接拿到所有待验证的码。我的做法是存明文但加短过期。原因是验证码本身时效极短5 分钟且一次性使用即使泄露攻击窗口也很小。相比之下排查问题的便利性更重要。如果你的场景安全要求极高可以存哈希值代价是排查时只能确认“对不对”而看不到原值。这个取舍没有标准答案看你的业务敏感度。3. 核心细节拆解每个环节的坑与解法3.1 验证码怎么生成才安全先看一段很多人会写的代码import random code random.randint(100000, 999999)这段代码的问题在于random模块是伪随机数生成器它的种子如果被猜到整个序列就能被预测。对于验证码这种安全凭证必须用加密安全的随机源。正确的写法import secrets code .join(secrets.choice(0123456789) for _ in range(6))secrets模块底层调用操作系统的加密随机源不可预测。位数上我建议6 位数字这是体验和安全的一个平衡点。4 位太容易被暴力破解一万种组合脚本几秒就跑完8 位用户输入起来嫌烦。6 位有 100 万种组合配合频率限制足够安全。注意不要用递增、时间戳、邮箱哈希等可推导的方式生成验证码。我见过有人用邮箱的 MD5 前 6 位当验证码这等于把验证码公开了。3.2 存储结构怎么设计Redis 的 key 设计直接决定了后续逻辑的复杂度。我用的结构是这样的verify:code:{email} - 验证码值TTL 300 秒 verify:limit:{email} - 发送次数计数TTL 60 秒 verify:lock:{email} - 发送锁TTL 60 秒三个 key 各司其职verify:code:{email}存验证码本身5 分钟过期。verify:limit:{email}做频率限制记录 60 秒内发了几次。verify:lock:{email}防止并发重复发送用户连点按钮时只有一个请求能真正发出去。为什么用邮箱而不是用户 ID 做 key因为注册场景下用户还没登录没有用户 ID邮箱是唯一标识。而且验证码本来就是绑定邮箱的用邮箱做 key 语义上也更自然。TTL 的设置有个细节验证码的 TTL 和频率限制的 TTL 要分开。验证码 5 分钟频率限制 60 秒。如果混用一个 TTL要么验证码过期太快要么频率限制形同虚设。3.3 频率限制的三种粒度只做一层频率限制是不够的。我实际用的是三层单邮箱 60 秒内只能发一次防止用户狂点。单邮箱 1 小时内最多发 5 次防止有人拿一个邮箱反复刷。单 IP 1 小时内最多发 20 次防止有人用脚本换邮箱批量刷。第一层用verify:lock实现第二层用一个带计数器的 key第三层按 IP 计数。三层叠加基本能挡住绝大多数滥用。这里有个参数计算的细节。为什么是 60 秒而不是 30 秒因为邮件投递本身有延迟用户点了发送后可能十几秒才收到。如果限制 30 秒用户等得不耐烦又点一次反而触发限制体验很差。60 秒给了足够的缓冲也和前端倒计时对齐。3.4 邮件内容怎么写才不容易进垃圾箱这是最容易被低估的环节。很多人代码写得没问题但邮件全进了垃圾箱用户根本收不到。影响进箱率的因素很多我挑几个可控的讲发件人域名要有 SPF 记录告诉收件方哪些服务器有权用你的域名发信。配置 DKIM 签名给邮件加上数字签名证明没被篡改。配置 DMARC 策略告诉收件方收到伪造邮件时怎么处理。邮件内容别太“营销”标题里别用“免费”“中奖”“限时”这类词正文别塞大量链接和图片。邮件正文我建议极简就一段话加一个验证码您的验证码是123456 5 分钟内有效请勿泄露给他人。 如非本人操作请忽略此邮件。标题用“您的验证码”或者“验证码”就行别搞花哨的。实测下来越朴素的邮件越容易进收件箱。提示SPF、DKIM、DMARC 这三项配置是邮件送达率的基础不做的话进垃圾箱的概率非常高。具体配置方法各家 DNS 服务商都有文档照着填就行。4. 实操过程从零把模块跑起来4.1 环境准备与依赖安装我用 Python 举例其他语言思路一样。需要两个核心库pip install redis pip install secure-smtplibredis用来操作存储secure-smtplib是标准库smtplib的增强版对 TLS 支持更好。如果你用其他语言找对应的 Redis 客户端和 SMTP 库即可。Redis 我建议本地起一个测试实例docker run -d -p 6379:6379 redis:7生产环境用云 Redis 或者自建集群都行关键是所有应用实例要连同一个 Redis这是多实例共享验证码的前提。4.2 配置邮件发送参数邮件发送的配置我抽成一个独立的配置块方便替换SMTP_CONFIG { host: smtp.example.com, # 替换成你的 SMTP 服务器 port: 465, # SSL 端口587 是 STARTTLS user: noreplyexample.com, # 发件邮箱 password: your_password, # 邮箱授权码不是登录密码 sender: noreplyexample.com, }这里有个大坑password 填的是授权码不是邮箱登录密码。绝大多数邮箱服务商都要求用授权码直接填登录密码会认证失败。授权码在邮箱设置里生成每个服务商位置不同找一下就有。端口的选择465 是 SSL 加密587 是 STARTTLS 加密。两者都安全465 更省事我一般用 465。4.3 核心发送逻辑实现把生成、存储、发送串起来核心函数大概长这样import secrets import redis import smtplib from email.mime.text import MIMEText from email.header import Header r redis.Redis(hostlocalhost, port6379, decode_responsesTrue) def send_verify_code(email): # 第一层并发锁 lock_key fverify:lock:{email} if not r.set(lock_key, 1, nxTrue, ex60): return {ok: False, msg: 请求过于频繁请稍后再试} # 第二层小时级频率限制 limit_key fverify:limit:{email} count r.incr(limit_key) if count 1: r.expire(limit_key, 3600) if count 5: return {ok: False, msg: 发送次数过多请一小时后再试} # 生成验证码 code .join(secrets.choice(0123456789) for _ in range(6)) # 存储5 分钟过期 r.set(fverify:code:{email}, code, ex300) # 发送邮件 try: send_email(email, code) except Exception as e: # 发送失败要回滚计数否则用户白白消耗一次额度 r.decr(limit_key) r.delete(lock_key) return {ok: False, msg: 发送失败请稍后重试} return {ok: True, msg: 发送成功}这段代码有几个关键点值得展开并发锁用set nx exnxTrue表示 key 不存在时才设置ex60是过期时间。这两者组合是一个原子操作能保证同一时刻只有一个请求能拿到锁。如果用先get再set的写法两个请求可能同时通过检查锁就失效了。计数器的过期设置incr之后判断是不是第一次是的话才设过期。如果每次都设过期计数永远不会归零用户会被永久限制。这个细节很多人会写错。发送失败要回滚邮件发送可能因为网络、认证等原因失败。失败时如果不把计数减回去用户明明没收到邮件却消耗了一次额度体验很差。回滚计数和删除锁是必要的补偿操作。4.4 邮件发送函数def send_email(to_email, code): msg MIMEText( f您的验证码是{code}\n5 分钟内有效请勿泄露给他人。\n如非本人操作请忽略此邮件。, plain, utf-8 ) msg[From] Header(SMTP_CONFIG[sender]) msg[To] Header(to_email) msg[Subject] Header(您的验证码, utf-8) with smtplib.SMTP_SSL(SMTP_CONFIG[host], SMTP_CONFIG[port]) as server: server.login(SMTP_CONFIG[user], SMTP_CONFIG[password]) server.sendmail(SMTP_CONFIG[sender], [to_email], msg.as_string())用SMTP_SSL而不是SMTP因为 465 端口需要 SSL 连接。如果用 587 端口要改成SMTP加starttls()。4.5 校验逻辑实现校验比发送简单但有个细节要注意def verify_code(email, input_code): key fverify:code:{email} stored r.get(key) if not stored: return {ok: False, msg: 验证码已过期或未发送} if stored ! input_code: return {ok: False, msg: 验证码错误} # 验证成功立刻删除保证一次性 r.delete(key) return {ok: True, msg: 验证成功}验证成功后立刻删除是保证“一次性”的关键。如果不删同一个码在 5 分钟内可以反复使用安全性大打折扣。还有个进阶做法错误次数限制。如果同一个邮箱连续输错 5 次直接把这个码作废要求重新发送。这能防止有人暴力枚举。实现上可以加一个verify:fail:{email}计数器每次错误加一超过阈值就删掉验证码。4.6 前端配合倒计时与防重复点击后端做再多限制前端不配合体验也会差。前端要做两件事点击后立刻禁用按钮开始 60 秒倒计时。倒计时结束才允许再次点击。倒计时期间按钮显示剩余秒数让用户知道还要等多久。let counting false; async function sendCode() { if (counting) return; counting true; const btn document.getElementById(sendBtn); btn.disabled true; const res await fetch(/api/send-code, { method: POST, headers: {Content-Type: application/json}, body: JSON.stringify({email: getEmail()}) }); const data await res.json(); if (!data.ok) { alert(data.msg); counting false; btn.disabled false; return; } let left 60; btn.textContent ${left} 秒后重试; const timer setInterval(() { left--; if (left 0) { clearInterval(timer); btn.textContent 发送验证码; btn.disabled false; counting false; } else { btn.textContent ${left} 秒后重试; } }, 1000); }前端的倒计时和后端的 60 秒锁是对齐的。这样用户看到倒计时结束时后端的锁也刚好过期点击就能成功不会出现“倒计时结束了但后端还提示频繁”的尴尬。5. 常见问题与排查技巧实录5.1 邮件发送失败排查表邮件发不出去是最常见的问题我整理了一张排查表现象可能原因排查方法认证失败用了登录密码而非授权码检查配置里的 password连接超时端口或 host 错误确认 465/587 和 SMTP 地址被拒收发件域名无 SPF/DKIM检查 DNS 记录进垃圾箱内容触发垃圾规则简化正文去掉营销词部分收不到收件方服务器限流降低发送频率加退避重试5.2 验证码收不到但接口返回成功这个问题的迷惑性很强。接口返回成功只代表邮件提交给了 SMTP 服务器不代表用户收到了。中间可能经过好几跳任何一跳出问题都收不到。排查思路是分层确认先确认 SMTP 服务器有没有接受看返回码再确认对方邮件服务器有没有接收看发件箱的投递状态最后确认用户是不是在垃圾箱里。大部分“收不到”其实是进了垃圾箱。5.3 多实例部署后验证码失效这是前面提过的经典问题。单机测试一切正常一上多实例就出现“发送成功但验证失败”。根因是验证码存在了某个实例的本地内存里。解法就是用共享存储。Redis 是最常见的选择也可以用数据库或者专门的缓存服务。核心原则是所有实例读写同一份数据。5.4 用户狂点导致收到多封邮件前端禁用按钮能挡住大部分但挡不住直接调接口的。后端的并发锁是最后一道防线。set nx ex保证同一时刻只有一个请求能真正执行发送逻辑其他请求直接返回“请求过于频繁”。实操心得并发锁的过期时间要和前端倒计时对齐都是 60 秒。如果锁设成 30 秒用户倒计时还没结束锁就过期了狂点又能发出去。5.5 验证码被暴力枚举6 位数字有 100 万种组合看起来很多但如果没有任何限制脚本每秒试几百次几个小时就能跑完。防护手段有两个一是错误次数限制同一个邮箱错 5 次就作废二是IP 级频率限制单个 IP 的验证请求也要限速。这两个限制叠加暴力枚举的成本会高到不划算。记住一个原则任何可以被反复尝试的接口都必须有限速。6. 一些让模块更稳的进阶做法6.1 异步发送别阻塞请求上面的代码是同步发送邮件的用户请求后要等邮件发完才返回。SMTP 发送有时候要几秒用户会感觉卡。更好的做法是把发送任务丢到队列里接口立刻返回“发送中”后台 worker 慢慢发。实现上可以用 Celery、RQ 这类任务队列也可以用简单的线程池。对于验证码这种量不大的场景线程池就够了。量大了再上专业队列。6.2 发送失败的重试与降级邮件发送偶尔失败是正常的网络抖动、对方服务器临时不可用都会导致失败。加一个简单的重试机制能显著提升成功率失败后隔几秒重试一次最多重试两次。如果还是失败返回明确的错误提示让用户稍后再试。重试要注意幂等别因为重试导致用户收到多封邮件。可以在重试前检查验证码是否还在在的话说明还没发成功可以重发。6.3 监控与告警上线后要盯着几个指标发送成功率、平均送达时间、验证成功率。发送成功率突然下降可能是 SMTP 配置出问题或者被限流了。验证成功率低可能是邮件进垃圾箱了。这些指标能帮你第一时间发现问题。我一般会在发送成功和失败的地方打点统计每分钟的成功率。低于某个阈值就告警。这个投入不大但能省很多排查时间。6.4 验证码的清理策略Redis 的 TTL 会自动清理过期的验证码不用手动删。但有个细节如果用户请求发送后一直不验证验证码会在 5 分钟后自动消失这是符合预期的。不需要额外的清理任务。唯一要注意的是频率限制的 key。如果用户发了一次就再也不来了那个计数 key 会在 1 小时后自动过期也不会堆积。所以整个方案的存储是自清理的不需要维护定时任务。7. 关于这套方案我踩过的几个坑第一个坑是授权码和登录密码搞混。第一次配置时我直接填了邮箱登录密码认证一直失败排查了半天才反应过来要用授权码。这个错误很低级但很常见配置时一定要确认。第二个坑是忘了配 SPF 记录。代码跑通了邮件也发出去了但用户反馈收不到。查了半天发现全进了垃圾箱。配好 SPF 和 DKIM 之后进箱率立刻上来了。邮件送达这件事代码只占一半域名配置占另一半。第三个坑是并发锁的过期时间设太短。一开始设了 30 秒结果用户倒计时还没结束锁就过期了狂点又能发出去。后来统一成 60 秒和前端对齐问题解决。第四个坑是发送失败没回滚计数。有次 SMTP 服务商临时故障用户点了发送邮件没发出去但计数被消耗了。用户重试几次后就被限制了一小时投诉说“明明没收到却说发太多次”。加上失败回滚之后就正常了。这些坑都不复杂但都是实际跑起来才会遇到的。写代码时多想想异常路径能省很多事后排查的功夫。8. 后续可以怎么扩展这套模块跑通之后扩展方向挺多的。比如把邮件模板抽出来做成可配置的不同场景用不同模板比如加上多语言支持海外用户收到英文邮件比如把发送渠道抽象成接口邮件、短信、站内信都能接业务代码不用改。再往深了做可以加行为风控。比如同一个 IP 短时间内注册大量账号自动提高验证门槛比如检测邮箱格式和域名拦截明显的垃圾邮箱。这些都属于锦上添花核心的发送和校验逻辑稳了其他都好加。我个人在实际操作中的体会是验证码模块看着简单但它是注册登录流程的第一道门稳定性直接影响转化率。宁可前期多花点时间把频率限制、异常处理、邮件送达这些细节做扎实也别等上线后用户投诉了再回头补。这套方案我用了挺久量级从每天几百到几万都没出过问题你可以放心参考。