前端实时提示与后端校验必须使用同一套规则，否则会导致用户看到“强密码 ✅”却提交失败；需通过 oninput 防抖（250ms）、paste 监听、正则初筛加 zxcvbn 终审、结构化反馈、精准提示文案及前后端配置同步来保障一致性。
前端实时提示和后端校验必须用同一套规则，否则用户看到“强密码 ✅”却提交失败——这不是体验问题，是策略错位。
oninput 防抖校验比 submit 拦截更重要
用户在密码框里敲字、粘贴、删改时，input 事件是唯一能覆盖所有输入方式的触发点。只靠 submit 事件拦截，等于把反馈延迟到最后一刻，用户得反复试错。
- 每次
input触发，先clearTimeout上一个定时器，再setTimeout延迟 250ms 执行校验，避免中文输入法卡顿 - 校验函数不操作 DOM，只返回结构化对象，例如
{ score: 2, missing: ['symbol', 'uppercase'] } - 别在
input里直接调用zxcvbn()——它内部加载词典，防抖后调用才合理 - 需额外监听
paste事件，iOS Safari 对粘贴后的input触发不稳定
正则分项检测 + zxcvbn 补漏不可少
纯正则（如 /(?=.*[A-Z]).../）能告诉你“缺什么”，但拦不住 Password123! 这类语义弱口令。必须分层：轻量正则快速筛，zxcvbn() 做终审。
- 先做基础过滤：
.trim()去首尾空格，长度直接返回 <code>{ score: 0, missing: ['length'] } - 再跑四次
test()：小写、大写、数字、符号（注意用/[^a-zA-Z0-9]/匹配含空格的合法符号） - 最后调
zxcvbn(password)，取feedback.warning和feedback.suggestions作提示文案，比如“太常见”“加个随机词” - 前后端若都用
zxcvbn，版本必须一致，否则评分逻辑偏差会导致前端标“强”、后端拒收
提示文案必须紧贴 input 下方且可操作
提示不能塞进 placeholder，也不能用 position: absolute 飘走——它得是稳定 DOM 节点，随表单一起流式布局。
- 结构上，在
<input type="password" id="pwd">后紧跟一个<div id="pwd-strength" class="pw-strength-hint"></div> - 用
display: none控制显隐，别用visibility: hidden——后者占位导致表单高度跳动 - 文案拒绝“弱/中/强”这种抽象词，改用具体动作：“请添加符号”“避免连续数字”“太常见，换词试试”
- 移动端要加
scrollIntoView({ block: 'nearest' })，防止虚拟键盘遮挡提示
前后端强度策略必须对齐，但角色不同
前端提示是体验层，后端验证是安全层。两者规则可以宽松度不同，但“禁止项”必须完全一致——比如后端禁用字典词，前端就得同步禁用；后端要求至少 1 个符号，前端提示里就不能漏掉这项检查。
- 把强度规则抽成配置对象，例如
{ minLength: 9, requireUppercase: true, bannedWords: ['password', '123456'] }，前后端共用 - 提交时仍要把原始密码值原样传给后端，前端不替后端做“裁剪”或“标准化”
- 后端返回的错误里，最好带字段级不满足项，如
{"error": "weak_password", "missing": ["symbol", "banned_word"]}，方便前端精准高亮 - 真正容易被忽略的是：前端显示“已达标”后，用户删减内容，提示状态不会自动回退——必须每次
input都重算，不能缓存结果
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
