1. 为什么需要Pattern注解校验用户输入在开发Web应用时用户输入校验是必不可少的一环。想象一下如果你的注册页面不校验邮箱格式数据库里可能会存入abc123这样的无效数据如果不校验密码复杂度用户可能会设置123456这种极易被破解的弱密码。前端校验固然重要但后端校验才是最后一道防线。我见过太多因为后端校验缺失导致的安全问题。有一次接手一个老项目用户名字段没有任何校验结果有人注册了包含SQL注入代码的用户名差点导致数据泄露。这就是为什么我们需要Pattern注解——它能在数据进入业务逻辑前用正则表达式这把尺子量一量输入是否合规。2. Pattern注解的基本用法2.1 注解引入与基础语法首先确保你的项目引入了Jakarta Validation API原JSR-303。如果是Spring Boot项目spring-boot-starter-validation已经包含它dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency基本使用格式非常简单Pattern(regexp 你的正则表达式, message 校验失败时的提示信息) private String fieldName;比如校验用户名只允许中文、英文和数字Pattern(regexp ^[\u4e00-\u9fa5a-zA-Z0-9]$, message 用户名只能包含中文、英文和数字) private String username;2.2 常见问题排查新手常遇到的坑是正则表达式写错导致校验不生效。我建议先用在线正则测试工具如regex101.com验证你的表达式注意Java字符串中的反斜杠需要转义比如\d要写成\\d确保字段没有被其他注解如NotNull先拦截3. 高频使用场景的正则表达式大全3.1 用户身份相关校验复杂密码要求必须包含大小写字母、数字和特殊符号长度8-20位Pattern(regexp ^(?.*[a-z])(?.*[A-Z])(?.*\\d)(?.*[$!%*?])[A-Za-z\\d$!%*?]{8,20}$, message 密码需包含大小写字母、数字和特殊符号) private String password;中国大陆手机号严谨版校验考虑号段变化Pattern(regexp ^1(3[0-9]|4[01456879]|5[0-35-9]|6[2567]|7[0-8]|8[0-9]|9[0-35-9])\\d{8}$, message 请输入正确的手机号) private String phone;3.2 金融相关校验银行卡号16-19位数字Pattern(regexp ^[0-9]{16,19}$, message 银行卡号应为16-19位数字) private String bankCard;金额格式支持千分位和两位小数Pattern(regexp ^\\d{1,3}(,\\d{3})*(\\.\\d{2})?$, message 金额格式如1,234.56) private String amount;3.3 业务特殊需求订单编号以字母开头后接日期和5位数字Pattern(regexp ^[A-Z]\\d{8}-\\d{5}$, message 订单编号格式如A20230801-12345) private String orderNo;颜色十六进制码Pattern(regexp ^#([A-Fa-f0-9]{6}|[A-Fa-f0-9]{3})$, message 颜色格式如#FFFFFF或#FFF) private String colorHex;4. 高级技巧与性能优化4.1 预编译正则表达式频繁使用的正则表达式应该预编译private static final Pattern USERNAME_PATTERN Pattern.compile(^[\u4e00-\u9fa5a-zA-Z0-9]$); // 在代码中使用 if(!USERNAME_PATTERN.matcher(username).matches()) { throw new IllegalArgumentException(用户名格式错误); }4.2 复杂校验的拆分策略对于特别复杂的校验如密码强度建议拆分成多个简单校验// 校验长度 Size(min 8, max 20, message 密码长度8-20位) // 校验包含数字 Pattern(regexp .*\\d.*, message 需包含数字) // 校验包含字母 Pattern(regexp .*[a-zA-Z].*, message 需包含字母) private String password;4.3 自定义校验注解当标准注解不够用时可以创建自定义注解。比如校验两次输入是否一致Target({FIELD, PARAMETER}) Retention(RUNTIME) Constraint(validatedBy MatchValidator.class) public interface Match { String field(); String message() default 字段不匹配; Class?[] groups() default {}; Class? extends Payload[] payload() default {}; } public class MatchValidator implements ConstraintValidatorMatch, String { private String field; Override public void initialize(Match constraintAnnotation) { this.field constraintAnnotation.field(); } Override public boolean isValid(String value, ConstraintValidatorContext context) { // 实现校验逻辑 } }5. 实战中的经验分享在电商项目中我们曾用Pattern解决过一个棘手问题用户输入的优惠码需要同时支持ABC-123和ABC123两种格式。最终方案是Pattern(regexp ^[A-Z]{3}-?\\d{3}$, message 优惠码格式如ABC123或ABC-123) private String promoCode;另一个经验是永远要为message留足够的信息量。曾经有个报错只显示格式错误导致客服每天要处理大量咨询。后来改成请输入13-17位的信用卡号以4/5/6开头问题减少了80%。最后提醒一点正则表达式虽然强大但不要过度使用。对于特别复杂的逻辑如身份证校验码计算应该用专门的工具类处理。