小程序为什么要接身份证实名认证：与微信实名的关系、三段式架构与提审避坑
小程序业务实名与微信支付实名、手机号绑定的区别，身份证二要素核验的三段式架构（appkey 留在服务端、返回码归一化、幂等防重复计费），request 合法域名与隐私声明配置，提审驳回原因与常见坑清单。
不少做小程序的团队都有这个疑问：微信本身就要求用户实名（微信支付实名、手机号绑定），为什么业务里还要再接一道"身份证实名认证 API"？这篇把关系讲清楚，然后给一份小程序侧的接入实践——哪些事放在小程序前端做、哪些必须回到自己的服务端、微信域名白名单怎么配。
一、先厘清：微信的实名 ≠ 你业务的实名
微信生态里的"实名"其实是三件事，很多需求文档把它们混为一谈：
getPhoneNumber 能力），它证明"号码实名在运营商侧登记过"，但登记人不一定是当前使用者——借用家人手机号注册的场景非常普遍；结论很直接：当你的业务需要"确知用户是谁"——电商大额下单、二手交易、预约服务、租赁、内容平台风控——只有身份证二要素核验能给你这个确定性：提交的姓名和身份证号，在权威数据库里是否为同一人。微信侧的任何既有实名都替代不了这一步。
二、小程序的三段式架构：核验放哪一段
一个常见的设计错误是把核验接口直接暴露在小程序前端调用。正确的分层是这样的：
用户小程序端 你的服务端 核验 API
───────────── ───────────── ───────────── 填写姓名+身份证号 → 接收表单、校验格式 → 二要素核验请求 （18位正则、11位手机号） （appkey 在这层使用） 显示核验结果 ← 记录结果与审计日志 ← 返回码归一化
三个要点：
appkey 永远不出服务端。小程序包是可以被反编译的，密钥写在前端等于公开。核验调用一律从你的后端转发，小程序只和你的后端对话；三、微信侧的必配项
小程序要调你自己的后端，绕不开这两道配置（都在小程序管理后台）：
顺带一提合规面：核验请求里用户必须有主动授权动作（勾选《实名服务协议》+单独的敏感信息授权），授权时间戳和协议版本号建议落库——监管检查或用户纠纷时，这就是"最小必要+知情同意"的证据链。
四、一个能直接抄的最小流程
服务端伪代码（Node 风格，任何语言同理）：
POST /api/realname-verify
1. 鉴权：校验小程序登录态（code2session 换出的 session） 2. 格式校验：姓名非空、身份证 18 位正则、无重复提交（幂等键：用户ID+日期） 3. 调用核验 API：姓名+身份证号 → 二要素接口（appkey 签名） 4. 结果映射：一致→verified；不一致→mismatch；格式错→提示重填； 系统异常→可重试，提示用户稍后再试（不计费或按服务商规则） 5. 审计落库：user_id、核验时间、结果、授权协议版本号 （身份证号本身按脱敏存储：前6后4，中间打码） 6. 返回业务枚举，不返回上游原始码
两处刻意的设计值得强调：幂等键防止用户连点重复计费；审计日志只存"核验过+结果+授权依据"，不落身份证号明文——这是《中华人民共和国个人信息保护法》最小必要原则在存储侧的体现，也降低了数据泄露时的实际损失面。
五、常见坑清单
相关资源
小结：微信解决的是"这个账号属于哪个微信号"，身份证核验解决的是"这个人是谁"。两层实名各司其职，你的业务需要哪一层的确定性，取决于出了纠纷时要向监管和平台回答哪个问题。