先说一个我自己的真实经历一次线上用户反馈“身份证填对了就是提交不了”查到最后是后台校验把末尾的x强制转成了大写但某些渠道又传小写两边没对齐卡了一整天。后来我把身份证校验这块彻底重写还把算法和测试用例沉淀成工具类再没出过这种低级问题。身份证号码校验在Java后端里属于“看着简单做起来全是细节”的典型功能。很多项目从CRM到金融系统只要涉及个人实名信息第一关就是身份证号合法性校验。它不只是一道面试题也是你在简历上写“熟练使用Java”时面试官最爱拿来试探基本功的考点。这篇文章我就把18位身份证号码校验这件事聊透先说号码结构再讲校验码的MOD 11-2算法原理然后给出完整的Java实现和测试用例最后分享我在实际项目中踩过的一些坑以及面试时怎么回答才能显得有经验。如果你正在写身份证校验工具或者准备Java面试这篇可以直接参考。1. 为什么要自己写身份证号码校验1.1 身份证号里藏着什么18位身份证号码并不是乱编的一串数字它由4部分组成6位地址码、8位出生日期码、3位顺序码和1位校验码。地址码表示编码对象常住户口所在县区的行政区划代码出生日期码就是生日顺序码是同一地址、同一生日区域内对同年同月同日出生的人编订的顺序号其中第17位是奇数代表男性、偶数代表女性最后一位校验码用来检验前面17位是否被抄错或改错。明白这个结构之后你就知道为什么不能一股脑用正则糊上去。正则能检查格式但检查不了“这串号码是不是真的符合证件规则”。比如“110105199003078811”这种看起来格式合法但第18位校验码可能对不上那它就是无效号码。这就是身份证校验的第一层意义把明显不合规的数据挡在系统外面。第二层意义更实际脏数据会污染后续业务。比如依赖身份证号做实名认证的用户如果号码格式都不合法第三方接口调用只会白白消耗费用和流量。一个本地校验能拦下80%以上的非法输入成本低收益肉眼可见。1.2 正则校验的局限性网上最常见的写法是^\\d{17}[0-9Xx]$能匹配17位数字最后一位数字或X但这种正则只能说是“格式校验”完全保证不了真实有效。举个反例123456789012345678这串字符长度18位前17位是数字最后一位也是数字正则直接放行。但它的前6位地址码可能完全不存在第7到14位也可能是1999年33月45日这种假日期。更重要的是通过校验码反推一下就会发现它跟真实证件规则差了十万八千里。所以在生产环境里合理的做法是“正则做第一层快速过滤 地址码和出生日期做第二层规则校验 校验码做最终数学验证”。三层都过了才能说这个号码大概率没问题。这也是我推荐所有Java开发者自己手写一遍校验逻辑的原因只有把规则拆碎了你才会真正理解为什么不能依赖单一手段。2. 核心算法MOD 11-2 校验码原理2.1 权重因子怎么定18位身份证号前17位中每一位都对应一个固定的权重因子从左到右依次是7、9、10、5、8、4、2、1、6、3、7、9、10、5、8、4、2。这些数字不是拍脑袋定的而是国家标准化委员会采用的ISO 7064:1983 MOD 11-2校验码算法里确定的加权因子。校验算法本身很简单把前17位数字分别乘以对应权重再求和然后用和值除以11取余数。余数的区间是0到1011个可能的结果对应11个校验字符。为什么是11因为模11的校验能力比较强可以检测出单字符错误和大部分换位错误。处理身份证数据时最常见的错误就是用户输错一位数字或者把相邻两位数字调换了MOD 11-2算法对这种错误有较高检出率所以被选作公民身份号码的标准校验算法。2.2 校验码映射规则用前17位加权求和的余数映射出最后一位校验码。余数0到10对应关系如下余数012345678910校验码10X98765432注意余数2对应大写字母X不是英文字母“克斯”的随意发挥而是罗马数字X表示10。因此最后一位用X表示值10保证总共刚好18位字符。处理用户输入时X需要允许大小写两种形式进行兼容。这个映射表看起来很枯燥但它是整个校验的“解码器”。我建议你在代码里用一个长度11的字符串常量来存储10X98765432索引0的位置放1索引1放0索引2放X后面依次9到2。这样直接用数组或者字符串charAt取值既清晰又不容易写错。2.3 一段代码读懂计算过程把刚才的原理转成语义化代码大致是这个样子public static boolean isValidIdCard(String idCard) { if (idCard null || idCard.length() ! 18) { return false; } char[] chars idCard.toUpperCase().toCharArray(); int[] weights {7, 9, 10, 5, 8, 4, 2, 1, 6, 3, 7, 9, 10, 5, 8, 4, 2}; int sum 0; for (int i 0; i 17; i) { char c chars[i]; if (c 0 || c 9) { return false; } sum (c - 0) * weights[i]; } int mod sum % 11; String verifyCode 10X98765432; return verifyCode.charAt(mod) chars[17]; }这段代码已经能完成最核心的校验码校验但还没做出生日期和地区码校验。实际项目中肯定不能只依赖这一层否则2025年13月40日这种非法日期也会被放过去所以下面会继续补全。3. 完整的Java实现从方法到工具类3.1 基础版本校验前17位与校验码先落地一个可以直接用的基础版本核心逻辑前面已经写出来了这里加上空指针、长度、非法字符等前置判断。public class IdCardValidator { private static final int[] WEIGHTS {7, 9, 10, 5, 8, 4, 2, 1, 6, 3, 7, 9, 10, 5, 8, 4, 2}; private static final String VERIFY_CODE 10X98765432; public static boolean validate(String idCard) { if (idCard null || idCard.length() ! 18) { return false; } String upper idCard.toUpperCase(); char[] chars upper.toCharArray(); int sum 0; for (int i 0; i 17; i) { char c chars[i]; if (!Character.isDigit(c)) { return false; } sum (c - 0) * WEIGHTS[i]; } char last chars[17]; if (last ! X !Character.isDigit(last)) { return false; } char expected VERIFY_CODE.charAt(sum % 11); return expected last; } }这个版本足够应付面试里的核心考点了。但生产环境要求更高地址码和生日都要落进去。有经验的面试官会追问一句“如果给你一个字符串你怎么判断出生日期是合法的”这时候只会校验码显得准备不足。3.2 进阶版本加入出生日期和地区码判断18位身份证的第7到14位是出生日期第7到10位是年份第11到12位是月份第13到14位是日期。地区码是前6位虽然没办法在无数据源情况下判断所有行政区划是否真实存在但可以做基础范围过滤比如前两位省份码必须在正常的取值区间内。出生日期处理建议直接用Java 8之后的LocalDate简单可靠还能自动处理闰年、大小月这些规则。注意不要用SimpleDateFormat的parse默认行为去判断因为它默认会宽松解析比如2月30日可能会被解析成3月2日校验结果就是错的。import java.time.LocalDate; import java.time.format.DateTimeFormatter; import java.time.format.ResolverStyle; private static final DateTimeFormatter DATE_FORMATTER DateTimeFormatter.ofPattern(yyyyMMdd) .withResolverStyle(ResolverStyle.STRICT); private static boolean isValidBirthDate(String idCard) { try { String birth idCard.substring(6, 14); LocalDate date LocalDate.parse(birth, DATE_FORMATTER); return !date.isAfter(LocalDate.now()); } catch (Exception e) { return false; } }这里用ResolverStyle.STRICT严格模式是防止2月30日、13月这样的非法日期被解析成功。LocalDate.parse出现异常就返回false逻辑上很清晰。地区码方面我一般会维护一份省份码到省份名称的静态映射。这样做的成本很低但能把“110105...”这种有效号码识别出来把“999999...”这种明显乱填的号码拦截住。如果项目需要更精确的县区级校验就得引入行政区划数据表或者调用第三方API这已经超出一个工具类的范围了。3.3 让结果更友好封装校验结果对象方法返回boolean足够用于快速拦截但在需要提示用户具体原因的场景里比如表单校验要提示“出生日期不合法”而不是“身份证格式错误”boolean就不够用了。我习惯封装一个校验结果对象来承载失败原因public class ValidateResult { private final boolean pass; private final String message; private ValidateResult(boolean pass, String message) { this.pass pass; this.message message; } public static ValidateResult ok() { return new ValidateResult(true, 校验通过); } public static ValidateResult fail(String message) { return new ValidateResult(false, message); } public boolean isPass() { return pass; } public String getMessage() { return message; } }然后主方法逐层校验先长度再字符再地区码再出生日期最后校验码。这样用户拿到的错误提示非常具体排查问题也快。下面这段是完整结构public static ValidateResult check(String idCard) { if (idCard null || idCard.length() ! 18) { return ValidateResult.fail(身份证号码长度应为18位); } String upper idCard.toUpperCase(); if (!upper.matches(\\d{17}[0-9X])) { return ValidateResult.fail(身份证号码包含非法字符); } if (!isValidProvinceCode(upper.substring(0, 2))) { return ValidateResult.fail(地址码不合法); } if (!isValidBirthDate(upper)) { return ValidateResult.fail(出生日期不合法); } if (calculateVerifyCode(upper) ! upper.charAt(17)) { return ValidateResult.fail(校验码不匹配); } return ValidateResult.ok(); }把校验码计算单独抽成方法也方便其他地方复用比如给15位身份证升级成18位时要用到同样的算法。4. 测试验证与踩坑实录4.1 用什么测试用例写工具类不配单元测试等于没写。身份证校验这种纯函数逻辑最适合做数据驱动测试。我通常准备几类用例正规有效号码真实身份证号在脱敏后可以作为正向用例比如11010519491231002X这类公开测试号码。校验码错误号码把有效号码最后一位改掉应该被拦截。出生日期非法号码比如第7-14位是19900230必须被拦截。前17位包含非数字字符比如中间混入了字母o。长度为17位或19位或者空字符串、null。尾号x大小写异类X和x都应通过。这些用例覆盖了校验常犯的错误类型。我建议用JUnit 5的ParameterizedTest配合CsvSource来写一屏代码就能跑完几十个用例。4.2 实测几种典型输入我本地跑了一组输入结果比如下输入结果说明11010519491231002X通过经典测试号码110105194912310021不通过最后一位不是校验码110105199002309999不通过2月30日不存在999999199001010010不通过地区码不合法11010519491231002x通过小写x被兼容每次想当然觉得“这种错不会有人犯”时线上数据都会打脸。比如把年份输成0991或者把月份输成00的情况真实业务里一点不少见。这也是我坚持在方法里做严格日期校验的原因。4.3 代码性能与并发安全这个工具类没有任何可变状态所有辅助数组和格式化器都是静态final天然线程安全。性能上一次完整校验就是几次字符串切割、一次正则匹配、一次日期解析耗时基本都在微秒级别接口调用上千并发也没压力。需要注意的坑是不要把DateTimeFormatter设成全局可变对象导致线程安全问题我这里用final的常量没问题。另外如果项目还在用Java 7LocalDate用不了只能退回去用Calendar配合setLenient(false)来严格校验日期代码会繁琐一些但思路一样。5. 常见问题与面试加分项5.1 15位旧身份证怎么办有些老系统或者存量用户中还会有15位身份证号。15位的结构是6位地址码 6位出生日期没有19 3位顺序码没有校验码。简单的兼容方案是把15位统一升为18位年份前面补“19”然后重新计算校验码。public static String convert15To18(String oldIdCard) { if (oldIdCard null || oldIdCard.length() ! 15) { throw new IllegalArgumentException(15位身份证号码长度错误); } String id17 oldIdCard.substring(0, 6) 19 oldIdCard.substring(6); char verifyCode VERIFY_CODE.charAt(calcSum(id17) % 11); return id17 verifyCode; }要注意的是15位号是1999年之前签发的所以年份前面硬补“19”在绝大多数场景下是没问题的。但如果你做的是涉及历史数据清洗的项目得结合具体业务确认是否要支持1920年前出生的人群那种情况补“19”就不对了。5.2 尾号x大小写与格式细节身份证号码最后一位可能是X这个字符在现实中经常被用户输入成小写x、字母x甚至数字10。我的建议是校验之前统一toUpperCase()数据库存储也统一存大写展示的时候按业务需求决定是否保留原始输入。还有一个容易忽略的点有些输入法会把X输成全角“”这种字符toUpperCase()也救不回来会被Character.isDigit判断成false直接拒掉。如果你对用户体验要求高可以在入口层做全角转半角的预处理。5.3 前端、后端、数据库怎么配合校验不能只放在后端。用户体验上前端失焦时先用相同算法做即时提示能减少大量无效提交数据完整性上后端必须做最终校验因为接口可以被绕过数据库层不推荐用check约束去写这种业务逻辑维护起来很麻烦最多对身份证字段做唯一索引避免同一证件号重复录入。我见过很多项目前后端各写一套校验规则还不一致前端提示某号码有效后端却报错用户直接懵了。更合理的做法是把校验逻辑抽成公共包或微服务前后端通过接口协议共用同一套规则至少也要保证算法逻辑一致。5.4 面试这样答显得有经验面试官问“Java如何实现身份证号码校验”时大多数人会背诵正则匹配和校验码算法这是及格水平。想拿高分可以从下面几个点切入先讲18位结构再引出校验码的MOD 11-2原理说明为什么用11做模数。强调正则只能过滤格式无法判断真实性所以必须叠加出生日期和地区码校验。抛出“15位旧号码如何兼容”“X大小写怎么处理”“严格日期解析用什么API”这些工程细节。补充测试用例设计告诉面试官你不仅会写功能还会写边界测试。这几点下来面试官基本能判断你踩过真实业务的坑而不是只看了几篇八股文。实际上这种问题就是考察你有没有完整处理过一个需求闭环结构分析、算法实现、边界处理、测试验证。6. 从身份证校验延伸出去的思考6.1 校验码算法并不神秘MOD 11-2只是加权校验码的一种类似的思想在银行卡号Luhn算法、ISBN图书编号里都有。掌握身份证校验码的实现后你会发现校验码的本质就是用一组规则对原始数据进行计算然后附加一个结果字符用来检测数据在传输或输入过程中是否被篡改。理解这一层之后你再看到任何带校验位的编码规则都会习惯性去分析它的算法结构。这种思维方式比背一行正则值钱得多也是很多Java面试官真正想从“身份证校验”这道题里看到的东西。6.2 工程上放在哪一层更合适工具类可以放在common模块但要注意它不应该强依赖HttpServletRequest、用户密码等业务上下文。一个纯粹静态方法的工具类方便单元测试也方便在Spring Boot之外的地方复用。如果项目微服务化建议把它下沉到common-validator这样的独立基础库通过Maven坐标引用。多个服务同时依赖同一份校验逻辑避免A服务刚修好B服务还在用旧方法。实际管理中版本语义化很重要改校验规则时要谨慎因为身份证校验规则基本是恒定不变的但地区码数据却可能随着行政区划调整而变化。6.3 后续还可以怎么扩展除了校验身份证号还能做脱敏。用户列表页通常只显示前6位和后4位中间8位打码。这个功能可以顺手做成工具方法复用身份证解析逻辑public static String mask(String idCard) { if (!validate(idCard)) { return null; } return idCard.substring(0, 6) ******** idCard.substring(14); }再进一步如果你在做风控或数据仓库身份证号还可以用于提取籍贯、年龄、性别等派生维度。但派生字段只能作为参考业务上所有决定都应该基于用户上传的证件照片或权威接口核验结果不能只信赖身份证号本身。我在实际项目中一般会把身份证校验工具类做成独立模块并附上完整的单元测试每次改动都跑一遍全量用例。这样无论前端换了多少次后端接口保证了最后一道防线心里就有底。如果你也在维护类似的基础功能建议你好好打磨一下这个“小工具”它能帮你避开不少线上数据脏、接口被刷、用户投诉的麻烦。
