密码复杂性的校验，看似简单，实际开发中却暗藏不少陷阱。许多开发者习惯堆砌一个超长的正则表达式，试图一次性完成所有检查，然而效果往往不尽如人意——要么可读性极差，要么边界情况频频出错。更推荐的做法是采用分项验证，将每个条件拆解开来，清晰明了且易于调试。
核心规则拆解与对应正则表达式
与其编写一个让人头疼的“全能巨无霸”正则，不如老老实实分项验证。每一条规则对应一个独立的检查项，逻辑一目了然：
- 最小长度（例如8位）：
^.{8,}$—— 确保整个字符串达到指定长度 - 至少包含1个小写字母：
[a-z]—— 不加锚点，仅检查“是否存在” - 至少包含1个大写字母：
[A-Z] - 至少包含1个数字：
[0-9]或\d - 至少包含1个特殊字符：
[!@#$%^&*()_+\-=\[\]{};':"|,./?]—— 具体字符集可根据业务需求灵活调整，务必将常见符号都纳入其中
这种分开验证的方式有一个显著好处：一旦某个条件失败，就能向用户给出精确的提示（例如“缺少大写字母”），而不是笼统地报“密码不符合复杂度要求”，从而大幅提升用户体验。
组合式单正则（适用于简单场景）
如果后端接口强制要求使用单个正则（例如某些框架内置的预定义校验规则），那就需要借助正向先行断言（(?=...)）了。一个典型的组合式正则如下：
^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[!@#$%^&*()_+\-=\[\]{};':"|,./?]).{8,}$
解读其原理：
- 每个
(?=.*...)仅做断言，不消耗字符，它的含义是“后面必须存在某个模式” .{8,}放在最后控制总长度，确保前面的断言不会干扰长度判断- 注意特殊字符在字符组中需要正确转义（例如
\-、\[、\]、\\），否则正则引擎会抛出语法错误
这种写法虽然能够用一个正则完成任务，但可读性确实不如分项校验。建议仅在接口限制严格或测试框架强制要求单正则时使用，否则还是分项方式更友好。
实际使用建议
正则只是密码校验的一个环节，真正落地时还需注意以下几点：
- 前端校验用于即时反馈，但务必牢记——后端必须重新做一遍校验。前端绕过过于简单，后端才是真正的安全防线。
- 不要把规则定得太死板，例如强制要求必须包含特殊字符，这会显著降低用户体验。建议采用分级策略：注册时要求强密码，修改密码时适当放宽标准。
- 常见弱口令（如
123456、password、qwerty）正则无法识别，需要额外通过字典对比来过滤。 - 考虑国际化场景：如果用户可能使用中文、日文、emoji 等非ASCII字符，必须明确是否允许。若允许，可以用
\p{L}匹配任意Unicode字母，但需注意正则引擎是否支持此特性。
常见陷阱提醒
以下几个坑，连许多老手都曾踩过：
- 忘记
^和$锚点——如果只写了[a-z][A-Z]\d，那么像"a1!"这种只有3位的字符串也能匹配成功（因为它只要求存在顺序出现的小写、大写、数字，并未约束开头结尾）。锚点必须加上，否则部分匹配会导致校验形同虚设。 - 特殊字符转义不完整——在字符组
[...]内部，有些字符具有特殊含义（例如]、\、^、-），需要正确转义。尤其是-放在中间会被解释为范围，必须放到开头或结尾，或者前面加反斜杠。 - 别让正则承担不该承担的语义规则——像“密码不能包含用户名”这种逻辑，应该由代码逐字符判断，而不是硬塞进正则。正则只负责检查格式，语义规则应交给业务逻辑处理。
