后台要测实名认证流程，同事直接搜「免费 500 个实名认证身份证号码」，下了一堆 txt 文件。用之前最好先停一下：这些号码要么是编的、过不了校验，要么是真实公民的信息，后者用一次就踩线了。

网上流传的号码为什么大多不能用

身份证号最后一位是校验位，按国家标准 GB 11643 算出来的。随手编的号码九成过不了校验，接口第一步就拒了。剩下能过校验的，往往对应真实存在的人，被批量倒卖过很多轮。这类信息属于敏感个人信息，未经本人同意收集使用，风险远大于省下的那点测试时间。

校验位怎么算

前十七位分别乘以固定权重：7、9、10、5、8、4、2、1、6、3、7、9、10、5、8、4、2，全部相加后对 11 取模。余数 0 到 10 依次对应校验字符 1、0、X、9、8、7、6、5、4、3、2。所以最后一位可能是大写 X，不是数字。

权重 [7,9,10,5,8,4,2,1,6,3,7,9,10,5,8,4,2] 求和取模 11 查表 [1,0,X,9,8,7,6,5,4,3,2]

自己生成测试数据才是正路

用虚构的地址码，配合任意出生日期和顺序码，再按上面的规则算出校验位。这样号码格式能过校验，又不会命中真实的人。写个十几行的小脚本批量生成，要多少有多少，还能覆盖边界情况：闰年 2 月 29 日、地址码不存在、顺序码为 000、校验位是 X。

测试环境要拦住真实调用

实名认证通常对接第三方服务，测试环境和生产环境必须分开配置，测试数据不能发到真实通道。用一个开关控制，默认走 mock，返回可控结果，比如指定号码返回认证通过、指定号码返回姓名不一致。日志里不要明文打印身份证号，排查时打码，保留前后各四位就够。

合规上的几条硬线

  • 最小必要：不需要实名的功能，不要收集身份证号。
  • 加密存储：落库前加密，密钥与数据库分开管理。
  • 可追溯：谁在什么时间因为什么查了谁的实名信息，要有审计日志。
  • 不二次使用：为 A 业务收集的信息，不能拿去做 B 业务的营销。

压测也别用真数据

并发压测同样跑 mock 通道，不要在测试环境里刷真实接口，既浪费配额也容易触发风控。要验证性能，就压自己那层封装和数据库写入，实名服务本身的速度不由你决定。

取舍：测试数据多花半小时自己生成，比事后解释数据来源省太多事。真要压测，用脱敏数据和 mock 通道，别碰真实号码。