小工具可以解决大问题。在软件发布流程中，最尴尬的事情莫过于：宣传图已经发出去了，用户扫码后却发现链接打不开，或者下载了一个旧版本的安装包。

我就亲身经历过这么一次“翻车”事故。

事故现场：一个 URL 引起的麻烦

有一次，我在更新软件下载页面后，由于换了一个新的 URL 地址，在生成二维码阶段没有进行严格校验，就直接把二维码发布了出去。

结果当用户兴冲冲地扫码下载时，发现软件运行异常。我对比了半天才发现，生成二维码时填写的 URL 链接版本号写错了一个字符，导致用户下载到了一个有问题的版本，这是偶然中的极端。

虽然这只是一个低级错误，但它让我意识到：在二维码挂载后、正式发布前，必须有一个极简的“内容鉴定”环节。

痛点：如何快速、无痛地校验？

通常我们校验二维码，习惯性地直接拿手机扫一下。但如果二维码指向的是一个大容量的 APP 下载包或复杂的跳转链接，扫码后手机会自动触发下载或进入复杂的网页路径。

我其实并不想真的下载并安装测试（那是后续的 QA 环节），我只是想一眼看到二维码里到底写了什么字符，确定那个 URL 是不是我想要的那一个。

实现：借力小程序的原生能力

既然发现了痛点，解决起来就非常顺手了。得益于微信生态对扫码的深度支持，我在“豆子工具”里实现了一个“二维码识别”功能：

  • 核心逻辑：直接调用小程序的 wx.scanCode 接口。
  • 功能表现：不仅支持扫描实物二维码，还支持从手机相册里直接读取生成的二维码图片，还支持小程序码扫描，支持查看页面路径和scene值。
  • 结果反馈：系统不会触发自动跳转，而是将二维码包含的原始文本、URL、一维码内容直接以纯文本的形式展示在屏幕上。

价值：多看一眼，少出一次错

现在，每当我生成一个新的二维码，无论是用于软件下载、文档分享还是活动跳转，我都会习惯性地用自己的工具“扫一下”：

  1. 确认 URL 参数是否完整。
  2. 确认是否有肉眼难以察觉的拼写错误。
  3. 确认二维码的类型（一维码还是二维码）是否符合预期。

识别二维码

技术实现

使用小程序纯原生实现，仅仅做一个页面展示即可。

scanQRCode: function () {
        const that = this;
        wx.showLoading({
            title: '识别中...',
            mask: true,
        })
        wx.scanCode({
            onlyFromCamera: false,
            scanType: ['qrCode', 'barCode', 'datamatrix', 'pdf417', 'wxCode'],
            success: (res) => {
                wx.hideLoading()
                if(res.scanType=='WX_CODE'){
                    that.setData({
                        scanResult: res.path
                    });
                }else{
                    that.setData({
                        scanResult: res.result
                    });
                }
            },
            fail: (err) => {
                wx.hideLoading()
                console.error(err);
            }
        });
    },

需要注意的是，小程序码和其它码的结果字段有点不同，所以需要区分，以便取到正确的值。

总结

这个功能的代码实现极其简单，几乎就是调用一个 API 的事。但它的价值在于改变了工作流——在发布前的最后关头，提供了一个低成本的“人工校验点”。

很多时候，工具的作用不仅仅是自动化，更是为了在我们疏忽大意时，拉我们一把。