密码强度校验应优先使用逻辑判断而非纯正则，因正则难以实现动态得分与多类字符组合判断；推荐拆解为长度、大小写、数字、符号、重复等可加权的原子规则，并封装为可测试、可扩展的服务。
密码强度校验该用正则还是逻辑判断
纯正则表达式不适合做动态得分计算，也很难覆盖“至少含3类字符”这类条件。它适合快速过滤明显弱密码（如 123456、aaaaaa），但真正可靠的强度评估必须拆解为可编程的原子规则——比如“是否含大写字母”“是否含特殊符号”“长度是否≥8”，再加权计分。
- 正则适合做预检：
password.matches(".*[0-9].*")判断含数字，但别试图写一个正则同时匹配大小写+数字+符号+长度+非重复字符 - Java 里推荐用
Character.isUpperCase()、Character.isDigit()等逐字符扫描，比正则更可控、更易调试 - 正则在 Spring Validation 中可用于声明式校验（如
@Pattern(regexp = "^(?=.*[a-z])(?=.*[A-Z]).{8,}$")），但那是静态阈值，不支持“8分算合格，12分算强密码”这种连续得分
如何设计可扩展的密码强度评分逻辑
把强度拆成独立维度，每项给分，最后汇总。这样新增规则（比如“禁止常见键盘序列 qwerty”）只需加一个 check 方法，不影响其他逻辑。
- 基础分项示例：
lengthScore（长度分）、upperScore（大写分）、lowerScore（小写分）、digitScore（数字分）、specialScore（符号分）、repeatPenalty（重复字符扣分） - 避免硬编码分数：用常量定义各维度权重，例如
UPPERCASE_WEIGHT = 2，方便后续调整 - 注意边界：长度分不要线性增长（比如16位≠2×8位），建议阶梯制——
8–10位: 2分，11–14位: 3分，≥15位: 4分
常见误判点：正则中的特殊字符和 Java 字符串转义
写正则校验特殊字符时，[!@#$%^&*] 在 Java 字符串里要写成 "[!@#$%^&*]"，但若里面含 或 - 就容易出错。最稳妥的方式是用 Pattern.quote() 处理用户可控输入，而校验逻辑本身应尽量避开正则。
- 错误写法：
password.matches(".*[\W&&[^_]].*")—— 想匹配非单词字符但排除下划线，实际在 Java 里会因双重转义失效 - 更安全的做法：先定义合法符号集
Set<character> specials = Set.of('!', '@', '#', '$');</character>，再遍历判断 - 正则中
-放在开头或结尾才不会被当范围符，[a-z-]是对的，[-a-z]也行，但[a-z-]写成字符串就得是"[a-z-]"，不是"[a\-z]"
Spring Boot 项目中集成与测试要点
别把校验逻辑塞进 Controller 层，也不要在 Entity 上堆砌一堆 @Pattern。应该封装为独立 Service，并提供单元测试入口。
立即学习“Java免费学习笔记（深入）”；
- Service 方法签名建议：
public PasswordStrengthResult evaluate(String password)，返回含score、details（各维度是否达标）、suggestions的 DTO - 测试时重点覆盖边界：空字符串、null（提前判空）、全空格、Unicode 字符（如中文密码，通常应拒绝）、超长字符串（防 DoS）
- 注意 Locale 影响：
Character.isUpperCase('É')在某些 JVM 默认 locale 下可能返回 false，建议显式指定Locale.ENGLISH或只校验 ASCII 字符集
