身份证核验显示不一致？五步排查顺序：从间隔号到批量监控
身份证核验不一致的五步排查:姓名归一化(间隔号冤案)、身份证号格式(末位X/空格/15位)、真伪区分(填错vs证件变更)、修改重填路径设计、批量不一致率监控。前两步解决技术冤案,中间两步救转化。
对接身份证核验接口时，最让人心慌的返回结果就是"不一致"——用户信誓旦旦说信息没错，系统却回了不一致。是用户骗你，还是系统错了？
根据我们的接客经验，相当一部分"不一致"并不是身份造假，而是可以定位和修复的技术问题。这篇文章给出一个系统的排查顺序：收到"不一致"后按这五步走，大部分冤案能在第一步就解决。
第一步：检查姓名归一化（解决约一半的"冤案"）
少数民族姓名的间隔号是重灾区。"阿依古丽·买买提"里的间隔号，在不同输入法/系统里至少有 5 种写法：·（U+00B7）、•（U+2022）、・（U+30FB）、全角句点、半角句点——权威库以标准编码登记，你原样提交用户输入的变体，就会误判不一致。
修复：核验前做姓名归一化——常见变体统一转为标准间隔号、去除首尾及中间多余空白、全角字母数字转半角（NFKC）。处理代码在之前《1108 排查》一文里有现成的 Python/Java 实现。
判定技巧：如果"不一致"集中在带"·"或生僻字的姓名上，几乎可以确定是归一化问题，不是用户问题。
第二步：检查身份证号格式
x（传大写 X 返回 1103 编码不合法），证件上印的大写 X 只是展示形态；第三步：确认是"真不一致"还是"证件状态问题"
格式和归一化都排除了，剩下的"不一致"分两种情况：
人证确实不符：用户填错了（用了别人的号、记错了自己的号、胡乱填的）——引导用户核对证件原件重填。前端提示要具体：「姓名与身份证号不匹配，请核对证件原件」，而不是一句「认证失败」。
证件已变更/注销：用户换了新证（补办、姓名变更）、旧证号已被注销回收——此时旧号码核验结果会是异常。判定方法：让用户出示证件原件核对，号码一致但仍不通的，走人工通道。
第四步：给用户"修改重填"路径，而不是直接拒绝
这一步是产品设计，不是技术——但它决定了"不一致"用户的最终转化率：
核验不一致
→ 前端明确提示哪个字段可能有问题（姓名 or 号码） → 回显用户输入，标出可疑字符（间隔号、生僻字高亮） → 允许修改重填（1-2 次） → 仍失败 → 转人工审核通道
直接拒绝的后果：真实用户流失 + 客服工单暴涨。"不一致"的用户里藏着你的真实客户。
第五步：批量场景的"不一致率"监控
单次不一致看个案，批量不一致看异常率：
小结
"不一致"排查五步：归一化 → 格式 → 真伪区分 → 重填路径 → 批量监控。前两步解决技术冤案，中间两步解决用户体验，最后一步守住批量质量。
如果你正在对接身份证实名认证接口，可以参考身份证核验接口的说明与错误码总表——不同返回码的处理动作不同，别用统一的重试逻辑应付所有失败。