应使用 input 事件配合 compositionstart/compositionend 实现密码强度实时检测，避免 onchange、keyup、blur 等误用；需加防抖、过滤输入法中间态、分层打分（防连续/重复字符、弱口令、键盘序列），pattern 仅作基础约束。
密码强度检测该用哪个事件监听
别用 onchange，它只在失焦时触发，用户边输边改根本没反馈。实时检测必须靠 input 事件——它捕获每一次输入、粘贴、删除，包括中文输入法未上屏的中间状态（需配合 compositionstart/compositionend 过滤）。
常见错误现象：keyup 漏掉长按重复输入、手机虚拟键盘粘贴、剪贴板拖入；blur 导致用户填完才提示“太弱”，体验断裂。
- 监听
input，但加防抖（如 300ms），避免高频计算拖慢输入 - 对中文输入法：监听
compositionstart暂停检测，compositionend再触发一次 - 移动端务必测试软键盘「粘贴」按钮——它不触发
keyup，但会触发input
正则判断密码强度容易漏哪些规则
单纯用一个大正则匹配“大小写数字符号”是错的：它无法量化强度，也无法区分“Abc123!”（6位勉强达标）和“aA1!aA1!”（8位但模式重复）。真实场景要分层打分。
典型漏判：
立即学习“前端免费学习笔记（深入）”；
- 连续字符：
"123456"、"abcde"—— 用循环比对相邻 ASCII 差值 - 重复字符：
"aaabbb"—— 统计单字符出现频次，超 3 次扣分 - 常见弱口令：
"password"、"12345678"—— 建轻量白名单数组，includes()快速拦截 - 键盘序列：
"qwerty"、"!@#$%^"—— 预置几组常见序列字符串，检查子串包含
HTML5 pattern 属性能替代 JS 检测吗
不能。pattern 只在表单提交时校验，且只支持单个正则，无法做长度统计、字符分布分析、字典匹配等动态逻辑。它适合做兜底（比如强制至少 8 位），但绝不能当唯一手段。
性能影响明显：复杂正则在 pattern 中会导致移动端键盘弹出延迟，尤其 iOS Safari 对 pattern 解析较重。
-
pattern仅用于基础格式约束，例如pattern=".{8,}"或pattern="[a-zA-Z0-9!@#]{8,}" - 把真正强度逻辑全交给 JS，用
setCustomValidity()手动控制报错文案 - 别在
pattern里写多行正则或前瞻断言——兼容性差，Chrome 之外基本不认
为什么移动端密码强度条总显示不准
核心是输入法干扰。用户用拼音输入法打“zhifubao”，实际 DOM 值可能是空或乱码，直到选词完成。此时 JS 读到的 value 不是最终密码，导致分数虚高或骤降。
解决关键：不是禁用输入法，而是识别输入法状态。
- 监听
compositionstart时置标志位isComposing = true，暂停所有强度计算 - 监听
compositionend后立刻执行一次检测，并重置标志位 - 对 iOS Safari，额外监听
textInput事件补漏（它在某些粘贴场景下更可靠） - 别依赖
selectionStart判断光标位置来推测输入状态——移动端不可靠
最常被忽略的是：没处理「剪贴板粘贴后直接点登录」这个路径。用户跳过所有输入事件，只触发一次 input，但你的防抖可能刚清空定时器，导致没检测就提交了。
