邮箱验证流程核心是“发送验证码→用户提交验证→后端比对并激活账户”，需用独立email_verification表管理临时凭证，含id、user_id、email、code、expires_at、used、created_at字段，全程事务保障一致性，并优化前端交互与安全提示。
邮箱验证流程的核心是“发送验证码 → 用户提交验证 → 后端比对并激活账户”，在 MySQL 项目中需兼顾安全性、时效性和用户体验。关键不是只存邮箱，而是用独立验证表管理临时凭证，避免污染主用户表。
设计专用验证表（不与用户表耦合）
新建一张 email_verification 表，字段建议包含：
- id：主键（BIGINT 或 UUID）
- user_id：关联用户表的外键（可为空，注册时未知用户ID则留空）
- email：待验证邮箱（VARCHAR(255)，加索引）
- code：6位数字或随机字符串（VARCHAR(16)，加索引）
- expires_at：过期时间（DATETIME，如 NOW() + INTERVAL 30 MINUTE）
- used：是否已使用（TINYINT(1)，默认 0）
- created_at：创建时间（DATETIME，默认 CURRENT_TIMESTAMP）
这样设计便于单独清理过期记录（DELETE FROM email_verification WHERE expires_at ），也支持重发、多设备验证等扩展场景。
生成与存储验证码的关键细节
验证码不能是简单递增或时间戳，需防预测和暴力尝试：
- 用 PHP 的 random_int(100000, 999999) 或 Node.js 的 crypto.randomInt(100000, 1000000) 生成 6 位纯数字；或用 bin2hex(random_bytes(8)) 生成短随机串
- 写入数据库前，对 code 字段做单向哈希（如 SHA-256 + 盐）更安全，但需同步更新验证逻辑——推荐初期先明文存（加索引+短有效期），上线后再升级为哈希存储
- 插入前检查同邮箱近期（如 1 分钟内）是否已有未过期未使用的记录，有则拒绝新发，防止刷邮件
验证接口的原子性与状态控制
用户提交邮箱+验证码后，后端必须一次性完成查询、校验、标记、激活四步，且用事务保证不出现中间态：
- WHERE 条件必须同时满足：email = ? AND code = ? AND expires_at > NOW() AND used = 0
- UPDATE 语句直接将 used = 1，并返回影响行数 —— 若为 0，说明验证码错误/已用/过期
- 只有 UPDATE 成功（影响行数=1），才执行激活用户操作（如更新 users 表中 is_email_verified = 1）
- 整个过程包裹在 MySQL 事务中，避免并发重复验证导致异常状态
前端与体验优化要点
技术实现之外，几个易忽略但影响转化率的点：
- 发送邮件后，前端禁用“发送验证码”按钮 60 秒，并显示倒计时，防止用户狂点
- 验证码输入框自动聚焦，支持粘贴（监听 paste 事件并截断空格/换行）
- 若验证失败，不提示“验证码错误”或“邮箱错误”，统一返回“验证码无效或已过期”，防止枚举攻击
- 邮箱验证成功后，跳转页应明确告知“邮箱已验证”，并引导下一步（如设置密码、完善资料）
