强密码需满足长度≥8位且包含大小写字母、数字、特殊字符四类中的至少三类；应通过input事件分项正则检测（小写/[a-z]/、大写/[A-Z]/、数字/[0-9]/、特殊符/1/），实时动态提示缺失项，避免仅依赖required或minlength，并注意DOM存在性、trim预处理及节流防抖。a-zA-Z0-9 ↩
密码输入框需要实时校验哪些规则才够“强”
强密码不是“越长越好”，而是要覆盖大小写字母、数字、特殊字符四类中的至少三类，且长度不小于8位。浏览器原生的 pattern 属性只能做正则匹配，无法分项提示缺失项；靠提交时 checkValidity() 报错又太晚——用户已经填完所有字段，只因密码弱就被拦住，体验差。
用 input 事件 + 正则分项检测实现动态提示
监听 input 事件比 blur 更及时，能边输边反馈。关键不是写一个大正则去“判断是否合格”，而是拆解成四项独立检测：
-
/[a-z]/→ 小写字母 -
/[A-Z]/→ 大写字母 -
/[0-9]/→ 数字 -
/[^a-zA-Z0-9]/→ 特殊字符（注意：这里用取反更稳妥，避免漏掉空格、中文等边界情况）
每项检测结果对应一个提示文案（如“需含大写字母”），用 classList.toggle() 控制显示/隐藏。别用 innerHTML 拼接，避免 XSS 风险；用 textContent 更新文本内容即可。
为什么不能只依赖 required 和 minlength
required 只管是否为空，minlength="8" 只管长度，两者都对字符类型无约束。更麻烦的是：当表单含多个必填字段时，如果仅靠 submit 事件里统一校验密码，用户点击提交后才发现密码不合规，焦点没自动跳回密码框，错误提示还可能被滚动遮挡。实际项目中，这类交互问题投诉率远高于逻辑错误。
立即学习“前端免费学习笔记（深入）”；
正确做法是：submit 事件里仍要调用 event.preventDefault() 并再次校验（防绕过 JS），但主提示必须在输入过程中完成。
兼容性与 DOM 更新时机要注意什么
IE11 不支持 input 事件对 contenteditable 区域的监听，但密码框没问题；真正容易出错的是 DOM 更新时机——如果你在 input 回调里直接操作元素 class 或 textContent，但该元素尚未插入文档（比如用 document.createElement 动态生成提示区），就会报错或静默失败。
稳妥做法：
- 确保提示 DOM 在页面加载时已存在（哪怕
display: none） - 用
Element.closest('form')关联提示区和对应密码框，避免多个表单时错乱 - 对空字符串或纯空格输入，先
.trim()再检测，否则/[0-9]/会误判“ ”为含数字
复杂点不在正则本身，而在提示状态与用户输入节奏的同步——输得快时，上一轮检测还没结束，下一轮又来了，得用简单节流（比如 setTimeout 清除前序定时器）保响应不卡顿。
