企业官网建设流程全解析

1. 从一个真实需求说起：为什么要死磕连续扫码

去年接了一个仓储盘点的小程序项目，需求方开口第一句话就是：“我要能一直扫，扫完一个自动跳下一个，别让我点来点去。”听起来简单得不行，对吧？微信小程序不是自带wx.scanCode吗？调一下不就完了？

结果真上手才发现，事情远没有想象中那么顺滑。wx.scanCode是单次调用接口，每次扫码都会拉起一个全屏的原生扫码界面，扫完返回结果，界面关闭。用户想连续扫十个条码，就得经历“点击按钮→扫码界面弹出→对准→识别→界面关闭→再点按钮”这个循环十次。在仓库那种光线一般、条码磨损、工人戴着手套的环境里，这个体验简直是灾难。

后来我把目光转向了camera组件。它允许你在页面内嵌一个相机预览区域，配合wx.createCameraContext()和其中的onCameraFrame回调，理论上可以实现“页面不跳转、持续识别”的效果。但真正动手之后，我踩了一连串的坑：帧回调频率怎么控制、识别逻辑放主线程还是 Worker、iOS 和 Android 表现不一致、连续识别同一个码怎么去重、页面切后台相机怎么释放……这些问题官方文档要么一笔带过，要么根本没提。

这篇文章就是把这些东西全部摊开讲清楚。如果你也在做需要连续扫码的小程序，或者对camera组件的底层机制感兴趣，那接下来的内容应该能帮你省下不少试错时间。我会从整体设计思路讲起，然后拆解核心细节，再给出可直接参考的实现方案，最后把那些年我踩过的坑整理成一份速查表。

2. 整体设计思路：为什么不能只用 scanCode

2.1 scanCode 的能力边界在哪里

先把wx.scanCode的定位说清楚。它是微信提供的一个原生扫码能力封装，调用后会拉起一个独立的原生页面，由微信客户端自己完成图像采集和识别，开发者拿到的是一个已经解析好的结果对象。这个接口的优点是稳定、兼容性好、识别率高，毕竟底层用的是微信自己的识别引擎。

但它的局限也很明显：

• 无法自定义界面：扫码界面完全由微信控制，你改不了按钮位置、加不了提示文字、没法在取景框上叠加自己的 UI。
• 单次触发：每次调用只能扫一个码，扫完就结束，没有“连续模式”这个选项。
• 无法获取原始帧：你拿不到相机预览画面，也就没法做自定义的图像处理，比如批量识别多个条码、识别特定格式的图形码等。
• 页面跳转感强：原生扫码页拉起时，用户能明显感知到“换了个界面”，在需要高频连续操作的场景里，这种割裂感很影响效率。

所以，scanCode适合“偶尔扫一次”的场景，比如扫个付款码、扫个链接。但一旦需求变成“连续扫几十个”，它就不够用了。

2.2 camera 组件能补上哪些短板

camera组件是微信小程序提供的一个原生组件，它把相机预览直接嵌入到你的页面里。你可以像摆一个普通 view 一样摆它，设置它的位置、大小、层级。配合wx.createCameraContext()创建的上下文对象，你能拿到onCameraFrame回调，每一帧画面都会以ArrayBuffer的形式传给你。

这就打开了自定义的大门：

• 界面完全可控：取景框、扫描线、提示文字、已扫列表，全部由你自己画。
• 持续识别：只要相机开着，帧回调就在跑，你可以在回调里做识别，实现“扫完一个接着扫下一个”。
• 可做图像预处理：拿到原始帧数据后，你可以做灰度化、二值化、区域裁剪等操作，提升特定场景下的识别率。
• 多码识别潜力：理论上可以在一帧画面里同时定位多个条码区域，实现批量识别。

但代价也很直接：识别逻辑要自己写。微信不会帮你解析条码内容，你得自己引入识别库，或者把帧数据传给后端做识别。这就引出了下一个关键决策。

2.3 识别方案选型：前端识别还是后端识别

这是整个项目里最重要的一个岔路口。两条路各有优劣，选错了后面全是返工。

