HTML本身不处理“忘记密码”逻辑，仅负责呈现表单和收集输入；完整流程需后端支撑，包括校验用户、生成签名token、发邮件、验证链接、更新密码及登出所有会话。
直接说结论：HTML 本身不处理“忘记密码”逻辑，它只负责呈现表单和用户输入界面；真正的密码重置必须由后端服务支撑，前端 HTML + JavaScript 只能完成第一步——提交邮箱或用户名。
为什么纯 HTML 无法实现密码重置
HTML 是标记语言，没有执行能力，不能发邮件、不能查数据库、不能生成 token、也不能修改密码。所谓“忘记密码流程”，本质是前后端协作的完整链路：
-
HTML提供<form>收集用户输入（如邮箱） -
JavaScript拦截提交、校验格式、调用fetch()发请求 - 后端接收请求，查用户是否存在，生成一次性
reset_token，存入数据库并发送带链接的邮件 - 用户点击邮件里的链接（形如
/reset?token=abc123），进入重置页 —— 这个页面仍由 HTML 构建，但需后端渲染或 JS 动态加载 - 提交新密码时，
POST到后端接口，后端校验token有效性、更新密码、作废该 token
input[type="email"] 是起点，但别只靠它校验
很多人以为加个 type="email" 就算完成了邮箱验证，其实浏览器只做基础格式检查（比如是否含 @），无法确认邮箱真实存在或属于当前用户。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 前端用
input[type="email"]+required属性提供基础体验，但必须配合后端校验 - 提交前用 JavaScript 简单检查是否为空、是否含 @ 和 .（避免明显错误）
- 禁用提交按钮并显示 loading，防止重复点击导致多次发邮件请求
- 后端收到邮箱后，统一返回成功提示（不要区分“用户不存在”和“已发送”，防枚举攻击）
重置页 URL 中的 token 必须由后端生成并签名
别用前端 JS 生成 token（比如 Math.random().toString(36)），那毫无安全性可言。用户可随意构造 URL 尝试重置他人密码。
关键点：
-
token应由后端用加密方式生成（如 Node.js 的crypto.randomBytes(32).toString('hex')，或 Python 的secrets.token_urlsafe(32)） - 该
token必须与用户 ID、过期时间（如 1 小时）、使用状态绑定，并存入数据库 - 重置页面加载时，前端通过 URL 参数读取
token（用new URLSearchParams(window.location.search).get('token')），但仅用于提交；真正校验必须由后端完成 - 如果
token无效或已用过，后端应返回明确错误（如400 Bad Request或410 Gone），前端展示友好提示
密码输入框要避开常见安全陷阱
重置页通常有两个密码字段：new_password 和 confirm_password。看似简单，但容易出问题：
- 不要用
type="password"同时套两个字段就完事 —— 必须用 JavaScript 对比值是否完全一致（注意空格、Unicode 等） - 禁止前端存储明文密码或
token到localStorage或cookie（尤其token） - 提交时用
POST（不是GET），且请求头设置Content-Type: application/json，传参如：{ "token": "abc123", "new_password": "xxx" } - 后端接收到后，必须先查库确认
token未过期、未使用，再哈希新密码（如用bcrypt），最后更新并清空 token
最常被忽略的一点：重置成功后，必须强制退出当前所有登录态（包括其他设备），并要求用户用新密码重新登录 —— 这步几乎全靠后端清理 session 或 token 黑名单实现，前端只负责跳转和清空本地 cookie/localStorage。
