密码强度校验必须前后端协同：前端仅作实时体验优化，后端才是唯一可信防线，需独立校验原始密码，覆盖长度、字符多样性、弱口令黑名单、连续重复字符、键盘序列等真实风险点。
密码强度校验该用前端还是后端
前端校验只是体验优化，不能替代后端验证。用户可以禁用 JavaScript、绕过表单提交逻辑，甚至直接发 POST 请求。所以 checkPasswordStrength 这类函数只应在输入时给用户实时反馈，而真正的强度判断（比如是否含 2 类字符、长度 ≥ 8、不含常见弱口令）必须在后端重复执行。
- 后端校验必须独立于前端传来的“强度分值”，只依据原始密码字符串重新计算
- 前端可调用
zxcvbn库做启发式评估，但它返回的是估算熵值，不是合规性结论 - 如果后端用正则硬匹配（如
/^(?=.<em>[a-z])(?=.</em>[A-Z])(?=.*\d)/），注意它不防字典词、重复字符或键盘序列（如qwerty）
用正则写密码规则容易漏掉什么
纯正则很难覆盖真实风险点。比如 /^[a-zA-Z0-9!@#$%^&*]{8,16}$/ 看似限制了字符集和长度，但允许 aaaaaa1! 或 password123 —— 它们完全符合正则，却极弱。
常见疏漏包括：
- 不检查连续重复字符：
/([a-zA-Z0-9])\1{2,}/可捕获aaabbb - 不排除常见弱口令：需预加载黑名单（如
["123456", "password", "admin"]），且要做大小写+常见变形归一化（"Password123" → "password123"） - 不检测键盘模式：
qwerty、asdfgh、1q2w3e这类需单独比对预定义序列数组 - Unicode 字符处理不当：比如用户输入全角数字
１２３，正则\d匹配不到，导致误判
zxcvbn 库在浏览器里怎么安全用
zxcvbn 是目前最贴近人类直觉的密码强度评估库，但它体积大（min 版约 700KB）、默认加载全部字典（含英文常见词），生产环境需裁剪。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 只需保留核心逻辑 + 中文常用词表（可删掉非目标语言的字典 JSON）
- 调用时传入用户名、邮箱等上下文，提升识别针对性弱口令的能力：
zxcvbn(password, [username, email]) - 注意它返回的
score是 0–4 的整数，但不要直接当“通过/拒绝”开关——应结合业务策略：比如score < 3提示加强，score === 0才禁止提交 - 避免在每次 keyup 都调用：加个
setTimeout防抖，延迟 300ms 再算，否则输入快时卡顿明显
服务端校验要防哪些绕过手段
即使前端做了完整校验，攻击者仍可能：
- 发送空格包裹的密码：
" password123 "，后端必须先.trim()再校验 - 插入零宽字符（
、），肉眼不可见但影响正则匹配，需用/[\u200B-\u200F\u202A-\u202F\uFEFF]/g清洗 - 利用编码绕过：如把
a换成全角ａ（U+FF41），需统一转为 ASCII 再比对（可用String.prototype.normalize('NFKC')） - 提交超长密码触发栈溢出或 OOM：后端应限制接收长度（如
max_length=64），超出直接拒收，不进校验逻辑
真正难的不是写出八条规则，而是让每条规则在 Unicode、性能、用户体验之间不互相拆台。比如强制“至少一个特殊字符”，就得明确列出允许范围（!@#$%^&*()_+-=[]{}|;:,.<>?），而不是用 \W —— 后者会把中文标点也认作“特殊”，反而降低可用性。
