微信小程序里做扫码功能大多数人第一反应就是wx.scanCode调一次弹一次原生扫码界面扫完拿到结果再调一次。这个方案在扫一次记一笔的场景里够用但只要业务变成连续扫、一口气扫几十上百个它立刻就崩了——每扫一个码就要重新拉起一次全屏界面中间那两秒的等待和界面跳转对仓库盘点、门店理货、快递分拣这种场景来说完全是折磨。我在给一个做仓储盘点的小工具做迭代时就硬生生被这个问题折腾了一周最后落到camera组件的modescan上才算彻底解决。这篇就把连续扫码从选型、实现、去重、生命周期管理到真机适配的完整链路拆开讲代码可以直接抄踩过的坑也一并标出来。1. 连续扫码的真实业务场景与它比单次扫码难在哪先把场景对齐不然很容易做成一个看起来很酷但没人用的demo。连续扫码的核心诉求通常有三类第一类是批量录入比如仓库盘点时手持设备绕货架走一圈把每个货位码都扫进去第二类是流水作业校验比如快递分拣线上把包裹码一个个过一遍跟系统里的清单做比对第三类是临时收集比如活动签到、物料清点这种一次性任务。这三类的共同点是人不愿意停下来等界面手要一直举着眼睛要一直盯着屏幕任何一次界面跳转都是在打断这个动作节奏。1.1 为什么wx.scanCode撑不起连续扫码wx.scanCode的定位是一次性调用它的行为链路是固定死的调用后关闭当前页面视图、拉起微信原生的扫码全屏页、用户对准码、识别成功后原生页关闭、回调返回结果、再回到你自己的页面。也就是说整套动作里包含了页面栈的切换和相机资源的反复申请与释放。我实测下来一次wx.scanCode从调用到回调稳定在800毫秒到2秒之间机型越老越慢冷启动相机的那一次甚至能到3秒。问题不只是慢还有状态丢失。因为原生扫码页是独立页面你自己页面上维护的已扫清单当前批次剩余待扫数量这些状态在视觉上是断开的用户扫完一个码回到页面需要0.5秒左右重新建立视觉上下文才能确认刚才那个扫进去了没有。连续扫十几个码这个认知负担会累积得非常明显。更麻烦的是错误处理——如果某个码识别失败或者是个重复码你只能靠 toast 提示而 toast 出现的时候用户可能已经抬手对准下一个码了反馈严重滞后。提示wx.scanCode并不是不能用它是低频、重量级、需要微信原生识别能力兜底的场景比如扫一个付款码、扫一个不常见的条码。核心区别在于调用频率。1.2camera组件原生扫码模式的两个关键参数替代方案就是camera组件它本身支持一个内置的扫码模式。这里有两个参数是决定性的很多人第一次用会漏掉第一个是modescan。camera组件默认是modenormal也就是只做预览不做识别。只有把它设成scan组件内部才会启动持续识别逻辑并通过bindscancode事件把识别结果持续抛给你。注意这个持续的含义——只要相机画面里存在可识别的码它就会周期性触发bindscancode而不是只触发一次。这一点非常关键后面去重章节会重点讲。第二个是flash属性取值off、torch、auto。连续扫码经常在光线不足的仓库角落或者货架背光面进行手电筒几乎是刚需。torch是常亮模式auto是自动补光我一般用torch配合一个手动开关按钮把控制权交给用户因为auto在某些机型的判断逻辑很迷该亮的时候不亮。camera modescan device-positionback flash{{torchOn ? torch : off}} resolutionhigh binderroronCameraError bindscancodeonScanCode stylewidth:100%;height:100% /cameraresolution我建议设成high。默认是medium在扫小尺寸二维码比如贴在螺丝上的那种时识别率会明显下降。代价是功耗更高、发热更快这个取舍后面在性能章节再展开。1.3 先想清楚你的业务到底是谁扫谁在写代码之前有一个容易被忽略的判断扫的是二维码还是条形码。这两者的识别难度完全不同。二维码信息密度高、容错强对角度和距离的容忍度大条形码尤其是 EAN-13、Code128对水平角度和光照非常敏感稍微歪一点或者反光就识别不出来。如果你的业务要扫条形码那在UI上必须给用户明确的引导——一条水平对准线而不是通用的方框扫描框。还有一个判断是码是静止的还是移动的。盘点场景码是贴在货架上的静止理论上识别压力小但分拣线上的包裹是移动的相机要连续抓帧识别对曝光和对焦速度要求很高。后者我一般会建议把resolution降到medium换取更高的帧率因为运动模糊比分辨率更影响识别。2. 用一个最小可用示例跑通 camera 连续扫码概念讲完了直接上能跑的东西。我用的是原生小程序写法非 uniapp思路在 uniapp 里完全一样只是标签大小写要注意。2.1 WXML 结构相机层与遮罩层的叠加关系这里最容易出问题的是布局。camera组件必须是一个有明确宽高的原生组件否则不渲染。常见做法是用一个铺满屏幕的容器相机占满遮罩用cover-view叠在上面——注意必须是cover-view普通view在部分机型上会被相机的原生层级盖住。view classscan-page camera classcamera modescan device-positionback flash{{torchOn ? torch : off}} resolutionhigh binderroronCameraError bindscancodeonScanCode /camera cover-view classoverlay cover-view classscan-box/cover-view cover-view classtips{{tips}}/cover-view /cover-view view classbottom-bar button sizemini bindtaptoggleTorch {{torchOn ? 关闭补光 : 打开补光}} /button view classcounter已扫{{list.length}}/view button sizemini bindtapfinish完成/button /view /view.camera我给的是width:100%; height:100%; position:absolute; top:0; left:0overlay也是绝对定位铺满pointer-events:none避免挡住下面的按钮cover-view的层级处理和普通元素不同这个坑后面章节细说。2.2 JS 核心逻辑onScanCode回调里到底该做什么回调本身很简单难的是该做什么、不该做什么。我的原则是回调里只做轻量操作任何耗时逻辑都异步化。因为bindscancode是高频触发的事件你在回调里做setData大量数据、做网络请求、做复杂计算都会阻塞相机线程直接表现为画面卡顿甚至黑屏。Page({ data: { torchOn: false, tips: 对准二维码即可自动识别, list: [], lastCode: , lastTime: 0 }, onScanCode(e) { const code e.detail.result if (!code) return const now Date.now() // 冷却时间内的重复码直接丢弃 if (code this.data.lastCode now - this.data.lastTime 1500) { return } this.setData({ lastCode: code, lastTime: now }) // 震动反馈让用户不用看屏幕也知道扫上了 wx.vibrateShort({ type: medium }) this.commitResult(code) }, commitResult(code) { const list this.data.list // 全局去重如果业务不允许重复码 if (list.some(item item.code code)) { wx.showToast({ title: 该码已扫描, icon: none, duration: 800 }) return } list.unshift({ code, time: Date.now() }) this.setData({ list }) } })这里有两个层次的点需要说清楚。第一层是lastCode lastTime这个组合它解决的是同一个码在短时间内被反复触发的问题这是modescan的必然行为不是 bug。第二层是list.some()的全局去重它解决的是业务层面的重复两者作用不同不能互相替代。2.3 权限、隐私协议与真机调试的前置条件camera组件需要用户授权scope.camera。如果用户之前拒绝过你直接渲染相机是拿不到画面的必须先用wx.getSetting检查再决定是否走wx.authorize或者打开设置页引导。这段逻辑建议放在onLoad里并且要处理授权后回到页面这个场景。onLoad() { wx.getSetting({ success: (res) { if (res.authSetting[scope.camera] false) { wx.showModal({ title: 需要相机权限, content: 请在设置中开启相机权限后继续扫码, confirmText: 去设置, success: (r) { if (r.confirm) wx.openSetting() } }) } } }) }还有一个2023年之后越来越容易踩的坑隐私协议。小程序如果涉及相机等敏感接口需要在后台配置《小程序用户隐私保护指引》并且在代码里调用wx.requirePrivacyAuthorize或者在app.json里正确声明。没配的话开发者工具里可能能跑真机上直接报错拿不到相机权限而且报错信息非常隐晦。我在这上面浪费了整整半天最后是翻官方文档才定位到。3. 扫码去重连续扫码里最容易翻车的一环去重这件事表面上是判断字符串相等实际上要考虑的维度比想象的多。我见过好几个项目的连续扫码功能最后败在去重逻辑上——要么扫一次入三条要么合法的重复码被误杀。3.1 为什么同一张码会被连续触发十几遍理解这一点要从modescan的机制说起。相机是连续采集画面的识别引擎每隔一个很短的时间间隔大致在几十到几百毫秒就会尝试识别一次当前帧。只要你把手机对准那张码并且不动每一帧里都存在这个码识别引擎就会每一帧都通知你一次结果。所以你会看到bindscancode疯狂触发同一个result连续抛上来十几次。这不是识别错误是设计如此。如果不去重你的list会在两秒内被同一个码塞满。所以去重不是优化是功能正确性的前提。3.2 时间窗口去重与内容哈希去重的取舍去重有两条主流路线我一般会组合使用去重方式实现方式优点缺点适用场景时间窗口去重记录上次码上次时间窗口内相同码丢弃实现简单、开销极小无法区分真的扫了两次和重复触发单次物理扫描内容集合去重维护已扫码的 Set重复直接丢严格保证唯一内存随数量增长且合法重复码被误杀清单核对视觉位移去重结合设备加速度/位置变化判断是否换了码最接近人类直觉实现复杂、机型差异大高精度场景实际项目里我的默认组合是时间窗口去重1500ms兜住高频触发内容集合去重兜住业务唯一性。如果业务允许同一个码扫多次比如一批货物里有两个相同料号那就把内容集合去重关掉只留时间窗口同时在UI上给用户一个允许重复的开关。注意时间窗口别设太大。设成 3000ms 的话用户扫完一个码立刻扫下一张如果两张码内容恰好相同比如连续两箱同型号货物第二箱就会被吃掉。1500ms 是我实测下来手感最平衡的值。3.3 一个可直接抄的去重 冷却实现把上面的思路写成可复用的模块我用一个小类来管理避免页面data里堆一堆散装变量class ScanDeduper { constructor(cooldown 1500) { this.cooldown cooldown this.lastCode this.lastTime 0 this.seen new Set() } // 返回 true 表示这个码应该被接受 accept(code, allowRepeat false) { const now Date.now() if (code this.lastCode now - this.lastTime this.cooldown) { return false } if (!allowRepeat this.seen.has(code)) { return false } this.lastCode code this.lastTime now this.seen.add(code) return true } reset() { this.lastCode this.lastTime 0 this.seen.clear() } }用的时候在页面里挂一个实例回调里第一行就if (!this.deduper.accept(code)) return。注意accept的第二个参数allowRepeat它让去重策略可以按业务动态切换不用改代码逻辑。reset用于开始新一批扫描时清空状态这个在下游业务闭环里很重要。4. 手电筒、相机暂停与页面生命周期的配合相机是个系统级资源谁抢到谁用。这个特性决定了连续扫码页面必须在生命周期上做严格管理否则会出现跳到别的页面相机还亮着返回后黑屏切后台耗电到爆这些经典问题。4.1 手电筒开关与对焦模式的实操细节手电筒开关本身很简单绑一个布尔值到flash就行。但有两个细节第一flash的切换有短暂延迟连续快速点按可能不生效我一般会在按钮上做300ms的防抖第二flashtorch在部分机型上要求相机已经完成初始化页面刚进来立刻设置可能丢失所以初始值建议给off等用户主动开。对焦模式camera组件没有直接暴露但有一点可以间接改善识别率让用户不要贴太近。手机相机的对焦距离一般在10cm以上很多用户习惯把手机怼到码上反而对不上焦。我在UI上加了一句引导文案距离20-30厘米识别更快实际识别率提升很明显。4.2 onHide/onShow 里必须做的三件事连续扫码页面切后台或者跳转其他页面时相机不会自动关你必须手动处理。我总结下来是三件事onHide 时用一个标志位把相机停掉。小程序没有直接销毁camera组件的API常用做法是用wx.createCameraContext().stopRecord()这类方式不适用实际最稳妥的是通过条件渲染把camera节点移除或者用一个覆盖全屏的占位层 把mode切回normal。onShow 时重新检查权限并恢复相机。因为用户可能在设置页改了权限再回来。onUnload 时清理定时器和去重器实例避免内存泄漏。onHide() { // 关掉手电筒避免切后台还亮着 this.setData({ torchOn: false, cameraAlive: false }) }, onShow() { this.setData({ cameraAlive: true }) wx.getSetting({ success: (res) { if (res.authSetting[scope.camera] false) { wx.showToast({ title: 相机权限已关闭, icon: none }) } } }) }, onUnload() { if (this.timer) clearInterval(this.timer) this.deduper this.deduper.reset() }配合 WXML 里用wx:if{{cameraAlive}}包住camera切后台时会真的把相机节点卸载掉。实测这个方案比只调stopRecord更彻底能明显降低后台耗电。4.3 遮罩扫描线与 UI 反馈的轻量实现连续扫码的UI反馈不能太重否则用户眼睛累。我的经验是三样东西就够一个静态的扫描框告诉用户大致的对准区域、一个扫码成功时闪一下的绿色边框、以及震动反馈。扫描线动画说实话在连续扫码场景里帮助不大反而因为动画一直动用户会以为没识别到是在等动画产生误导。.scan-box { width: 480rpx; height: 480rpx; border: 4rpx solid rgba(255,255,255,0.7); border-radius: 16rpx; transition: border-color 0.15s; } .scan-box.success { border-color: #07c160; }扫码成功时通过setData给扫描框加上success类200ms后去掉。这个闪一下绿的反馈配合震动是连续扫码里性价比最高的交互设计。5. 连续扫码的性能、发热与机型兼容问题排查连续扫码一旦持续时间超过几分钟性能和发热问题就会暴露出来而且不同机型表现差异巨大。这部分是我踩坑最多的地方整理成一个排查链路。5.1 iOS 与 Android 的表现差异实测维度iOSAndroid识别速度快稳定中高端快低端明显慢相机初始化快首次慢可能达2-3秒长时间发热明显5分钟后开始降帧更明显部分机型10分钟烫手黑屏概率低中低端机型较高手电筒响应快偶尔延迟或失效iOS 整体更稳但在长时间连续扫码时也会有降帧现象——系统为了保护电池会主动降低相机采集帧率表现是识别变慢。Android 的问题更集中在相机权限被其他应用抢占上比如用户突然接到电话、切到相机APP回来时你的扫码页可能就黑屏了需要在onShow里做恢复逻辑。5.2 长时间连续扫码的降耗思路如果要连续扫十几分钟得主动做降耗。我的做法有三条第一降分辨率。把resolution从high降到medium功耗能降一截代价是识别率略降。可以做成动态连续扫码超过5分钟后自动降级用户感知不明显。第二降低 UI 刷新频率。setData是整个小程序里最贵的操作之一。扫码回调里如果每次成功都setData整个 list连续扫几百个之后性能会雪崩。我的做法是本地数组维护全量数据setData只更新展示需要的最近几条或者用一个单独的displayCount控制展示条数。第三用节流控制回调处理频率。虽然识别本身不归你控制但你可以控制自己处理结果的频率。加一个最小处理间隔比如100ms内的事件直接忽略。// 简单的节流 onScanCode(e) { const now Date.now() if (now - this._lastHandle 100) return this._lastHandle now // ... 后续处理 }提示setData的数据量超过几十KB时在中低端 Android 上会有肉眼可见的卡顿。连续扫码的列表千万不要全量setData。5.3 识别率低的排查链路识别率低是个综合问题我一般按这个顺序排查从最容易的先来光照——是不是背光或者反光手电筒能不能解决距离——用户是不是贴太近了引导文案有没有码本身——码是否破损、褶皱、分辨率太低打印得太小这是硬伤技术解决不了。分辨率设置——resolution是不是medium小码必须high。镜头脏污——听起来离谱但真遇到过用户镜头有油污导致整体模糊。识别算法差异——微信的扫码引擎在不同基础库版本里有差异更新基础库有时能解决。我遇到过一次特别诡异的同一张码A手机秒识B手机死活识别不了。最后发现是 B 手机的相机对焦坏了物理问题换台机器立刻正常。所以排查时要换机器验证别一条道走到黑。6. 从扫码到业务闭环批量入库、离线缓存与容错扫码只是入口真正的价值在扫完之后的数据怎么处理。这部分决定了你的功能是玩具还是工具。6.1 扫码结果本地队列与批量提交连续扫几十上百个码绝对不能每扫一个就发一次网络请求。一是网络开销巨大二是任何一个请求失败都会打断扫码节奏。正确做法是本地队列 批量提交。我的设计是扫码结果先进本地数组页面上实时展示用户点完成或者队列达到一定数量比如50条时一次性提交。async submitBatch() { const list this.data.list if (!list.length) return wx.showLoading({ title: 提交中 }) try { const res await wx.request({ url: https://yourdomain.com/api/batch, method: POST, data: { items: list.map(i i.code) } }) if (res.data.code 0) { this.setData({ list: [] }) this.deduper.reset() wx.showToast({ title: 提交成功 }) } } catch (e) { // 失败不清空让用户重试 wx.showToast({ title: 提交失败请重试, icon: none }) } finally { wx.hideLoading() } }关键点是失败时不清空本地数据。网络抖动太常见了清空等于让用户白扫一遍这是绝对不能接受的体验。6.2 网络抖动时的重试与幂等批量提交必须考虑幂等。用户点了提交服务端处理成功了但响应超时你这边报失败用户再点一次——如果服务端不做幂等数据就重复了。做法是每次批次生成一个唯一batchId比如时间戳随机串服务端根据batchId去重。const batchId ${Date.now()}_${Math.random().toString(36).slice(2, 8)}这个batchId在重试时要保持不变所以它应该是批次的一部分存在页面状态里提交成功后重置。6.3 一个仓储盘点场景的完整闭环把前面所有东西串起来一个完整的盘点流程是这样的用户进入扫码页检查相机权限渲染相机初始化去重器。对着货位码扫每扫一个去重器判断 - 通过则震动 闪绿 加入本地列表 更新展示。用户随时可以开手电筒应对暗环境。扫完一批点提交带上batchId批量提交到服务端。提交成功清空本地队列、重置去重器失败保留数据提示重试重试时复用同一个batchId。页面切后台时关闭相机节点和手电筒回来时恢复。这套闭环我在实际项目里跑下来一个人盘点一个中等仓库大约300个货位的时间从原来的40多分钟压到了10分钟左右主要省下来的就是每扫一次等界面的时间。识别率方面二维码在正常光照下基本是对准就出条形码则需要多试几次这个后面如果业务允许我会建议把货位标识从条形码换成二维码一步到位。我个人在实际操作中的体会是连续扫码这个功能技术难度不在怎么扫而在扫完之后的一堆状态怎么管——去重、生命周期、批量提交、失败重试每一环都容易出问题而且都是那种不真机长时间跑就发现不了的问题。建议想做的同学先别急着写业务逻辑用一个最少代码的 demo 在真机上连续扫200个码把上面这些坑先踩一遍心里就有数了。如果你们的场景还需要支持离线扫码无网络环境下先存本地联网后再同步那又是另一个话题我在盘点工具里是用本地存储做了一层缓存队列感兴趣的话可以顺着这个思路往下挖。
微信小程序里做扫码功能大多数人第一反应就是wx.scanCode调一次弹一次原生扫码界面扫完拿到结果再调一次。这个方案在扫一次记一笔的场景里够用但只要业务变成连续扫、一口气扫几十上百个它立刻就崩了——每扫一个码就要重新拉起一次全屏界面中间那两秒的等待和界面跳转对仓库盘点、门店理货、快递分拣这种场景来说完全是折磨。我在给一个做仓储盘点的小工具做迭代时就硬生生被这个问题折腾了一周最后落到camera组件的modescan上才算彻底解决。这篇就把连续扫码从选型、实现、去重、生命周期管理到真机适配的完整链路拆开讲代码可以直接抄踩过的坑也一并标出来。1. 连续扫码的真实业务场景与它比单次扫码难在哪先把场景对齐不然很容易做成一个看起来很酷但没人用的demo。连续扫码的核心诉求通常有三类第一类是批量录入比如仓库盘点时手持设备绕货架走一圈把每个货位码都扫进去第二类是流水作业校验比如快递分拣线上把包裹码一个个过一遍跟系统里的清单做比对第三类是临时收集比如活动签到、物料清点这种一次性任务。这三类的共同点是人不愿意停下来等界面手要一直举着眼睛要一直盯着屏幕任何一次界面跳转都是在打断这个动作节奏。1.1 为什么wx.scanCode撑不起连续扫码wx.scanCode的定位是一次性调用它的行为链路是固定死的调用后关闭当前页面视图、拉起微信原生的扫码全屏页、用户对准码、识别成功后原生页关闭、回调返回结果、再回到你自己的页面。也就是说整套动作里包含了页面栈的切换和相机资源的反复申请与释放。我实测下来一次wx.scanCode从调用到回调稳定在800毫秒到2秒之间机型越老越慢冷启动相机的那一次甚至能到3秒。问题不只是慢还有状态丢失。因为原生扫码页是独立页面你自己页面上维护的已扫清单当前批次剩余待扫数量这些状态在视觉上是断开的用户扫完一个码回到页面需要0.5秒左右重新建立视觉上下文才能确认刚才那个扫进去了没有。连续扫十几个码这个认知负担会累积得非常明显。更麻烦的是错误处理——如果某个码识别失败或者是个重复码你只能靠 toast 提示而 toast 出现的时候用户可能已经抬手对准下一个码了反馈严重滞后。提示wx.scanCode并不是不能用它是低频、重量级、需要微信原生识别能力兜底的场景比如扫一个付款码、扫一个不常见的条码。核心区别在于调用频率。1.2camera组件原生扫码模式的两个关键参数替代方案就是camera组件它本身支持一个内置的扫码模式。这里有两个参数是决定性的很多人第一次用会漏掉第一个是modescan。camera组件默认是modenormal也就是只做预览不做识别。只有把它设成scan组件内部才会启动持续识别逻辑并通过bindscancode事件把识别结果持续抛给你。注意这个持续的含义——只要相机画面里存在可识别的码它就会周期性触发bindscancode而不是只触发一次。这一点非常关键后面去重章节会重点讲。第二个是flash属性取值off、torch、auto。连续扫码经常在光线不足的仓库角落或者货架背光面进行手电筒几乎是刚需。torch是常亮模式auto是自动补光我一般用torch配合一个手动开关按钮把控制权交给用户因为auto在某些机型的判断逻辑很迷该亮的时候不亮。camera modescan device-positionback flash{{torchOn ? torch : off}} resolutionhigh binderroronCameraError bindscancodeonScanCode stylewidth:100%;height:100% /cameraresolution我建议设成high。默认是medium在扫小尺寸二维码比如贴在螺丝上的那种时识别率会明显下降。代价是功耗更高、发热更快这个取舍后面在性能章节再展开。1.3 先想清楚你的业务到底是谁扫谁在写代码之前有一个容易被忽略的判断扫的是二维码还是条形码。这两者的识别难度完全不同。二维码信息密度高、容错强对角度和距离的容忍度大条形码尤其是 EAN-13、Code128对水平角度和光照非常敏感稍微歪一点或者反光就识别不出来。如果你的业务要扫条形码那在UI上必须给用户明确的引导——一条水平对准线而不是通用的方框扫描框。还有一个判断是码是静止的还是移动的。盘点场景码是贴在货架上的静止理论上识别压力小但分拣线上的包裹是移动的相机要连续抓帧识别对曝光和对焦速度要求很高。后者我一般会建议把resolution降到medium换取更高的帧率因为运动模糊比分辨率更影响识别。2. 用一个最小可用示例跑通 camera 连续扫码概念讲完了直接上能跑的东西。我用的是原生小程序写法非 uniapp思路在 uniapp 里完全一样只是标签大小写要注意。2.1 WXML 结构相机层与遮罩层的叠加关系这里最容易出问题的是布局。camera组件必须是一个有明确宽高的原生组件否则不渲染。常见做法是用一个铺满屏幕的容器相机占满遮罩用cover-view叠在上面——注意必须是cover-view普通view在部分机型上会被相机的原生层级盖住。view classscan-page camera classcamera modescan device-positionback flash{{torchOn ? torch : off}} resolutionhigh binderroronCameraError bindscancodeonScanCode /camera cover-view classoverlay cover-view classscan-box/cover-view cover-view classtips{{tips}}/cover-view /cover-view view classbottom-bar button sizemini bindtaptoggleTorch {{torchOn ? 关闭补光 : 打开补光}} /button view classcounter已扫{{list.length}}/view button sizemini bindtapfinish完成/button /view /view.camera我给的是width:100%; height:100%; position:absolute; top:0; left:0overlay也是绝对定位铺满pointer-events:none避免挡住下面的按钮cover-view的层级处理和普通元素不同这个坑后面章节细说。2.2 JS 核心逻辑onScanCode回调里到底该做什么回调本身很简单难的是该做什么、不该做什么。我的原则是回调里只做轻量操作任何耗时逻辑都异步化。因为bindscancode是高频触发的事件你在回调里做setData大量数据、做网络请求、做复杂计算都会阻塞相机线程直接表现为画面卡顿甚至黑屏。Page({ data: { torchOn: false, tips: 对准二维码即可自动识别, list: [], lastCode: , lastTime: 0 }, onScanCode(e) { const code e.detail.result if (!code) return const now Date.now() // 冷却时间内的重复码直接丢弃 if (code this.data.lastCode now - this.data.lastTime 1500) { return } this.setData({ lastCode: code, lastTime: now }) // 震动反馈让用户不用看屏幕也知道扫上了 wx.vibrateShort({ type: medium }) this.commitResult(code) }, commitResult(code) { const list this.data.list // 全局去重如果业务不允许重复码 if (list.some(item item.code code)) { wx.showToast({ title: 该码已扫描, icon: none, duration: 800 }) return } list.unshift({ code, time: Date.now() }) this.setData({ list }) } })这里有两个层次的点需要说清楚。第一层是lastCode lastTime这个组合它解决的是同一个码在短时间内被反复触发的问题这是modescan的必然行为不是 bug。第二层是list.some()的全局去重它解决的是业务层面的重复两者作用不同不能互相替代。2.3 权限、隐私协议与真机调试的前置条件camera组件需要用户授权scope.camera。如果用户之前拒绝过你直接渲染相机是拿不到画面的必须先用wx.getSetting检查再决定是否走wx.authorize或者打开设置页引导。这段逻辑建议放在onLoad里并且要处理授权后回到页面这个场景。onLoad() { wx.getSetting({ success: (res) { if (res.authSetting[scope.camera] false) { wx.showModal({ title: 需要相机权限, content: 请在设置中开启相机权限后继续扫码, confirmText: 去设置, success: (r) { if (r.confirm) wx.openSetting() } }) } } }) }还有一个2023年之后越来越容易踩的坑隐私协议。小程序如果涉及相机等敏感接口需要在后台配置《小程序用户隐私保护指引》并且在代码里调用wx.requirePrivacyAuthorize或者在app.json里正确声明。没配的话开发者工具里可能能跑真机上直接报错拿不到相机权限而且报错信息非常隐晦。我在这上面浪费了整整半天最后是翻官方文档才定位到。3. 扫码去重连续扫码里最容易翻车的一环去重这件事表面上是判断字符串相等实际上要考虑的维度比想象的多。我见过好几个项目的连续扫码功能最后败在去重逻辑上——要么扫一次入三条要么合法的重复码被误杀。3.1 为什么同一张码会被连续触发十几遍理解这一点要从modescan的机制说起。相机是连续采集画面的识别引擎每隔一个很短的时间间隔大致在几十到几百毫秒就会尝试识别一次当前帧。只要你把手机对准那张码并且不动每一帧里都存在这个码识别引擎就会每一帧都通知你一次结果。所以你会看到bindscancode疯狂触发同一个result连续抛上来十几次。这不是识别错误是设计如此。如果不去重你的list会在两秒内被同一个码塞满。所以去重不是优化是功能正确性的前提。3.2 时间窗口去重与内容哈希去重的取舍去重有两条主流路线我一般会组合使用去重方式实现方式优点缺点适用场景时间窗口去重记录上次码上次时间窗口内相同码丢弃实现简单、开销极小无法区分真的扫了两次和重复触发单次物理扫描内容集合去重维护已扫码的 Set重复直接丢严格保证唯一内存随数量增长且合法重复码被误杀清单核对视觉位移去重结合设备加速度/位置变化判断是否换了码最接近人类直觉实现复杂、机型差异大高精度场景实际项目里我的默认组合是时间窗口去重1500ms兜住高频触发内容集合去重兜住业务唯一性。如果业务允许同一个码扫多次比如一批货物里有两个相同料号那就把内容集合去重关掉只留时间窗口同时在UI上给用户一个允许重复的开关。注意时间窗口别设太大。设成 3000ms 的话用户扫完一个码立刻扫下一张如果两张码内容恰好相同比如连续两箱同型号货物第二箱就会被吃掉。1500ms 是我实测下来手感最平衡的值。3.3 一个可直接抄的去重 冷却实现把上面的思路写成可复用的模块我用一个小类来管理避免页面data里堆一堆散装变量class ScanDeduper { constructor(cooldown 1500) { this.cooldown cooldown this.lastCode this.lastTime 0 this.seen new Set() } // 返回 true 表示这个码应该被接受 accept(code, allowRepeat false) { const now Date.now() if (code this.lastCode now - this.lastTime this.cooldown) { return false } if (!allowRepeat this.seen.has(code)) { return false } this.lastCode code this.lastTime now this.seen.add(code) return true } reset() { this.lastCode this.lastTime 0 this.seen.clear() } }用的时候在页面里挂一个实例回调里第一行就if (!this.deduper.accept(code)) return。注意accept的第二个参数allowRepeat它让去重策略可以按业务动态切换不用改代码逻辑。reset用于开始新一批扫描时清空状态这个在下游业务闭环里很重要。4. 手电筒、相机暂停与页面生命周期的配合相机是个系统级资源谁抢到谁用。这个特性决定了连续扫码页面必须在生命周期上做严格管理否则会出现跳到别的页面相机还亮着返回后黑屏切后台耗电到爆这些经典问题。4.1 手电筒开关与对焦模式的实操细节手电筒开关本身很简单绑一个布尔值到flash就行。但有两个细节第一flash的切换有短暂延迟连续快速点按可能不生效我一般会在按钮上做300ms的防抖第二flashtorch在部分机型上要求相机已经完成初始化页面刚进来立刻设置可能丢失所以初始值建议给off等用户主动开。对焦模式camera组件没有直接暴露但有一点可以间接改善识别率让用户不要贴太近。手机相机的对焦距离一般在10cm以上很多用户习惯把手机怼到码上反而对不上焦。我在UI上加了一句引导文案距离20-30厘米识别更快实际识别率提升很明显。4.2 onHide/onShow 里必须做的三件事连续扫码页面切后台或者跳转其他页面时相机不会自动关你必须手动处理。我总结下来是三件事onHide 时用一个标志位把相机停掉。小程序没有直接销毁camera组件的API常用做法是用wx.createCameraContext().stopRecord()这类方式不适用实际最稳妥的是通过条件渲染把camera节点移除或者用一个覆盖全屏的占位层 把mode切回normal。onShow 时重新检查权限并恢复相机。因为用户可能在设置页改了权限再回来。onUnload 时清理定时器和去重器实例避免内存泄漏。onHide() { // 关掉手电筒避免切后台还亮着 this.setData({ torchOn: false, cameraAlive: false }) }, onShow() { this.setData({ cameraAlive: true }) wx.getSetting({ success: (res) { if (res.authSetting[scope.camera] false) { wx.showToast({ title: 相机权限已关闭, icon: none }) } } }) }, onUnload() { if (this.timer) clearInterval(this.timer) this.deduper this.deduper.reset() }配合 WXML 里用wx:if{{cameraAlive}}包住camera切后台时会真的把相机节点卸载掉。实测这个方案比只调stopRecord更彻底能明显降低后台耗电。4.3 遮罩扫描线与 UI 反馈的轻量实现连续扫码的UI反馈不能太重否则用户眼睛累。我的经验是三样东西就够一个静态的扫描框告诉用户大致的对准区域、一个扫码成功时闪一下的绿色边框、以及震动反馈。扫描线动画说实话在连续扫码场景里帮助不大反而因为动画一直动用户会以为没识别到是在等动画产生误导。.scan-box { width: 480rpx; height: 480rpx; border: 4rpx solid rgba(255,255,255,0.7); border-radius: 16rpx; transition: border-color 0.15s; } .scan-box.success { border-color: #07c160; }扫码成功时通过setData给扫描框加上success类200ms后去掉。这个闪一下绿的反馈配合震动是连续扫码里性价比最高的交互设计。5. 连续扫码的性能、发热与机型兼容问题排查连续扫码一旦持续时间超过几分钟性能和发热问题就会暴露出来而且不同机型表现差异巨大。这部分是我踩坑最多的地方整理成一个排查链路。5.1 iOS 与 Android 的表现差异实测维度iOSAndroid识别速度快稳定中高端快低端明显慢相机初始化快首次慢可能达2-3秒长时间发热明显5分钟后开始降帧更明显部分机型10分钟烫手黑屏概率低中低端机型较高手电筒响应快偶尔延迟或失效iOS 整体更稳但在长时间连续扫码时也会有降帧现象——系统为了保护电池会主动降低相机采集帧率表现是识别变慢。Android 的问题更集中在相机权限被其他应用抢占上比如用户突然接到电话、切到相机APP回来时你的扫码页可能就黑屏了需要在onShow里做恢复逻辑。5.2 长时间连续扫码的降耗思路如果要连续扫十几分钟得主动做降耗。我的做法有三条第一降分辨率。把resolution从high降到medium功耗能降一截代价是识别率略降。可以做成动态连续扫码超过5分钟后自动降级用户感知不明显。第二降低 UI 刷新频率。setData是整个小程序里最贵的操作之一。扫码回调里如果每次成功都setData整个 list连续扫几百个之后性能会雪崩。我的做法是本地数组维护全量数据setData只更新展示需要的最近几条或者用一个单独的displayCount控制展示条数。第三用节流控制回调处理频率。虽然识别本身不归你控制但你可以控制自己处理结果的频率。加一个最小处理间隔比如100ms内的事件直接忽略。// 简单的节流 onScanCode(e) { const now Date.now() if (now - this._lastHandle 100) return this._lastHandle now // ... 后续处理 }提示setData的数据量超过几十KB时在中低端 Android 上会有肉眼可见的卡顿。连续扫码的列表千万不要全量setData。5.3 识别率低的排查链路识别率低是个综合问题我一般按这个顺序排查从最容易的先来光照——是不是背光或者反光手电筒能不能解决距离——用户是不是贴太近了引导文案有没有码本身——码是否破损、褶皱、分辨率太低打印得太小这是硬伤技术解决不了。分辨率设置——resolution是不是medium小码必须high。镜头脏污——听起来离谱但真遇到过用户镜头有油污导致整体模糊。识别算法差异——微信的扫码引擎在不同基础库版本里有差异更新基础库有时能解决。我遇到过一次特别诡异的同一张码A手机秒识B手机死活识别不了。最后发现是 B 手机的相机对焦坏了物理问题换台机器立刻正常。所以排查时要换机器验证别一条道走到黑。6. 从扫码到业务闭环批量入库、离线缓存与容错扫码只是入口真正的价值在扫完之后的数据怎么处理。这部分决定了你的功能是玩具还是工具。6.1 扫码结果本地队列与批量提交连续扫几十上百个码绝对不能每扫一个就发一次网络请求。一是网络开销巨大二是任何一个请求失败都会打断扫码节奏。正确做法是本地队列 批量提交。我的设计是扫码结果先进本地数组页面上实时展示用户点完成或者队列达到一定数量比如50条时一次性提交。async submitBatch() { const list this.data.list if (!list.length) return wx.showLoading({ title: 提交中 }) try { const res await wx.request({ url: https://yourdomain.com/api/batch, method: POST, data: { items: list.map(i i.code) } }) if (res.data.code 0) { this.setData({ list: [] }) this.deduper.reset() wx.showToast({ title: 提交成功 }) } } catch (e) { // 失败不清空让用户重试 wx.showToast({ title: 提交失败请重试, icon: none }) } finally { wx.hideLoading() } }关键点是失败时不清空本地数据。网络抖动太常见了清空等于让用户白扫一遍这是绝对不能接受的体验。6.2 网络抖动时的重试与幂等批量提交必须考虑幂等。用户点了提交服务端处理成功了但响应超时你这边报失败用户再点一次——如果服务端不做幂等数据就重复了。做法是每次批次生成一个唯一batchId比如时间戳随机串服务端根据batchId去重。const batchId ${Date.now()}_${Math.random().toString(36).slice(2, 8)}这个batchId在重试时要保持不变所以它应该是批次的一部分存在页面状态里提交成功后重置。6.3 一个仓储盘点场景的完整闭环把前面所有东西串起来一个完整的盘点流程是这样的用户进入扫码页检查相机权限渲染相机初始化去重器。对着货位码扫每扫一个去重器判断 - 通过则震动 闪绿 加入本地列表 更新展示。用户随时可以开手电筒应对暗环境。扫完一批点提交带上batchId批量提交到服务端。提交成功清空本地队列、重置去重器失败保留数据提示重试重试时复用同一个batchId。页面切后台时关闭相机节点和手电筒回来时恢复。这套闭环我在实际项目里跑下来一个人盘点一个中等仓库大约300个货位的时间从原来的40多分钟压到了10分钟左右主要省下来的就是每扫一次等界面的时间。识别率方面二维码在正常光照下基本是对准就出条形码则需要多试几次这个后面如果业务允许我会建议把货位标识从条形码换成二维码一步到位。我个人在实际操作中的体会是连续扫码这个功能技术难度不在怎么扫而在扫完之后的一堆状态怎么管——去重、生命周期、批量提交、失败重试每一环都容易出问题而且都是那种不真机长时间跑就发现不了的问题。建议想做的同学先别急着写业务逻辑用一个最少代码的 demo 在真机上连续扫200个码把上面这些坑先踩一遍心里就有数了。如果你们的场景还需要支持离线扫码无网络环境下先存本地联网后再同步那又是另一个话题我在盘点工具里是用本地存储做了一层缓存队列感兴趣的话可以顺着这个思路往下挖。
