应优先用防抖的 oninput 实现实时反馈，配合 onblur 作为校验底线；正则需拆解为多步 test() 并兼容 unicode，前后端共用强度规则，提示需无障碍与国际化支持。
密码强度校验该用 oninput 还是 onblur
实时反馈体验好，但别在 oninput 里直接调用复杂正则或多次 DOM 查询——卡顿会很明显。真正该做的是：输入时只做轻量级触发（比如标记“已开始输入”），等用户停顿 300ms 后再执行完整校验；而 onblur 是底线，提交前必须走一遍，防止绕过前端校验。
常见错误现象：oninput 中每敲一个键都跑一遍含 Unicode、大小写、数字、特殊字符的四重正则，导致中文输入法下拼音候选框卡住；或者把校验逻辑写死在事件监听里，导致多个密码字段互相干扰。
- 用
setTimeout+clearTimeout做防抖，不是节流 - 校验函数本身要纯（不读写 DOM），结果由外部统一更新 UI
- 移动端注意
oninput在 Safari 上对粘贴行为支持不稳定，得补监听paste事件
正则写法别照抄网上“强密码8位以上”模板
那种 ^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[!@#$%^&*])[\s\S]{8,}$ 看似全面，实际会让用户输 Password123! 就通过，但输 你好abc123! 却失败——因为没考虑 Unicode 字母。更糟的是，它默认禁掉空格，可很多安全规范明确允许中间带空格的口令（比如助记短语）。
真正可用的判断逻辑得拆开：先测长度（建议 ≥ 9），再分别计数小写字母、大写字母、数字、Unicode 字母（\p{L}）、标点（\p{P}），最后加权打分。浏览器支持方面，\p{L} 需要 u 标志，老版 iOS Safari 不认，得降级用 [a-zA-Z\u4e00-\u9fa5] 之类。
立即学习“前端免费学习笔记（深入）”；
- 别用单个正则包打天下，拆成多个
test()更可控 - 长度检查放最前，快速失败
- 对
password字段值做.trim()，避免用户输一堆空格蒙混过关
后端必须重新校验，前端只是体验层
所有前端密码强度提示，包括颜色变化、进度条、文字说明，都只是降低用户挫败感的手段。只要没发请求到服务端，就等于没校验。常见错误是前端显示“强度足够”，但后端用另一套规则（比如禁止连续数字、要求必须含两个特殊字符），结果接口返回 {"error": "weak_password"}，用户完全不知道哪里弱。
解决方案很简单：前后端共用同一套强度定义（比如 JSON Schema 或 OpenAPI 的 pattern + minLength），或后端提供 /api/password/strength 接口供前端调用（注意 CORS 和频率限制）。别让前端猜后端想拦什么。
- 提交表单时，即使前端已标绿，也要把原始密码值原样传给后端
- 后端返回的错误信息里，最好带具体不满足项（如
"missing_uppercase"），方便前端精准高亮 - 别在前端存任何密码规则文案，它属于后端配置项
无障碍和国际化容易被忽略的细节
用 aria-live="polite" 包住强度提示文字，否则屏幕阅读器不会读出“强度中等”这种动态变化；同时，别用颜色 alone 表达强弱（比如只靠红/黄/绿），得配图标或文字（✅ / ⚠️ / ❌）。国际化更麻烦：中文里“强”“中”“弱”对应英文是 “Strong”/“Fair”/“Weak”，但德语里 “Schwach” 和 “Mittel” 容易被用户误认为“无效”和“一般”，实际应译为 “Akzeptabel”（可接受）。
- 所有提示文案走 i18n key，不拼字符串
- 密码输入框设
aria-describedby指向强度说明区域 ID - 禁用 autocomplete 时写
autocomplete="new-password"，不是"off"（后者在 Chrome 下已失效）
