必须使用HBuilderX自定义调试基座集成原生人脸SDK，JS层需通过uni.requireNativePlugin调用，参数编码、双回调、后端验签闭环及系统权限适配缺一不可。
uni-app App端调用原生人脸SDK必须走自定义基座
纯HBuilderX标准基座不支持任意原生能力扩展，人脸核身涉及摄像头控制、活体检测、加密传输等敏感操作，uni-app默认的plus.camera或uni.chooseImage完全无法满足。你写的JS逻辑再完整，没原生层支撑就是白搭。
实操建议：
- 必须使用HBuilderX的「自定义调试基座」功能，打包时嵌入第三方SDK（如支付宝
Zoloz、腾讯FaceID、百度Baidu Face）的iOS/Android原生模块 - 不能只配
manifest.json里的权限——camera、microphone、storage这些只是基础，还要在nativePlugins里显式声明已集成的人脸插件 - 真机调试前务必用「运行到自定义基座」而非「运行到手机」，否则
uni.requireNativePlugin('xxxFace')会直接返回undefined
如何让uni-app JS层安全调用原生SDK的活体检测接口
第三方SDK通常提供startLiveness、verifyIdCard这类方法，但它们不在uni全局对象里，也不能直接require。JS和原生之间靠「模块桥接」通信，漏掉任一环节就会卡死或报not a function。
实操建议：
- 先确认原生插件是否注册成功：
const facePlugin = uni.requireNativePlugin('com.example.face'); if (!facePlugin) { console.error('人脸插件未加载'); } - 调用时注意参数格式：SDK往往要求传
idCardNo、name、callback三个字段，但name含中文必须encodeURIComponent，否则Android端可能乱码导致验签失败 - 回调函数必须用
success/fail双回调，不能只写then——原生线程不走Promise链，fail里要检查err.code，比如1002可能是活体动作超时，2001是身份证照片反光
人脸比对结果如何与后端验签闭环，避免中间人篡改
前端拿到result.token或certifyId只是开始，不是结束。直接把token发给自己的后端？风险极大——攻击者可截获并重放，或伪造isPassed: true字段。
实操建议：
- 第三方SDK返回的原始数据（如
certifyId、identityInfo）必须原样透传，禁止前端拼装或解密——百度Face的identityInfo是base64+AES加密的，JS层解不了，也别试 - 后端必须调用SDK厂商提供的
queryCertifyResult接口（如支付宝zoloz.authentication.certify.query），用certifyId换真实结果，而不是信前端传来的passed布尔值 - 若需前端展示“认证成功”，只根据后端API返回的
{ code: 200, data: { passed: true } }来判断，且该接口必须带登录态校验（如Authorizationheader），不能裸奔
Android 12+ 和 iOS 17 下人脸授权弹窗被系统拦截怎么办
不是代码bug，是系统级限制。Android 12起强制要求android.permission.CAMERA在runtime申请，且首次调用startLiveness前必须已获授权；iOS 17对AVCaptureDevice访问更敏感，未在info.plist里声明NSCameraUsageDescription会导致黑屏无提示。
实操建议：
- Android端：在调用SDK前，先执行
uni.authorize({ scope: 'scope.camera' })，失败则uni.openSetting跳设置页——别等SDK内部报错才处理 - iOS端：检查
unpackage/res/ios/Info.plist是否包含<key>NSCameraUsageDescription</key><string>用于人脸识别验证身份</string>，字符串不能为空或仅空格 - 真机测试务必用目标系统版本，模拟器无法触发真实授权流程，iOS模拟器甚至不加载摄像头设备
最麻烦的其实是SDK版本兼容——比如Zoloz 5.0.0以上要求targetSdk 33，但uni-app默认生成的Android工程还是31，这时候Gradle sync会失败，得手动改build.gradle里的compileSdk和targetSdk。这种细节不踩一遍根本想不到。
