邮件与电话验证的 7 条规则：投递风险与账号连续性

页面在凌晨 02:13 崩了。学生无法登录，支持在睡觉，仪表盘显示登录端点健康。缺失的信号出现得更早：验证码被反复请求、从未被接受。 这是投递与恢复问题，不只是两个输入框之间的选择。

短答案：邮件与电话验证保护不同的安全边界，所以要按身份稳定性、滥用暴露面、以及投递失败时你能运营的恢复路径来选。

作者在生产里被 paged 过漏掉任务和重复投递。同样的运营气味在这里出现：系统返回 200 时用户体验已经坏了。把验证码请求当成带截止时间、重试预算和审计轨迹的 job 对待。

教育应用该先验证什么

先给资产命名：课堂产品里，账号可能持有成绩、监护人联系人或教师名册。邮箱通常在学年内稳定，但学校邮箱在转学期间可能被禁用；电话能快速找到人，但号码会被回收、共享设备很常见。 两个渠道都不能永远证明"这个人就是合法主人"。

Google/GitHub 社交登录只是增加一个身份提供方，不是万能恢复答案——学生可能有 Google 账号但不一定有绑定的邮箱/电话。

7 条规则要点（按原文提炼）

• 验证渠道按身份稳定性与滥用暴露面选，不按"哪个输入框顺手"选；
• 验证码请求 = 有截止时间的 job：重试预算 + 审计轨迹，别只看 HTTP 200；
• 社交登录是额外提供方，不是恢复通道的银弹；
• 投递失败要有可运营的恢复路径（换渠道、人工兜底）；
• 号码回收与共享设备是电话验证的固有风险，按场景接受或补偿；
• 邮箱可用性（如学校邮箱转学禁用）会变，验证状态要有重验证机制；
• 账号连续性靠"多渠道 + 过期重验证"，不靠单点信任。

实践建议

• 把验证投递当作业系统设计：deadline、重试、审计，健康检查不等于用户体验健康；
• 教育类产品警惕"号码共享/邮箱转学禁用"场景，预留重验证与人工恢复路径；
• 安全边界不同（邮箱=所有权稳定、电话=即时可达），用风险策略而不是习惯选渠道。

来源：7 Rules for Email and Phone Verification: Delivery Risk and Account Continuity - DEV Community