必须用 javascript 监听 input 事件配合正则与字符集检测实现分级提示，纯 pattern 无法动态反馈；提示需紧贴 input 下方用 display: none 控制显隐，前后端校验策略须一致且可配置。
密码强度校验用 pattern 还是 JavaScript？
纯 pattern 只能做正则匹配，无法动态反馈“已输入8位但缺大小写字母”，更没法实时计算熵值。真实项目里必须用 JavaScript 监听 input 事件，配合正则 + 字符集检测做分级判断。
常见错误是只检查长度或只用一个正则（比如 /^(?=.*[a-z])(?=.*[A-Z]).{8,}$/），漏掉数字、符号、重复字符等维度，导致“Password123”被误判为强密码。
- 用
input事件而非blur，用户打字时就提示，别等失焦才反应 - 避免每键都重算全部规则，可节流到 100ms 内最多触发一次
- 区分“最低要求”和“强度评分”：前者决定表单能否提交，后者影响 UI 提示颜色/文字
如何用 CSS 控制密码强度提示的显示位置和样式
提示文案不能塞进 label 或拼在 input 后面——会被屏幕阅读器误读，且响应式布局容易错位。正确做法是紧贴 input 下方加一个 <div class="pw-strength-hint"></div>，用 CSS 的 margin-top 和 font-size 控制间距与字号。
容易踩的坑：用 position: absolute 定位提示框，结果父容器没设 position: relative，提示飘到页面左上角；或者用 visibility: hidden 隐藏提示，但占位空间还在，导致表单高度跳动。
立即学习“前端免费学习笔记（深入）”；
- 提示容器初始状态用
display: none，有内容时切为display: block - 颜色别只靠红/绿区分强度，加图标（如 ???）或文字（“弱”“中”“强”）
- 移动端注意提示文字行高，避免被虚拟键盘遮挡
后端验证和前端提示必须一致吗？
必须一致，但实现方式不同。前端提示是体验层，可以宽松（比如允许空格、不强制特殊字符）；后端验证是安全层，必须严格按策略执行（例如要求至少1个符号、禁止常见弱口令字典词）。
典型翻车点：前端显示“强密码 ✅”，用户点击提交却收到后端返回的 "Password must contain at least one special character" 错误。这是因为前端校验漏了符号检查，或用了和后端不一致的正则。
- 把后端密码策略（最小长度、必需字符类型、禁用字典）同步给前端，写成配置对象，而非硬编码在 JS 里
- 前端提示等级（如“中”）不等于后端是否接受，仅作参考；最终以
400响应体里的message为准 - 若后端用 zxcvbn 库评估强度，前端也应引入同版本 zxcvbn，避免评分逻辑差异
移动端软键盘弹出时，密码强度提示被顶出视口怎么办
这是 iOS Safari 和部分安卓 WebView 的通病：软键盘推起页面，但固定定位的提示元素不会自动上移。不能依赖 window.scrollTo()，因为滚动行为不可靠且触发时机难捕捉。
真正有效的解法是监听 resize 事件（iOS 键盘弹出会触发 viewport 尺寸变化），结合 document.activeElement === inputEl 判断当前焦点是否在密码框，再用 scrollIntoView({ behavior: 'smooth', block: 'nearest' }) 滚动提示容器到可视区。
- 别用
focus事件直接滚动——键盘还没完全弹出，滚动位置不准 - 安卓部分浏览器 resize 不稳定，需加 100ms 延迟再执行
scrollIntoView - 如果提示容器本身在 modal 或 fixed 弹层里，要确保其父容器有
overflow: visible，否则scrollIntoView失效
