能，但仅限格式初筛；正则无法校验真实性，15位须全数字且首非0，18位末位为0-9或Xx，二者结构差异大，需分步验证日期与校验码，且必须预处理全角字符和大小写。
只用正则能同时匹配15位和18位身份证吗
能，但必须明确：正则只能做格式初筛，不校验真实性。15位全是数字，18位前17位是数字、末位是0-9或Xx，两者结构差异大，不能靠一个“万能正则”兜底。
常见错误是写成/^(\d{15}|\d{17}[\dXx])$/——看似简洁，实则漏掉关键约束：开头不能为0、18位的年份段需防乱填（如0000）、15位没校验码但也不能接受任意15个数字。
- 15位必须全数字且长度严格为15：
/^\d{15}$/，但要加^[1-9]限制首字符（避免000000...） - 18位推荐分两步：先用
/^[1-9]\d{16}[\dXx]$/快速过滤，再单独校验日期段和校验码 - 别用
^(\d{15}$|^\d{17}[\dXx])$这种嵌套写法——^和$位置错，实际会匹配失败
为什么不能直接用/^\d{15}$|^\d{17}[\dXx]$/
这个正则在PHP里会意外匹配到空字符串或部分数字串，因为|两边的^和$没对齐。正确写法必须把锚点统一包在外面：/^(?:\d{15}|\d{17}[\dXx])$/。
但即便语法正确，它仍放行大量非法组合：比如15位里的123456000101001（出生年00）、18位里的11010120991231123X（年份2099）。这些靠正则无法拦截，必须后续代码处理。
立即学习“PHP免费学习笔记（深入）”；
- 15位身份证实际已基本淘汰，2026年新系统建议直接拒绝15位输入
- 如果业务强制兼容，必须额外提取
substr($id, 6, 2)判断年份是否在1900–1999区间（15位默认19XX） - 18位中
(19|20|21)\d{2}比\d{4}更安全，但21开头目前仅理论存在，可暂限(19|20)
实际项目中怎么安全分流15/18位校验逻辑
别让正则承担所有责任。拿到$_POST['id_card']后，先做清理和长度判断，再分流：
-
$id = trim($_POST['id_card'] ?? '') ?: '';——空值或空白直接失败 -
if (strlen($id) === 15) { /* 走15位分支 */ }比正则更快，且避免正则引擎开销 - 15位转18位时，补年份用
'19' . substr($id, 6, 2)，而非'20' . ...——15位无20XX年 - 18位必须调用独立函数算校验码，不能只信正则；15位无校验码，但要验证
substr($id, 6, 6)是否构成合法日期
例如substr($id, 6, 4)取年份后，用DateTime::createFromFormat('Y', $year)检查是否解析成功，比正则(19|20)\d{2}更准。
容易被忽略的边界坑：全角数字和大小写混杂
用户复制粘贴或中文输入法下，可能输入全角数字１２３或小写x。正则[\dXx]会匹配小写x，但校验码算法要求末位统一转大写比较。
- 预处理必做：
$id = str_replace(['０','１','２','３','４','５','６','７','８','９'], range(0,9), $id); - 校验码对比前强制：
strtoupper(substr($id, -1)) === $expected_check_code - 别依赖
mb_convert_case($id, MB_CASE_UPPER)——它对数字无效，只影响字母
真正麻烦的不是正则写法，而是清理不彻底导致strlen()误判、substr()截出乱码、加权求和时遇到非ASCII字符直接崩掉。
