很多团队一想到「公众号里验真」就默认要网页授权拿 openid。对本玩法而言，目标是匹配「刚扫过包装码的同一个人」，不是建立长期微信身份——指纹短凭证更轻、也更少权限依赖。
为什么刻意不做 OAuth
网页授权要处理授权页跳转、用户拒绝、scope 变更与 openid 存储。对「扫码后 5 分钟内点菜单出结果」这一场景，授权链路过重，也容易在未关注用户上失败。指纹方案只回答一个问题：当前菜单请求，是否对应刚刚那次外链扫码。
指纹由哪些字段组成
常见做法是把手机型号、系统版本、微信版本（UA 解析）与屏幕分辨率、系统语言（前端采集）规范化后做哈希，再与公网 IP 组成 Redis 键。菜单页用同一规则重算，命中则取出密文码进入验真。
它不是账号体系
- 不替代 UnionID / 会员登录；领奖仍走官方小程序既有身份；
- 不作长期画像主键，短时 TTL 后自动失效；
- 统计以 MySQL 触达表为准，Redis 只做匹配，不作报表源。
合规与产品文案
采集字段应限于核验匹配所必需，并在隐私说明中交代用途。不要把指纹表述成「微信实名」或「绑定微信号」。更完整的消费者数据处理原则，可参考 扫码数据合规。
少拿一个 openid，往往多一分可落地性——在验真主链路上，够用且可审计，比权限堆满更重要。
常见问题
换网络或开代理会怎样？
公网 IP 变化可能导致凭证无法命中，需重新扫包装码。
同一 Wi-Fi 多人会串码吗？
键包含指纹维度，降低同 IP 串扰；仍建议引导用户尽快完成菜单核验。
需要 JS-SDK 签名吗？
本玩法不依赖 JS-SDK；菜单只是打开约定好的 /verify H5。
