密码复杂性校验应分项验证：长度（^.{8,}$）、小写字母（[a-z]）、大写字母（[a-z]）、数字（d）、特殊字符（[!@#$%^&*()_+-=[]{};':"|,.?]）；必要时用正向先行断言组合单正则，但需注意锚点、转义及语义规则边界。
要验证密码复杂性，正则表达式需同时检查多个条件：长度、大小写字母、数字、特殊字符。单个正则无法优雅覆盖所有场景，推荐用多个独立校验或组合式正则（兼顾可读性与可靠性）。
核心规则拆解与对应正则
避免写一个“全能”长正则，而是分项验证更清晰、易调试：
-
最小长度（如8位）：
^.{8,}$—— 确保整体长度达标 -
至少1个小写字母：
[a-z]—— 不加锚点，用于测试是否“存在” -
至少1个大写字母：
[A-Z] -
至少1个数字：
[0-9]或d -
至少1个特殊字符：
[!@#$%^&*()_+-=[]{};':"\|,./?]—— 根据业务需求调整字符集
组合式单正则（适用于简单场景）
若必须用一个正则（如后端接口统一校验），可用正向先行断言（(?=...)）组合：
^(?=.*[a-z])(?=.*[A-Z])(?=.*d)(?=.*[!@#$%^&*()_+-=[]{};'"|,./?]).{8,}$
说明：
- 每个
(?=.*...)只断言“存在”，不消耗字符 -
.{8,}控制总长度，放在最后确保前面断言不影响长度计算 - 注意特殊字符在字符组中需转义（如
、'、"），避免语法错误
实际使用建议
正则只是校验一环，还需配合其他实践：
- 前端校验用于即时反馈，但必须在后端重复校验（防止绕过）
- 避免过于严苛（如强制特殊字符），可能降低用户体验；可分级策略（如注册强校验、修改密码宽松些）
- 禁用常见弱口令（如
123456、password），正则无法覆盖，需额外字典比对 - 考虑国际化：若支持非ASCII字符（如中文、emoji），需明确是否允许，并调整正则（例如用
p{L}匹配任意字母）
常见陷阱提醒
这些细节容易出错：
- 忘记
^和$锚点 → 导致部分匹配（如"a1!"也能通过[a-z][A-Z]d） - 特殊字符未正确转义 → 正则编译失败或逻辑偏差（如
[a-z]+中的+在字符组内是普通字符） - 过度依赖正则处理语义规则（如“不能包含用户名”）→ 应由代码逻辑判断，非正则职责
