身份证校验必须分三层：基础格式（正则验证18位、前17位数字、末位数字/x）、日期有效性（提取7–14位并用date反向校验）、校验码计算（按iso 7064:1983.mod11-2加权模11查表），纯正则无法替代完整逻辑。
身份证号码格式校验用正则还是 Intl？
纯正则只能验格式，不能验真实性。国内18位身份证有严格校验逻辑：前6位是地址码（需查行政区划）、第7–14位是出生日期（得判断是否真实存在，比如20250230就非法）、第17位奇偶性决定性别、最后1位是加权校验码（ISO 7064:1983.MOD11-2算法）。浏览器原生 input[type="idcard"] 并不存在，别被某些文档误导。
checkIdCard() 必须实现的三步校验
真实项目里至少要分层验证，漏掉任何一层都可能放过伪造号：
- 基础格式：长度为18，前17位全是数字，最后一位是数字或
X/x - 日期有效性：提取第7–14位，用
new Date(year, month - 1, day)反向构造并比对，防止19000230这种无效日期通过字符串匹配 - 校验码计算：用固定权重数组
[7,9,10,5,8,4,2,1,6,3,7,9,10,5,8,4,2]和校验码表['1','0','X','9','8','7','6','5','4','3','2']计算，注意X不区分大小写但返回值建议统一转大写
前端校验为什么不能替代后端？
前端只防误输，不防恶意绕过。常见疏漏点：
- 没校验地址码是否在最新《中华人民共和国行政区划代码》范围内（比如用已撤销的“110105”朝阳区旧码，或瞎编“119999”）
- 没处理15位老身份证升级逻辑（补“19”+中间插入“00”，再重算末位），而部分银行/政务系统仍接受15位
- 把校验逻辑全塞进
onblur，结果用户粘贴完直接点提交，input事件没触发，校验被跳过
要不要调公安接口做实名核验？
真要确认“张三是否真叫张三且身份证有效”，前端永远做不到。必须走权威接口，但要注意：
- 公安部接口不对外开放，实际走的是银行、支付宝、运营商等持牌机构的实名认证通道（如支付宝
alipay.user.certify.open.initialize） - 这类调用需服务端签名，绝不能把
app_id和private_key暴露在前端 - 用户授权是强前提，未获明确同意就调用属于违规，页面上得有勾选框+隐私协议链接
格式校验可以前端做，真实性核验必须后端发起，且得留审计日志。很多人卡在“以为正则一配就等于验了身份”，其实连第一步都没迈出去。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