我当时的项目是仓储盘点，仓库里网络信号时好时坏，而且工人操作节奏很快，等不起网络往返。所以我选了前端识别方案。具体来说，是把识别逻辑放在Worker里跑，主线程只负责拿帧、丢给 Worker、接收结果。

为什么用 Worker？因为onCameraFrame的回调频率很高，如果直接在回调里跑识别算法，主线程会被占满，页面直接卡死。Worker 是独立线程，识别再慢也不会阻塞 UI。这个决策后面会详细展开。

3. 核心细节解析：帧回调、Worker 与去重逻辑

3.1 onCameraFrame 的触发机制与频率控制

onCameraFrame是CameraContext上的一个回调注册方法。你调用cameraContext.onCameraFrame(callback)之后，相机每采集一帧画面，就会触发一次 callback，把帧数据传进来。

帧数据的结构大概是这样：

{ width: 640, // 帧宽度 height: 480, // 帧高度 data: ArrayBuffer // RGBA 格式的像素数据 }

注意，data是RGBA格式，每个像素占 4 个字节。一帧 640x480 的画面，数据量就是 640 * 480 * 4 = 1,228,800 字节，差不多 1.2MB。如果相机每秒采集 30 帧，那就是每秒 36MB 的数据流过。这个量级如果不加控制，内存和 CPU 都扛不住。

所以第一件事就是降频。我不需要每帧都识别，每秒识别 3 到 5 次足够了。做法很简单，在回调里加一个时间戳判断：

let lastFrameTime = 0; const FRAME_INTERVAL = 200; // 200ms 识别一次，即每秒 5 次 cameraContext.onCameraFrame((frame) => { const now = Date.now(); if (now - lastFrameTime < FRAME_INTERVAL) { return; // 跳过这一帧 } lastFrameTime = now; // 把 frame 丢给 Worker 处理 worker.postMessage({ width: frame.width, height: frame.height, data: frame.data }, [frame.data]); // 注意：转移所有权，避免拷贝 });

这里有个关键点：postMessage的第二个参数是转移列表。把frame.data加进去之后，这个 ArrayBuffer 的所有权就从主线程转移到了 Worker，不会发生内存拷贝。如果不加这个，每帧 1.2MB 的数据拷贝会带来明显的性能开销。

注意：转移所有权之后，主线程就不能再访问这个 ArrayBuffer 了。如果你后续还需要用原始帧做别的事情，就不能转移，只能拷贝。但在连续扫码场景里，帧数据用完即弃，转移是最优解。

3.2 Worker 里的识别逻辑怎么组织

Worker 收到帧数据后，要做几件事：把 RGBA 转成灰度、做二值化、定位条码区域、解码。这一整套流程如果全部自己写，工作量不小。实际项目中，我建议直接引入成熟的条码识别库，比如zxing-wasm或者quagga2的 WASM 版本。

以zxing-wasm为例，Worker 里的代码大概长这样：

import { readBarcodes } from 'zxing-wasm'; self.onmessage = async (e) => { const { width, height, data } = e.data; // 把 RGBA 转成 zxing 需要的格式 const imageData = { data: new Uint8ClampedArray(data), width: width, height: height }; try { const results = await readBarcodes(imageData, { formats: ['QRCode', 'Code128', 'EAN13'], // 按需指定格式 tryHarder: true, maxNumberOfSymbols: 1 }); if (results.length > 0) { self.postMessage({ success: true, text: results[0].text, format: results[0].format }); } else { self.postMessage({ success: false }); } } catch (err) { self.postMessage({ success: false, error: err.message }); } };

这里有几个实操要点：

• 格式限定：formats一定要按需指定。如果你只扫 QR 码，就只写['QRCode']。格式越多，识别越慢。
• tryHarder 的取舍：tryHarder: true会提升识别率，但也会增加单帧处理时间。在光线好、条码清晰的场景里可以关掉，在恶劣环境下再打开。
• maxNumberOfSymbols：连续扫码场景通常一次只扫一个，设成 1 可以避免不必要的计算。

3.3 连续扫码的去重与节流策略

连续扫码最怕什么？怕同一个码被反复识别。相机对着一个条码，每秒识别 5 次，如果不去重，同一个码会连续触发 5 次“扫码成功”，业务逻辑直接乱掉。

去重策略我试过三种：

第一种：基于内容去重。维护一个最近识别结果的集合，如果新结果和集合里的某个值相同，就忽略。集合可以设一个过期时间，比如 3 秒。这种方案简单，但有个问题：如果两个不同的商品条码内容恰好相同（比如同一款商品的多个包装），会被误判为重复。

第二种：基于时间窗口去重。识别到一个码之后，强制冷却 1.5 秒，期间所有识别结果都忽略。这种方案能解决“同一个码连续触发”的问题，但如果用户手速快，1.5 秒内扫了下一个码，就会被漏掉。

第三种：基于内容+时间双重去重。如果新结果和上一次结果相同，且距离上次识别时间小于 2 秒，就忽略；如果内容不同，立即放行。这是我最终采用的方案，兼顾了准确性和流畅度。

let lastResult = ''; let lastResultTime = 0; const DEDUP_INTERVAL = 2000; function shouldAccept(newResult) { const now = Date.now(); if (newResult === lastResult && now - lastResultTime < DEDUP_INTERVAL) { return false; } lastResult = newResult; lastResultTime = now; return true; }

实操心得：去重窗口不要设太长。我一开始设了 5 秒，结果工人扫完一个码之后马上扫下一个，如果两个码内容碰巧一样（比如同一批次的产品），第二个就被吞了。后来改成 2 秒，配合界面上的“已扫描”提示，用户能清楚看到当前码已经被记录，不会重复扫。

4. 完整实操流程：从零搭建连续扫码页面

4.1 页面结构与 camera 组件配置

先看页面的 WXML 结构。核心就是一个全屏的 camera 组件，上面叠加自定义的 UI 层。

<view class="scan-container"> <camera device-position="back" flash="off" frame-size="medium" resolution="medium" bindinitdone="onCameraInit" binderror="onCameraError" class="camera-view" /> <view class="overlay"> <view class="scan-frame"> <view class="scan-line" /> </view> <view class="hint">{{ hintText }}</view> </view> <view class="result-panel"> <view class="result-title">已扫描 {{ scannedList.length }} 项</view> <scroll-view scroll-y class="result-list"> <view wx:for="{{ scannedList }}" wx:key="index" class="result-item"> <text class="result-code">{{ item.code }}</text> <text class="result-time">{{ item.time }}</text> </view> </scroll-view> </view> </view>

几个关键属性说明：

• frame-size：可选small、medium、large。这个属性直接影响onCameraFrame返回的帧尺寸。small大约是 320x240，medium大约是 640x480，large大约是 1280x720。尺寸越大，识别率越高，但数据量也越大。我实测下来，medium是性价比最高的选择，640x480 的分辨率足够识别大多数条码，数据量也还能接受。
• resolution：相机采集分辨率，和frame-size是两回事。resolution影响预览画面的清晰度，frame-size影响帧回调的数据尺寸。可以分开设置。
• device-position：连续扫码通常用后置摄像头，设成back。
• flash：默认关掉。如果环境光线暗，可以提供一个手电筒按钮让用户手动开启，但不要默认开，费电。

4.2 相机初始化与权限处理

相机初始化是异步的，bindinitdone触发后才算真正就绪。在这之前调用onCameraFrame可能会报错。所以正确的顺序是：

Page({ data: { cameraReady: false, scannedList: [], hintText: '正在启动相机...' }, onCameraInit() { this.setData({ cameraReady: true, hintText: '请将条码对准取景框' }); this.startScan(); }, onCameraError(e) { console.error('相机错误', e.detail); this.setData({ hintText: '相机启动失败，请检查权限' }); // 引导用户去设置页开启权限 wx.showModal({ title: '需要相机权限', content: '请在设置中允许使用摄像头', confirmText: '去设置', success: (res) => { if (res.confirm) { wx.openSetting(); } } }); }, startScan() { if (!this.data.cameraReady) return; const context = wx.createCameraContext(); this.cameraContext = context; this.frameListener = context.onCameraFrame((frame) => { this.handleFrame(frame); }); this.frameListener.start(); }, onUnload() { // 页面卸载时务必停止帧监听并释放相机 if (this.frameListener) { this.frameListener.stop(); } } });

注意：onCameraFrame返回的是一个CameraFrameListener对象，必须调用它的start()方法才会开始接收帧，调用stop()才会停止。很多人在这一步踩坑，注册了回调但忘了 start，结果一直收不到帧，还以为是相机没启动。

4.3 Worker 的创建与通信

小程序的 Worker 使用方式和 Web Worker 类似，但有一些限制。首先，Worker 文件必须放在特定目录下，通常是workers/目录。其次，Worker 里不能直接使用小程序的 API，只能跑纯 JS 逻辑。

创建 Worker 的代码：

// 在主线程中 const worker = wx.createWorker('workers/scanWorker.js'); worker.onMessage((res) => { if (res.success && this.shouldAccept(res.text)) { this.addScanResult(res.text, res.format); } }); worker.onError((err) => { console.error('Worker 错误', err); });

Worker 文件workers/scanWorker.js里引入识别库。这里有个坑：Worker 里不能直接用import语法，需要用require，而且引入的库必须是纯 JS 或 WASM，不能依赖 DOM 或小程序 API。

// workers/scanWorker.js const { readBarcodes } = require('./zxing-wasm.js'); self.onmessage = async (e) => { const { width, height, data } = e.data; // ... 识别逻辑 };

如果识别库体积较大，建议做按需加载或者分包。我用的zxing-wasm压缩后大概 300KB 左右，放在 Worker 里不影响主包体积，但首次加载会有一定耗时。可以在页面onLoad时就创建 Worker，提前预热。

4.4 识别结果的处理与界面反馈

识别到结果之后，要做三件事：去重判断、加入列表、给出反馈。

addScanResult(code, format) { const now = new Date(); const timeStr = `${now.getHours()}:${String(now.getMinutes()).padStart(2, '0')}:${String(now.getSeconds()).padStart(2, '0')}`; const newList = [{ code: code, format: format, time: timeStr }, ...this.data.scannedList]; this.setData({ scannedList: newList, hintText: `已扫描：${code}` }); // 震动反馈 wx.vibrateShort({ type: 'medium' }); // 播放提示音（可选） // this.playBeep(); // 2 秒后恢复提示文字 setTimeout(() => { this.setData({ hintText: '请将条码对准取景框' }); }, 2000); }

震动反馈在连续扫码场景里非常重要。工人往往不会一直盯着屏幕看，扫到没扫到全靠手感和声音。wx.vibrateShort在 iOS 和 Android 上表现有差异，Android 通常更明显，iOS 的震动偏弱。如果环境嘈杂，建议加上提示音。

提示音可以用wx.createInnerAudioContext()播放一个短促的 beep 音频。注意 iOS 静音键的问题：如果用户开了静音，innerAudioContext默认是不出声的。需要设置obeyMuteSwitch = false才能强制播放，但这个属性在部分基础库版本上表现不一致，需要做好降级处理。

5. 常见问题与排查技巧实录

5.1 帧回调不触发或触发频率异常

这是最常见的问题，表现是onCameraFrame注册了但一直不回调，或者回调频率远低于预期。

排查顺序：

1. 确认 camera 组件已经初始化完成。在bindinitdone之前调用onCameraFrame是无效的。
2. 确认调用了frameListener.start()。只注册不 start，等于没注册。
3. 检查frame-size设置。某些基础库版本下，frame-size设成large会导致帧回调不稳定，降成medium或small试试。
4. 检查页面是否在前台。小程序切到后台后，相机和帧回调都会被暂停，这是系统行为，无法绕过。
5. 检查是否有多个 camera 组件。同一页面同时存在多个 camera 组件时，只有第一个能正常工作。

实操心得：我在 Android 上遇到过帧回调频率忽高忽低的情况，后来发现是相机自动对焦在频繁调整。把focus-mode设成fixed或者手动触发对焦，帧率就稳定了。不过focus-mode属性在部分机型上不支持，需要做兼容判断。

5.2 识别率低、识别慢的优化方向

识别率低通常和图像质量有关。可以从这几个方面优化：

• 提高帧分辨率：把frame-size从small升到medium，识别率会有明显提升。
• 限制识别区域：不要对整帧做识别，只对取景框内的区域做识别。可以在 Worker 里先裁剪出中心区域，再送给识别库。这样既提升速度，又减少干扰。
• 调整二值化阈值：如果条码对比度低，可以在识别前做一次自适应二值化。zxing-wasm内部有相关处理，但你可以通过预处理进一步提升。
• 开启 tryHarder：在识别率优先的场景下打开，代价是单帧处理时间增加 30% 到 50%。

识别慢的话，首先要确认是不是 Worker 里的识别库在重复初始化。识别库应该只初始化一次，而不是每帧都初始化。其次检查帧数据拷贝次数，确保用了转移所有权的方式传递 ArrayBuffer。

5.3 iOS 与 Android 的兼容性差异

这是最让人头疼的部分。同样的代码，两个平台表现可能完全不同。

注意：iOS 上如果小程序切到后台再回来，相机经常需要重新初始化。我的做法是在onShow里判断cameraReady状态，如果相机已经失效，就重新走一遍初始化流程。不要假设相机一直可用。

5.4 连续扫码的性能与内存管理

连续扫码跑久了，小程序会变卡甚至闪退，基本都是内存问题。几个关键控制点：

• 及时释放帧数据：用了转移所有权之后，主线程不再持有帧数据，Worker 处理完也要及时置空引用，让 GC 回收。
• 控制识别频率：不要每帧都识别，200ms 一次足够了。识别频率翻倍，CPU 占用也差不多翻倍。
• 限制已扫列表长度：界面上展示的已扫列表不要无限增长，超过 100 条就截断或者分页。setData的数据量过大会导致通信开销剧增。
• 页面隐藏时停止扫描：在onHide里调用frameListener.stop()，在onShow里重新start()。不要让相机在后台空跑。

onHide() { if (this.frameListener) { this.frameListener.stop(); } }, onShow() { if (this.data.cameraReady && this.frameListener) { this.frameListener.start(); } }

5.5 常见问题速查表

6. 一些进阶玩法与扩展思路

连续扫码做稳之后，可以往上叠一些更有意思的能力。

批量识别多码：zxing-wasm支持maxNumberOfSymbols大于 1，可以在一帧里同时识别多个条码。这在盘点场景里很有用，一次对准货架，同时扫多个商品。但要注意，多码识别对图像质量要求更高，而且结果排序不稳定，需要自己做位置排序。

扫码结果实时校验：扫到的码可以立即和本地缓存或后端接口做校验，判断是否属于当前盘点任务。如果不属于，界面标红提示，避免误扫。这个逻辑放在 Worker 里做不了，需要在主线程收到结果后异步请求。

离线模式：把商品信息缓存在本地，扫码后直接匹配，不依赖网络。等有网了再批量同步。这对仓库、地下车库等弱网场景非常实用。

自定义识别区域：在取景框上画一个矩形，只识别这个矩形内的条码。实现方式是在 Worker 里根据坐标裁剪帧数据。这样可以避免取景框外的条码干扰，也能提升识别速度。

扫码历史导出：把已扫列表导出成 CSV 或 Excel，方便后续对账。小程序端可以用wx.getFileSystemManager()写文件，然后调wx.shareFileMessage分享出去。

这些扩展我在不同项目里都做过，核心的连续扫码框架不变，只是在结果处理层做加法。先把基础跑通，再按需叠加，不要一上来就全都要，那样调试成本会成倍增加。

我个人在实际操作中的体会是，连续扫码这件事，难点从来不在“识别”本身，而在“稳定”和“流畅”。识别库选对了，识别率都不会太差；但帧回调的管理、Worker 的通信、内存的控制、双端的兼容，这些才是真正吃时间的地方。把降频、去重、释放这三件事做扎实，基本就能覆盖 80% 的坑。剩下的 20%，靠真机实测慢慢磨。