uni-app实现小程序动态二维码生成与分享

先来个核心结论：在小程序端，前端只能生成普通的二维码（比如URL或文本），但凡需要带 scene 参数的小程序码，就必须走微信服务端接口——这事儿没得商量，是平台的硬性限制，绕不过去。

很多刚接触 uni-app 的同学会纳闷：为什么不能在前端直接调接口生成带参数的小程序码？其实原因很简单：微信明确禁止前端调用 /wxa/getwxacodeunlimit 这类接口。因为调用这些接口需要 appid 和 secret，这两者必须严格保密，而且请求还得携带合法的 access_token。如果你在前端暴露密钥，后果可是账号被盗、小程序被封，完全得不偿失。

顺便澄清几个容易混淆的概念：

• 你在 H5 或 App 端看到的“扫码跳小程序”，本质上跳的是 https://wxaurl.cn/xxx 这类短链，不是真正的小程序码
• 真正的小程序码（太阳码/二维码）包含加密签名，微信只允许服务端生成，返回的要么是 base64，要么是文件流
• uni-app 提供的 uni.na vigateToMiniProgram 是用于跳转到已安装的小程序，跟生成码压根是两码事

为什么不能在小程序前端直接生成带参数的小程序码

这个话题值得展开说说。微信这么设计，核心是安全考量：scene 参数里通常携带着用户身份、渠道来源等敏感信息，如果前端能直接生成，那参数暴露的风险就太大了。所以，你必须把生成逻辑放在服务端，让后端拿着 appid 和 secret 去请求微信接口，拿到结果后再返回给前端。这是硬性规则，没有讨价还价的余地。

前端能做的唯一可靠路径：调后端 API 拿 base64

既然前端不能直接生成，那唯一靠谱的做法就是：前端发请求给后端，后端调用微信接口生成小程序码，再返回 base64 字符串，你直接赋值给 就能显示了。听起来简单，但有几个关键点需要注意：

• 后端请求微信接口时，必须用 responseType: 'arraybuffer' 来接收，然后用 Buffer.from(res.data).toString('base64') 转成 base64 字符串
• 前端传参要灵活，比如传 { uid: this.userId, channel: 'share' }，后端把这些拼进 scene 字段——注意，scene 最多只能 32 个可见字符，别超了
• 如果参数太长，比如带 token 的完整路径，后端最好先存入数据库或缓存，用短 ID 作 scene，等用户扫码后再重定向到实际路径
• 前端拿到 base64 后，直接传给 组件就行——uni-app 原生支持 base64，不需要手动拼接 data:image/png;base64,... 前缀

普通二维码（非小程序码）可用 uqrcodejs 快速生成

如果你的业务场景不需要小程序码，只需要生成普通二维码（比如分享活动页、电子名片，扫出来跳 H5 页面或展示文本），那用 uqrcodejs 就足够了，而且它在三端（H5、小程序、App）表现一致。不过这里有几个坑要提前避开：

• 安装时注意包名：必须是 npm install uqrcodejs --sa ve，别搞成 uQRCode 或 qrcode，不然后面各种报错
• 导入语法要正确：import uQRCode from 'uqrcodejs'，它是 ESM 导出，不支持 require
• 如果内容包含中文，一定要提前 encodeURIComponent()，否则在 H5 端扫码跳转会乱码
• text 参数只接受字符串，如果传对象，记得自己 JSON.stringify()，不然会输出 [object Object]
• 生成时机要卡在 onReady 或 $nextTick，否则 canvas 元素还没挂载，必然失败

容易被忽略的细节：尺寸、白边与容错率

很多人设了 width: 200 却扫不出来，就开始怀疑内容太长。其实问题多半出在参数设置上，跟内容长度关系不大：

• width 是最终画布的宽高（px），而 size 才是每个模块的像素大小。默认 size: 4 在 200px 下模块太密，推荐 width: 280, size: 6
• margin 别设为 0，至少留 4px 白边，否则部分扫码器（尤其是微信内置的）会识别失败
• 容错等级必须设为 errorCorrectLevel: 'H'，特别是内容里大小写字母和数字混合时，高容错率能保证扫码不会翻车
• 注意返回值类型：小程序端返回的是 tempFilePath，H5 端返回的是 base64，但两者都能直接塞进 ，不用额外处理