密码修改表单必须包含old_password、new_password、confirm_password三个密码字段，缺一不可；需校验新旧密码匹配、新密码强度及两次输入一致，并禁用重复提交、成功后清空表单并跳转登录页。
密码修改表单必须包含哪些字段
用户能成功改密的前提是：后端能明确区分“谁在改”“旧密码对不对”“新密码合不合规则”。所以前端表单至少得有三个 <input type="password"> 字段：old_password、new_password、confirm_password，缺一不可。漏掉 old_password 就等于允许无验证重置，属于高危设计；只用一个新密码框而跳过二次确认，用户手滑输错就直接锁死自己。
常见错误现象：400 Bad Request 或后端返回 "old password mismatch"，往往是因为前端没传 old_password 字段，或者字段名和后端约定的不一致（比如后端要的是 current_password）。
实操建议：
- 字段
name属性严格对齐接口文档，别凭感觉写pwd或pass - 给每个密码框加
required属性，防止空提交 -
new_password和confirm_password需前端实时校验是否一致（用input事件监听，不是只靠submit）
怎么防止用户重复提交导致密码被覆盖两次
点击“提交”后页面没反应，用户习惯性连点两下——这是密码修改场景里最典型的并发问题。后端若没做幂等控制，可能把同一次修改执行两遍，或更糟：第二次请求因旧密码已失效而失败，让用户误以为改密没成功。
实操建议：
- 表单提交瞬间禁用提交按钮：
button.disabled = true，并把文字临时改成“修改中…” - 用
fetch或XMLHttpRequest发请求时，在then或finally里恢复按钮状态，别只在catch里恢复 - 避免用
form.submit()触发原生跳转，改用 JS 控制提交流程，便于统一处理 loading 和错误
前端密码强度校验该做到什么程度
纯前端校验只是用户体验优化，不能替代后端验证。但做得太松（比如只要长度>6），用户输完点提交才被告知“需含数字和大写字母”，体验断裂；做得太死（比如强制特殊字符+长度≥12），反而推高弱口令风险（用户会写在便签上）。
实操建议：
- 最低要求：检查
new_password和confirm_password是否相等，且长度 ≥8 - 推荐增强：用正则粗筛常见弱口令，例如 /^(?=.*[a-z])(?=.*[A-Z])(?=.*\d).{8,}$/，但别拦截“Passw0rd2024”这种看似合规实则撞库高频的组合
- 不要在前端明文提示“你用了常见密码”，这等于帮攻击者枚举字典；只说“密码安全性不足，请尝试其他组合”
为什么改密成功后不能直接 window.location.reload()
刷新页面会重新加载原始表单，所有输入清空，用户看不到“修改成功”反馈，还可能因缓存导致旧 session 仍有效。更危险的是：如果用户从密码找回页跳转来，刷新后回到空白登录页，路径完全断开。
实操建议：
- 成功响应后，清空所有密码字段（
input.value = ''），并显示绿色提示文案（如“密码修改成功，请重新登录”） - 3 秒后跳转到登录页：
setTimeout(() => window.location.href = '/login', 3000) - 如果系统支持 token 自动续期，跳转前记得清除本地
localStorage中的旧 token（键名如auth_token），否则新密码生效了但旧 token 还能继续调接口
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
