背景
微信小程序提供了两个接口来满足不同的需求和场景：
获取小程序码：
- 接口 A: 适用于需要的码数量较少的业务场景
- 生成小程序码，可接受 path 参数较长，生成个数受限，有数量限制，请谨慎使用。
- 接口 B：适用于需要的码数量极多的业务场景
- 生成小程序码，可接受页面参数较短（最大32个可见字符），生成个数不受限。
获取小程序二维码（已不推荐使用）：
- 接口 C：适用于需要的码数量较少的业务场景
- 生成二维码，可接受 path 参数较长，生成个数受限，有数量限制。
获取小程序码（一物一码）
微信一物一码 支持生成小程序码。微信通过“一物一码”接口发放的二维码相比较普通链接二维码更安全、支持更小的印刷面积，支持跳转到指定小程序页面，且无数量限制。
注意事项
- 接口只能生成已发布的小程序的二维码
- 接口 A 加上接口 C，总共生成的码数量限制为 100,000，请谨慎调用。
- 接口 B 调用分钟频率受限(5000次/分钟)，如需大量小程序码，建议预生成。
由于接口A + 接口C 存在生成的数量选择，因此在需要小程序码极多的场景下，只能考虑 接口B，但对于接口B 而言，携带的参数较短，最大32个可见字符无法满足正常的业务迭代需求，故诞生了该解决方案。
设计思想
通过数据映射的方式，对小程序码归一化处理，减少对接成本，做到一次处理，处处可用的状态，所有的二维码均可追溯。
设计原理
服务端：通过映射的方式，将小程序码原始信息存储在数据库中。
小程序端：
- 新增小程序码中转层，在中转层通过 id 获取对应业务参数后跳转到指定页面。
- 支持普通小程序码方案中转（后续会补充）。
优点
- 小程序码统一管理，减少混乱
- 对后续的运营类需求友好
- 数据埋点、分析更加方便
- 无需频繁更换线上物料等
设计方案
// 小程序码关键信息类型定义 interface QR { page: string; // 实际需要跳转的页面 query: Record<string, string | number | boolean>; // 业务参数（简单类型）用于页面路由参数相关 businessData: Record<string, any>; // 业务参数，可以为复杂类型，不与路由参数关联 desc: string; id: string; }
架构图
具体实现
1）业务方调用服务端接口生成小程序码，服务端生成唯一的 id，入库一条记录，该记录包含至少以下信息：
- 唯一 id
- 真实跳转页面（形如 pages/playVideo/index）
- 页面需携带的真实参数query
- 描述字段 desc（方便后期区分业务来源）
- 其他业务字段 businessData（例如：是否需要自动绑定作品到指定用户等）
2）小程序端
- 扫码进入进入 decode 出对应的 id
- 根据对应的 id 请求获取对应的 pages query，将query里面的业务参数拼接为URL Param，然后跳转到对应的页面 (形如 /pages/videoDetail/index?taskId=xxx）
[附]扫普通码打开小程序
为了解决微信生成小程序码 API 接口不稳定，为满足 VFrame 等线上需要大量小程序码的场景中 对实时性、稳定性的要求，现接入扫普通二维码打开小程序的方案。
架构图
微信扫普通链接二维码打开小程序文档：https://developers.weixin.qq.com/miniprogram/introduction/qrcode.html
现有方案
小程序码 id 和普通二维码的 id 保持一致（包含含义及命名规则等）
跳转到小程序后，通过解析路由参数（暂时不通过场景值区分）:
- q 表示来源 微信扫普通链接二维码打开小程序（提取 q 对应的URL 里面的 id ）
- scene 表示来源于小程序码（获取 scene 对应的 id）
后续流程和上述小程序码的流程保持完全一致。
使用场景
- VFrame 等线上实时场景（需要生成大量的小程序码，且小程序码的时效性很短）
- 对于小程序码有苛刻的 UI 定制需求（且小程序码的用量会很大）
非以上场景，请使用通用小程序码 或者又个数限制的小程序二维码，具体参见文档：https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/qr-code.html
关于测试
由于对于跳转规则的测试只能设置 5 个 测试链接，加上微信直接扫码跳转是直接打开线上环境小程序
wx.navigateToMiniProgram 不支持跳转自身（方案废弃）
借助小程序 B 做中转（来回跳转的方案），二次调回原小程序体验版时小程序崩溃（方案废弃）
方案2：借助一录小程序扫码工具，自行在小程序扫码工具里面扫普通二维码即可。（由于方案1存在诸多问题，暂时只能使用方案2）
风险点
非微信扫码，无法跳转到小程序，只会到对应的H5落地页
注意事项
关于非微信客服端扫码场景：
- 线下：放置普通二维码的地方加强提示「微信扫码」
- 线上：暂时以提示用户微信扫码的静态页展示（强提醒）
- 对于线上场景除了强提醒外，通过小程序码ID生成对应的 URL Schema 实现自动跳转。