人脸识别这个东西,做过H5的人都知道,打开需求文档那一刻心里就开始打鼓。uniapp跨端、H5环境、活体检测、免费方案、微信SDK,这几个词凑在一起,看上去是选择题,实际上是把所有坑都给你埋好了。我去年接了一个微信公众号内嵌H5的人脸核身需求,技术选型从纯前端免费方案到微信官方人脸识别SDK都完整走了一遍,后端分别用Spring Boot和ThinkPHP各写了一套对接逻辑,这里把整个过程、踩过的坑、以及为什么最终这样取舍,一次性说清楚。
1. 两种技术路线怎么选:免费方案与微信SDK的边界
很多产品经理拿着需求过来的时候,第一句话都是“人脸识别不是很简单吗,调个API就行”。但真正落地的时候你会发现,“人脸识别”这四个字下面至少分三个层次:人脸检测、人脸比对、活体检测。而H5端能做到哪一层,完全取决于你选哪条路。
1.1 纯前端免费方案到底能做什么
纯前端免费方案,通常指的是在浏览器里直接调用摄像头,把视频帧或图片丢给前端的人脸检测模型,比如face-api.js、BlazeFace,或者一些国内开源的人脸检测库,来完成人脸定位、关键点检测、表情判断等任务。
这类方案最大的优势确实是免费,而且不需要申请任何资质,不需要企业认证,不需要后端参与,前端工程师一个人就能搞定。但你要清醒地认识到它的边界:它只能做“活体自拍确认”,不能做“实名身份核验”。
什么意思呢?就是你可以判断摄像头前面是不是一张真人的脸、用户有没有眨眼、有没有张嘴、有没有左右摇头,但你无法把这个人和身份证号码、姓名关联起来。也就是说,纯前端方案解决的是“这个操作是人做的还是机器做的”,解决不了“这个人是不是张三”。
对于很多业务场景来说,比如用户修改密码时的二次确认、账号找回时的本人验证,这个级别已经够用了。但如果你是做金融、政务、合规要求极高的场景,纯前端方案基本过不了审计。
1.2 微信SDK方案解决了什么问题
微信官方的人脸识别方案,走的是wx.faceCheck这套接口,通常是嵌在微信公众号网页里的。它和纯前端方案最本质的区别是:它背后连接的是微信的实名认证体系,能够将摄像头前的人脸与用户绑定的身份证信息做权威比对。
也就是说,你是拿“微信用户的实名信息”作为比对基准。用户在微信里完成人脸核身,微信返回给你的是一个核身结果,告诉你这个用户是不是通过了人脸与身份信息的匹配。这就不只是“活体检测”了,而是真正的“人脸核身”。
代价也很明显:需要认证的服务号、需要申请接口权限、需要后端参与签名和回调,而且通常是收费的。微信人脸识别服务的计费方式和具体价格需要跟微信官方或服务商确认,不同行业类目、不同调用量的价格差别很大。
1.3 决策建议
我的建议是,如果你的业务只是需要确认“操作者是真人”,选纯前端免费方案,成本低、上线快、不依赖外部服务;如果你的业务需要把“摄像头前面的脸”和“身份证上的信息”做权威比对,直接走微信SDK方案,别为了省那点钱在合规上冒险。
另外还有一种折中方案:纯前端做活体检测,拿到用户的自拍头像,后端再对接第三方云厂商的人脸比对API,与公安库或自有库做比对。这个方案的合规性和成本介于两者之间,适合自有用户库的场景。这次项目里我没有采用这种方案,因为客户要求优先考虑微信生态内闭环,所以重点还是放在了前两种上。如果你需要这种混合方案,选型思路是一样的,只是把微信SDK换成云厂商API。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 纯前端人脸识别方案:原理重过代码
如果你决定走纯前端免费方案,我建议你先把原理搞清楚,再动手写代码。因为这类方案代码网上搜出来一大堆,但大多数都是把开源模型封装一下,真正出了问题你根本不知道怎么排查。
2.1 摄像头采集与活体检测的本质
先说到底什么是活体检测。传统的图片识别只能判断“画面里是不是脸”,但照片里的人脸也是一张脸。活体检测要解决的,是判断“
