HTML无法实现真正的双因素认证（2FA），因其属服务端逻辑；前端仅负责语义清晰、无障碍友好的备用入口展示，如脱敏联系方式、动态加载恢复选项、防刷校验及焦点可控的模态交互。
HTML里不能直接实现双因素认证（2FA）
双因素认证是服务端逻辑，HTML只是静态结构层。你看到的“备用码输入框”“短信重发按钮”，本质都是前端界面占位符，背后必须对接后端接口。强行在纯 HTML 里模拟 2FA 流程（比如用 localStorage 存备用码、用 prompt() 模拟验证码），不仅无效，还会误导用户以为已安全登录。
备用流程该用什么 HTML 元素呈现
重点不是“怎么加密”，而是“怎么让用户不卡住”。备用入口要显眼、语义清晰、无障碍友好：
- 备用码输入用
<input type="text" inputmode="text" autocomplete="off">，禁用自动填充避免泄露历史码 - 短信/邮箱切换用
<button type="button" data-method="sms">和<button type="button" data-method="email">，别用<a>标签——它不该跳转，而应触发 JS 请求验证码 - 错误提示统一用
<div role="alert">包裹，配合aria-live="polite"，让屏幕阅读器可感知
常见坑：把备用通道写死在 HTML 里
比如直接在页面里写：<p>备用邮箱：******@example.com</p>——这等于把恢复路径明文暴露给爬虫和中间人。真实场景中：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 所有备用联系方式必须动态加载（通过已认证的 session 请求
/api/auth/recovery-options） - 邮箱/手机号字段只显示脱敏格式（如
u***@g***.com），完整信息需二次验证后才展开 - “发送短信”按钮点击后，必须校验用户当前会话有效性（比如检查
X-CSRF-Token或短期 JWT），否则攻击者可批量刷短信
为什么不用 <dialog> 做 2FA 弹窗
<dialog> 语义合理，但兼容性差（Safari 直到 16.4 才支持，旧安卓 WebView 完全不认）。更实际的做法是：
立即学习“前端免费学习笔记（深入）”；
- 用
<div aria-modal="true">+ 手动管理焦点锁（focusin拦截） - 关闭按钮必须同时响应
Escape键和点击，且关闭后焦点回到触发按钮（否则键盘用户会迷失） - 弹窗内禁止嵌套表单提交——2FA 验证应走独立 API（如
POST /api/auth/verify-otp），而不是复用主登录表单
真正难的从来不是怎么画个输入框，而是确保每次点击、每次回车、每次网络中断后，状态都可预测、可回退、不残留敏感痕迹。
