设计用户注册、找回密码、更换登录邮箱等功能时Email Verification API 承担的不只是“发一封邮件”这样简单。它要把验证码生成、临时存储、邮件下发、用户回传校验、过期与重试控制、反滥用限流这六件事串成一条完整链路任何一个环节没有处理好都会直接表现为用户收不到邮件、验证码频繁失效或接口被批量刷取。在常见后端项目中真正需要邮箱验证的界面往往只是一个输入框和一封邮件模板但支撑它的 API 必须同时解决三个问题验证码不能被预测、验证码不能被反复使用、发送和校验接口不能被恶意刷量。很多团队把功能写完了才补安全策略最后只能靠加白名单硬撑本质上是因为一开始没有把“验证码生命周期”和“防滥用边界”设计清楚。这篇文章以 Spring Boot 3.x Redis SMTP 为例从零实现一个最小但结构完整的 Email Verification API。文章会覆盖验证码生成规则、Redis key 设计、邮件发送服务、发送与校验接口、本地联调方法、常见问题排查以及生产环境加固清单。掌握之后你可以在自己的注册、找回密码、绑定邮箱流程中直接落地也可以把同样的设计思路迁移到手机验证码接口上。1. 邮箱验证 API 到底在解决哪三个问题1.1 所有权验证证明这个邮箱可以被用户接收邮箱验证的第一个目标是证明“提交邮箱的人”能够访问“该邮箱的收件箱”。用户注册时如果只需要填写邮箱不验证归属任何人都可以把别人的邮箱填入表单从而在业务系统里创建出错误身份后续找回密码也会变成一条被滥用的通道。验证所有权的标准做法是服务端生成一个随机验证码写入临时存储再通过邮件发送给用户用户收到验证码后在页面回填API 比对用户输入与服务端保存的值。这一步在技术上并不复杂真正复杂的是确保验证码不会被中间人截获、不会在 Redis 里长期保留、不会因为错误次数过多而给暴力破解留下空间。这里需要明确一个边界邮箱验证不等于登录。验证通过只能说明“这个邮箱在某个时间点确实能被提交者接收”它通常用来完成注册、重置密码或更换邮箱流程中的某个步骤不能因此直接签发登录态。项目设计里应当把“验证通过”的标记与“会话创建”拆开。1.2 可达性验证把无效地址挡在业务数据之外很多业务系统在用户进入生产环境后会积累大量无法收到通知的邮箱地址。原因往往不是邮件服务商问题而是注册阶段没有做投递前验证用户填写的地址格式正确但根本不存在或者域名已经失效。邮箱格式校验只能检查字符串是否像邮箱地址例如是否包含 、后缀是否合法。它无法确认真实邮箱服务器是否接受这个地址。Email Verification API 要做的是通过真实发送邮件并等待用户回填验证码把“格式正确但不可达”的地址过滤掉。这也意味着发送邮件不能只把任务交给线程池后立即返回成功至少要记录发送结果、捕获异常并给出明确失败响应。1.3 人机验证与频率控制防止接口被批量滥用邮箱验证 API 天然是攻击面。攻击者可以用自动化脚本不停请求发送接口消耗邮件服务商的配额或者用同一批邮箱地址批量注册账号。更严重的场景是如果验证码没有错误次数限制攻击者可以对 6 位数字验证码进行穷举最多 100 万次尝试就能撞到有效值。所以邮箱验证 API 不能只面对正常用户设计。发送接口要限频校验接口要限制错误次数同一邮箱、同一 IP 都要有可配置的速率阈值。这些能力不是上线后的优化项而是 API 设计的一部分。下面的实现会把冷却时间和最大错误尝试次数放进 Redis key 的过期策略里保证单机运行和后续水平扩展都具备同样约束。2. 环境准备与项目结构先对齐再写代码2.1 技术选型Spring Boot Redis SMTP 的分工为了把注意力放在 Email Verification API 本身这里使用最常见、也最容易本地复现的技术栈Spring Boot 3.x 提供 Web 接口、配置绑定和邮件发送封装。Redis 存储验证码、错误次数和冷却标记并用过期时间自动清理。SMTP 作为邮件下发通道本地联调可以用 MailHog 模拟邮件接收。Redis 在这里承担的是“短生命周期数据存储”。验证码通常 5 分钟过期错误次数和验证码一起失效发送冷却标记 60 秒后自动解除。用 MySQL 也能完成同样功能但需要自己编写定时清理任务且每次校验都要读写数据库不如 Redis 的 TTL 机制自然。如果原始项目没有引入 Redis需要提前确认已部署可用的 Redis 环境否则后续代码无法启动。生产环境建议使用云数据库 Redis 或独立 Redis 集群并开启密码认证。2.2 Java 与 Maven 依赖示例以 Spring Boot 3.2 为基础要求 JDK 17 及以上。如果项目实际使用 Spring Boot 2.x 或 Java 8下面的代码中部分 API 需要调整特别是Duration和 Redis 脚本相关的写法落地前先确认版本。pom.xml 核心依赖如下parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version3.2.4/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-mail/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-test/artifactId scopetest/scope /dependency /dependencies引入spring-boot-starter-mail后Spring Boot 会自动创建JavaMailSender实例。引入spring-boot-starter-data-redis后默认使用 Lettuce 客户端StringRedisTemplate可以直接注入适合这里验证码这种字符串类型数据。2.3 application.yml 配置项详解server: port: 8080 spring: data: redis: host: 127.0.0.1 port: 6379 password: database: 0 timeout: 3s mail: host: smtp.example.com port: 465 username: noreplyexample.com password: change-me protocol: smtps properties: mail: smtp: auth: true connectiontimeout: 5000 timeout: 5000 writetimeout: 5000 app: email: verify: code-length: 6 code-ttl-seconds: 300 cooldown-seconds: 60 max-attempts: 5 send-from: noreplyexample.com subject: 请验证您的邮箱 template: 您的邮箱验证码是 %s%d 分钟内有效。请勿泄露给他人。 ip-send-hour-limit: 10 ip-send-day-limit: 50这里解释几个容易踩坑的参数spring.mail.protocolsmtps端口 465 时是 SSL 加密如果使用 587 端口通常改成smtp并配置 STARTTLS。写错协议会抛出连接超时或认证错误。spring.mail.password是 SMTP 授权码很多邮件服务商不允许使用登录密码需要在邮箱后台单独生成授权码。app.email.verify.code-ttl-seconds控制验证码有效期cooldown-seconds控制用户两次发送请求的最短间隔max-attempts控制最多可输入错误次数。2.4 项目目录与关键类清单src/main/java/com/example/emailverify/ ├── EmailVerifyApplication.java ├── config/ │ └── EmailVerifyProperties.java ├── controller/ │ ├── EmailVerificationController.java │ └── GlobalExceptionHandler.java ├── dto/ │ ├── ApiResponse.java │ ├── SendVerificationRequest.java │ └── VerifyRequest.java ├── enums/ │ └── ErrorCode.java ├── exception/ │ └── BusinessException.java ├── service/ │ ├── EmailVerificationService.java │ └── MailSenderService.java └── util/ └── EmailValidator.javaEmailVerifyProperties用ConfigurationProperties绑定app.email.verify配置避免在业务类里散落魔法值。2.5 学习环境与生产环境差异维度学习环境生产环境Redis本地默认配置无密码启用密码、TLS、持久化或托管服务邮件服务MailHog 本地模拟收信专业 SMTP 服务商配置 SPF/DKIM/DMARC密钥管理yml 明文环境变量、配置中心或密钥管理平台日志控制台输出结构化日志采集敏感字段脱敏安全策略基础冷却和错误限制增加行为验证、IP 限流、异常告警部署方式IDE 直接运行Docker、Kubernetes多副本部署先按学习环境跑通再逐项补齐生产差异这是比较合理的推进顺序。3. 验证码生成与 Redis 存储核心安全边界3.1 验证码的生成规则与安全随机数验证码长度在配置中定义为 6 位数字。生成代码最忌讳使用Math.random()因为它不是密码学安全随机数。这里使用java.security.SecureRandom。private final SecureRandom secureRandom new SecureRandom(); public String generateCode() { int min (int) Math.pow(10, properties.getCodeLength() - 1); int max (int) Math.pow(10, properties.getCodeLength()); int code min secureRandom.nextInt(max - min); return String.valueOf(code); }SecureRandom生成的随机序列在统计学上更难预测但 6 位数字意味着最多 90 万个可能值暴力穷举仍然可行。因此比长度更重要的是错误次数限制和过期时间两者一起才能把攻击窗口压缩到可控范围。3.2 Redis key 设计与过期时间验证码相关数据分成三个 keykey内容过期时间说明verify:email:code:{email}验证码字符串300 秒核心验证数据verify:email:attempts:{email}错误次数与验证码同生命周期超过次数后清空verify:email:cooldown:{email}发送时间戳60 秒防止频繁发送email 作为 key 的一部分时要注意不同环境隔离。比如测试环境和生产环境共用 Redis可以增加前缀prod:或test:。如果业务里有注册、找回密码、改绑邮箱等多个场景建议再增加场景维度例如verify:register:email:code:{email}和verify:reset:email:code:{email}避免不同类型验证码互相覆盖。3.3 发送冷却与发送频控发送接口必须做频率控制。最简单的原子操作是setIfAbsentString cooldownKey COOLDOWN_KEY_PREFIX email; Boolean acquired redisTemplate.opsForValue().setIfAbsent( cooldownKey, String.valueOf(System.currentTimeMillis()), Duration.ofSeconds(properties.getCooldownSeconds()) ); if (Boolean.FALSE.equals(acquired)) { throw new BusinessException(ErrorCode.SEND_TOO_FREQUENT); }setIfAbsent在 key 不存在时设置成功并返回 true存在时直接返回 false。这个命令是原子的多个请求同时到达时只有一个能通过。如果不使用这种原子操作先查存在再写入并发下会同时放行多个请求。3.4 保存验证记录的服务实现EmailVerificationService的核心逻辑是先占冷却标记再生成并保存验证码最后发送邮件。邮件发送失败时要删除已经保存的验证码和冷却标记否则用户会陷入“一直被冷却、永远收不到邮件”的状态。Service public class EmailVerificationService { private static final Logger log LoggerFactory.getLogger(EmailVerificationService.class); private static final String CODE_KEY_PREFIX verify:email:code:; private static final String ATTEMPTS_KEY_PREFIX verify:email:attempts:; private static final String COOLDOWN_KEY_PREFIX verify:email:cooldown:; private static final String IP_SEND_KEY_PREFIX verify:ip:send:; private final StringRedisTemplate redisTemplate; private final MailSenderService mailSenderService; private final EmailVerifyProperties properties; private final SecureRandom secureRandom new SecureRandom(); public EmailVerificationService(StringRedisTemplate redisTemplate, MailSenderService mailSenderService, EmailVerifyProperties properties) { this.redisTemplate redisTemplate; this.mailSenderService mailSenderService; this.properties properties; } public void sendVerification(String email, String ip) { if (!EmailValidator.isValid(email)) { throw new BusinessException(ErrorCode.INVALID_EMAIL); } checkIpLimit(ip); String cooldownKey COOLDOWN_KEY_PREFIX email; Boolean acquired redisTemplate.opsForValue().setIfAbsent( cooldownKey, String.valueOf(System.currentTimeMillis()), Duration.ofSeconds(properties.getCooldownSeconds()) ); if (Boolean.FALSE.equals(acquired)) { throw new BusinessException(ErrorCode.SEND_TOO_FREQUENT); } String code generateCode(); String codeKey CODE_KEY_PREFIX email; redisTemplate.opsForValue().set( codeKey, code, Duration.ofSeconds(properties.getCodeTtlSeconds()) ); try { mailSenderService.sendVerificationEmail(email, code, properties.getCodeTtlSeconds() / 60); } catch (Exception e) { redisTemplate.delete(codeKey); redisTemplate.delete(cooldownKey); log.warn(send verification email failed, email{}, email, e); throw new BusinessException(ErrorCode.MAIL_SEND_FAILED); } log.info(verification email sent, email{}, ip{}, email, ip); } }这里有一个工程取舍先保存验证码再发送邮件优势是防止邮件发送成功后 Redis 写入失败导致无法校验缺点是如果邮件发送失败需要主动清理数据。上面代码已经处理了清理逻辑。生产环境如果能引入消息队列可以进一步把“生成验证码保存”和“发送邮件”解耦但最小实现保持同步调用更直观。4. 邮件发送服务与对外 Rest API4.1 使用 JavaMailSender 发送邮件邮件发送独立成MailSenderService这样EmailVerificationService不直接依赖JavaMailSender后续要接入第三方邮件服务商也只需要替换这个类。Service public class MailSenderService { private final JavaMailSender mailSender; private final EmailVerifyProperties properties; public MailSenderService(JavaMailSender mailSender, EmailVerifyProperties properties) { this.mailSender mailSender; this.properties properties; } public void sendVerificationEmail(String to, String code, int ttlMinutes) throws MessagingException { MimeMessage message mailSender.createMimeMessage(); MimeMessageHelper helper new MimeMessageHelper(message, true, UTF-8); helper.setFrom(properties.getSendFrom()); helper.setTo(to); helper.setSubject(properties.getSubject()); String content String.format(properties.getTemplate(), code, ttlMinutes); helper.setText(content, false); mailSender.send(message); } }helper.setText(content, false)表示按纯文本发送。如果邮件模板需要展示品牌 logo可以把模板写成 HTML 并传 true。纯文本方式在邮件安全性上更保守不会因为 HTML 内容被打开而加载远程图片。邮件发送是 IO 操作比较耗时。当前实现是同步发送当 SMTP 服务响应慢时用户请求会一直等待。生产环境建议在发送接口里使用线程池或消息队列异步化并记录发送任务的执行结果。本文最小实现先保留同步语义便于排查问题。4.2 配置属性类Component ConfigurationProperties(prefix app.email.verify) public class EmailVerifyProperties { private int codeLength 6; private long codeTtlSeconds 300; private long cooldownSeconds 60; private int maxAttempts 5; private String sendFrom; private String subject; private String template; private int ipSendHourLimit 10; private int ipSendDayLimit 50; // getter/setter 省略 }如果项目启用了配置中心的动态刷新属性类可以在此基础上增加刷新机制。当前代码把默认值写在属性类里yml 中未配置时也能启动降低了本地联调门槛。4.3 发送验证码接口RestController RequestMapping(/api/v1/email/verification) public class EmailVerificationController { private final EmailVerificationService emailVerificationService; public EmailVerificationController(EmailVerificationService emailVerificationService) { this.emailVerificationService emailVerificationService; } PostMapping(/send) public ApiResponseVoid sendCode(RequestBody Valid SendVerificationRequest request, RequestHeader(value X-Forwarded-For, required false) String xff, HttpServletRequest httpRequest) { String ip resolveClientIp(xff, httpRequest); emailVerificationService.sendVerification(request.getEmail(), ip); return ApiResponse.success(); } PostMapping(/check) public ApiResponseVoid checkCode(RequestBody Valid VerifyRequest request) { emailVerificationService.verifyCode(request.getEmail(), request.getCode()); return ApiResponse.success(); } private String resolveClientIp(String xff, HttpServletRequest httpRequest) { if (xff ! null !xff.isBlank()) { return xff.split(,)[0].trim(); } return httpRequest.getRemoteAddr(); } }请求 DTO 加上校验注解可以让非法参数在进入业务逻辑前被拦截。public class SendVerificationRequest { NotBlank Email private String email; // getter/setter } public class VerifyRequest { NotBlank Email private String email; NotBlank Pattern(regexp ^\\d{6}$, message 验证码格式不正确) private String code; // getter/setter }4.4 校验验证码使用 Lua 脚本保证原子性校验逻辑有个并发隐患同一个正确验证码如果两个请求同时带着相同 code 发送过来先读取、再删除的普通做法可能让两个请求都读到同一个 code导致同一个验证码被使用两次。要避免这个问题校验和删除必须在 Redis 中以原子操作完成。这里使用 Lua 脚本验证码正确则立即删除验证码和错误次数验证码错误则递增错误次数超过阈值后删除验证码。整个流程在 Redis 内部执行不会出现并发竞态。private static final DefaultRedisScriptLong VERIFY_SCRIPT new DefaultRedisScript( local code redis.call(GET, KEYS[1])\n if not code then return -1 end\n local inputCode ARGV[2]\n if code inputCode then\n redis.call(DEL, KEYS[1], KEYS[2])\n return 1\n end\n local current tonumber(redis.call(GET, KEYS[2]) or 0) 1\n redis.call(SET, KEYS[2], current)\n local ttl redis.call(TTL, KEYS[1])\n if ttl 0 then redis.call(EXPIRE, KEYS[2], ttl) end\n local maxAttempts tonumber(ARGV[1])\n if current maxAttempts then\n redis.call(DEL, KEYS[1], KEYS[2])\n return -2\n end\n return 0, Long.class );对应的 Java 调用public void verifyCode(String email, String code) { Long result redisTemplate.execute( VERIFY_SCRIPT, List.of(CODE_KEY_PREFIX email, ATTEMPTS_KEY_PREFIX email), String.valueOf(properties.getMaxAttempts()), code ); switch (result.intValue()) { case 1 - log.info(email verified, email{}, email); case -1 - throw new BusinessException(ErrorCode.CODE_EXPIRED); case -2 - throw new BusinessException(ErrorCode.TOO_MANY_ATTEMPTS); default - throw new BusinessException(ErrorCode.CODE_INCORRECT); } }Lua 脚本返回值的语义需要和错误码表保持一致返回值含义对应提示1验证码正确且已消费校验成功-1验证码不存在或已过期请重新发送0验证码错误验证码不正确请检查后重试-2错误次数超过上限已锁定请重新发送验证码4.5 全局异常与统一响应所有业务异常统一使用BusinessException由RestControllerAdvice捕获避免业务代码里到处写try catch。public class ApiResponseT { private int code; private String message; private T data; public static T ApiResponseT success() { return new ApiResponse(0, success, null); } public static T ApiResponseT error(int code, String message) { return new ApiResponse(code, message, null); } }错误码定义错误码说明0成功4001参数错误4002发送过于频繁4003验证码不存在或已过期4004验证码错误4005错误次数超限4006邮件发送失败4007邮箱格式不合法5. 本地启动与完整链路自测5.1 启动 Redis 和本地邮件接收器先启动 Redisredis-server验证连通redis-cli ping本地开发环境如果不想使用真实 SMTP 服务可以运行 MailHog 来模拟邮件接收docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog此时 application.yml 的 mail 配置可以调整为spring: mail: host: 127.0.0.1 port: 1025 username: password: protocol: smtp properties: mail: smtp: auth: falseMailHog 的 Web 管理界面默认在http://localhost:8025收到的邮件会直接显示在页面上。真实 SMTP 不会对外发信适合学习联调。5.2 用 curl 验证发送接口发送接口的请求和响应如下curl -X POST http://localhost:8080/api/v1/email/verification/send \ -H Content-Type: application/json \ -d {email:testexample.com}预期响应{ code: 0, message: success, data: null }然后查看 Redis 中的验证码redis-cli get verify:email:code:testexample.com正常会输出 6 位数字。这个命令只用于本地调试生产环境禁止把这类命令直接开放给开发者使用。5.3 用 curl 验证校验接口从 Redis 里拿到 code 后调用校验接口curl -X POST http://localhost:8080/api/v1/email/verification/check \ -H Content-Type: application/json \ -d {email:testexample.com,code:123456}校验成功响应{ code: 0, message: success, data: null }再次调用相同验证码会返回验证码不存在或已过期因为校验成功后 key 已经被删除。这个行为是设计预期不是缺陷。5.4 通过日志确认每个环节如果发送接口返回成功但页面没有收到邮件先看后端日志。实现里已经保留了关键日志verification email sent, email..., ip...表示邮件发送流程结束。email verified, email...表示验证码校验成功。send verification email failed, email...表示发送异常。生产项目建议在发送日志中不要打印验证码本身避免日志系统被读取后泄露验证数据。可以考虑打印验证码哈希或后四位。5.5 自动化测试的补强单元测试重点覆盖两个服务验证码生成结果必须是纯数字且长度正确。校验逻辑在验证码错误、过期、超限三种情况下抛出对应错误。邮件发送失败时Redis 中的验证码和冷却 key 被清理。Spring Boot 测试中可以使用MockBean或MockitoBean模拟 Redis 和 JavaMailSender。生产项目还可以用 Testcontainers 启动真实 Redis进一步贴近环境。6. 按链路倒推的常见问题排查6.1 验证码邮件发不出去现象接口返回邮件发送失败日志出现AuthenticationFailedException或超时。排查顺序检查 SMTP host、port、protocol 是否匹配。465 端口通常是 SSL587 端口通常是 STARTTLS。检查 username 和 password 是否为 SMTP 授权码部分邮箱服务商需要使用独立授权码。检查网络是否可以访问 SMTP 服务。本地 MailHog 场景下确认容器是否启动端口是否映射正确。问题现象常见原因处理建议认证失败授权码错误重新生成 SMTP 授权码连接超时端口、协议不匹配465 使用 smtps587 配置 STARTTLS发送成功但收件箱为空投递到垃圾箱或域名未配置 SPF检查垃圾箱和邮件域名 DNS 配置6.2 发送成功但用户收不到邮件用户侧收不到邮件有两种典型情况邮件被投递到垃圾箱或者邮件服务商拒收。拒收常见原因是发信域名没有配置 SPF、DKIM、DMARC 记录接收方服务器会把邮件判定为垃圾邮件。本地联调阶段无法验证真实投递质量必须把生产域名配置交给运维或邮件服务商处理。建议在测试环境使用真实业务邮箱完整走一遍注册流程。6.3 验证码总是校验失败现象用户确认输入的验证码和邮件里的一致但接口返回错误码 4004 或 4003。排查顺序在 Redis 里查看verify:email:code:{email}是否存在。确认业务代码读取的是不是同一个 Redis database。配置里spring.data.redis.database不一致会导致逻辑隔离。确认邮件模板里没有在验证码前后拼上多余空格或 HTML 标签。确认是否有多个环境共用同一 Redis 前缀导致 key 被覆盖。6.4 Redis 中验证码提前丢失如果本地 Redis 进程经常重启默认配置下数据会丢失。生产环境需要开启 RDB 或 AOF 持久化并配置主从或集群。但也要理解验证码是短生命周期数据丢失后用户重新发送即可不应该把 Redis 当成持久化业务库。如果选择把验证码写入数据库表要额外处理过期清理任务否则表会越涨越大。这种方案不是本文推荐方向。6.5 并发重复校验导致同一个验证码被使用两次普通代码“先查再删”在高并发下会出现竞态。两个请求同时查询都得到同一个 code然后都执行校验成功逻辑。解决方式就是用 Lua 脚本把“比对验证码、删除验证码、更新错误次数”放在一个 Redis 原子操作里。这也是本文校验接口没有使用简单get - compare - delete的原因。7. 生产环境加固与此 API 的最佳实践7.1 接口防滥用不能只有冷却时间冷却时间只能控制同一邮箱的发送频率无法防止攻击者用几千个不同邮箱地址发垃圾邮件。生产环境至少叠加两层限制IP 维度限流记录每个 IP 每小时和每天的发送次数。行为验证在发送接口前增加滑块、图形验证码或行为风控参数。IP 限流的 Redis key 可以设计为verify:ip:send:{date}:{ip}计数字段用INCR和EXPIRE。发送接口先检查 IP 配额再检查邮箱冷却顺序不能颠倒否则攻击者可以用小号邮箱绕过冷却限制耗尽 IP 配额。7.2 验证码安全实践验证码本身是弱凭证所有防御目标都是降低被暴力枚举的概率使用SecureRandom生成不要使用Math.random()。验证码长度、有效期、最大错误次数必须可配置。校验成功后立即删除验证码。验证码不进入日志不在 URL 查询参数中传递。验证码不能作为会话凭证验证通过后的操作仍要校验用户身份。如果需要更高安全性可以把纯数字 6 位扩展为字母数字混合 8 位。但这会降低用户体验正常业务里 6 位数字配合错误次数限制已经足够常见。7.3 邮件发送可靠性与可观测性邮件系统属于外部依赖失败时不能只有日志还需要监控。生产环境建议统计以下指标发送请求量、成功量、失败量。SMTP 响应耗时。邮件被拒收、退信的数量。验证码校验成功率。用户单次获取验证码到校验通过的耗时。如果发送量较大用消息队列异步发送消费者记录每封邮件的状态。不要在线程池里无限制提交任务需要明确队列容量和拒绝策略。7.4 发布前检查清单上线前可以把下面这份清单放到运维或发布流程里逐项确认邮件域名是否配置 SPF、DKIM、DMARC。SMTP 账号是否为专用发信账号密码是否通过环境变量或配置中心注入。Redis 是否开启密码认证、TLS 和持久化。发送接口是否配置邮箱级和 IP 级限流。校验接口是否配置最大错误尝试次数。日志是否对邮箱、验证码、请求体做脱敏。错误码文档是否同步给前端团队。是否对发送和校验接口做基础压测确认 SMTP 和 Redis 不会成为瓶颈。是否准备邮件发送失败时的用户提示文案和重试链路。拿到这些项目后建议先按第 5 节的流程用 Redis MailHog 在本地跑通最小链路再替换为真实 SMTP最后逐项补充生产加固。验证码服务最容易踩的坑不在单一代码逻辑而在邮件通道、Redis 生命周期和限流策略之间的配合。把它们当成一个整体设计接口质量会稳定很多。扩展方向上你可以继续为不同业务场景拆分 verification key 前缀、把邮件发送改造成异步任务、加入短信验证通道并在同一个验证服务里抽象出统一的验证码存储与校验策略。