密码强度检测须前后端双重校验：前端在form submit事件中实时校验并preventDefault，拆分正则为独立规则；后端必须复用相同逻辑校验，防止绕过。
密码强度检测该在哪个环节做
必须在前端做实时校验，但不能只依赖前端。浏览器提交表单前，submit 事件里触发检测；后端仍需独立验证，因为前端可被绕过。
常见错误是只用 onblur 或 change，导致用户按回车提交时跳过检测。正确做法是在 form.addEventListener('submit', ...) 中调用检测函数，并在不满足条件时调用 event.preventDefault() 阻止提交。
正则表达式怎么写才真正有效
别用一个超长正则硬套所有规则——难维护、难调试、错误提示也不友好。应该拆成多个独立检查项，每个对应一条明确策略：
-
/[a-z]/至少一个英文小写字母 -
/[A-Z]/至少一个英文大写字母 -
/[0-9]/至少一个数字 -
/[^a-zA-Z0-9]/至少一个特殊字符（如!@#$%） -
.length >= 8长度不低于 8 位
注意：/[^a-zA-Z0-9]/ 在中文输入法下可能匹配空格或全角符号，若业务要求严格，建议显式列出允许的特殊字符集，例如 /[!@#$%^&*()_+-=[]{};':"\|,./?]/。
立即学习“前端免费学习笔记（深入）”；
如何给用户清晰的实时反馈
光弹个 alert 或控制台打日志没用。应在密码输入框下方用 <div id="pwd-tip"></div> 动态显示状态，颜色和文案随校验结果变化：
- 未输入：灰色提示“请输入密码”
- 长度不足：红色“至少 8 位”
- 缺大写：橙色“需含大写字母”
- 全部通过：绿色“强度足够”
别等用户输完再检查——监听 input 事件，每次按键后立即重跑全部规则。但注意避免频繁 DOM 操作，可用 debounce 控制频率（如延迟 150ms），否则在低配设备上会卡顿。
后端验证为什么不能省略
前端 JS 可被禁用、绕过或直接篡改。比如用户删掉校验逻辑、用 curl 直接 POST、甚至用浏览器开发者工具修改 type="password" 为 text 后注入恶意值。
后端必须重新执行相同规则（推荐复用同一套校验逻辑，如 Node.js 里导出为独立函数，Python 里封装成 utils 方法）。常见疏漏点：
- 忽略 Unicode 字符处理（如用户输入中文字符当“特殊符号”，实际不符合业务定义）
- 正则未加
^和$导致部分匹配就放行（例如/[0-9]/会把"abc"判为含数字） - 服务端未统一编码（如接收时是 UTF-8，但正则引擎按 Latin-1 解析，导致中文或 emoji 匹配异常）
最稳妥的做法：前端只负责体验，后端才是唯一可信防线。密码字段进数据库前，必须经过完整强度校验，且失败时返回明确错误码（如 400 Bad Request + {"error": "password_weak"}），而不是静默截断或降级处理。
