拓冰网站定制 
简介这是一份面向移动端Web开发者的HTML5条形码识别实战资源聚焦如何调用手机摄像头完成实时扫码可应用于电商、物流、库存管理等需要快速录入条码的场景适合具备一定JavaScript基础的前端学习者参考。压缩包共3个文件以2个js脚本和1个html页面为主整体约291KB其中html负责搭建摄像头视频流与扫描界面js文件承载条形码识别逻辑及依赖库结构精简便于直接运行调试。资源围绕video标签与getUserMedia获取实时视频流并借助QuaggaJS配置识别类型与扫描区域通过onDetected回调处理识别结果读者可据此理解从调用摄像头到输出条码的完整链路并在此基础上扩展多码制识别、优化扫描性能或对接后台系统。目前已有1683人学习下载适合希望快速上手H5扫码功能的开发者借鉴。1. 调起手机摄像头扫条形码H5 里最容易被低估的 200 行代码很多人第一次接到「H5 扫条形码」需求时第一反应是去找个现成的扫码插件结果翻遍 npm 发现要么体积大得离谱要么在 iOS 微信里直接黑屏。真实情况是现代浏览器已经原生提供了BarcodeDetectorAPI配合getUserMedia就能在 H5 里直接调起手机摄像头完成条形码识别不需要任何第三方 SDK。这套方案在 Android Chrome、部分 Android 微信内核里已经可用iOS Safari 从 17 开始也逐步放开。它解决的核心问题是让一个网页在手机浏览器里直接调用后置摄像头实时识别 EAN-13、Code-128 这类常见条形码把结果回传给业务逻辑。适合做扫码入库、快递单号录入、商品比价这类轻量场景的前端同学也适合不想引入重型扫码库、希望自己掌控整条链路的团队。2. 摄像头调起与 BarcodeDetector从权限到第一帧2.1 为什么优先用原生 API 而不是第三方库先讲选型。市面上常见的 H5 扫码方案大致三类一是html5-qrcode、quagga2这类纯 JS 解码库靠 canvas 逐帧取像素自己算二是BarcodeDetector原生 API三是调起原生 App 或小程序的能力。第三类不算纯 H5先排除。纯 JS 解码库的优点是兼容性广缺点是 CPU 占用高、识别慢尤其在低端安卓机上一秒钟能跑几帧就不错了手机还烫。BarcodeDetector把解码交给系统底层帧率和功耗都好很多代码量也小。代价是兼容性有缺口——iOS 上要较新版本部分国产浏览器内核还没实现。所以常见做法是优先探测BarcodeDetector不支持时再降级到quagga2之类的库。这样主流机型走快路径老设备走兜底路径。这里有个反直觉的点很多人以为扫码难在「识别」其实难在「拿到一帧能识别的画面」。摄像头权限、分辨率、对焦、光照任何一环出问题识别率都会断崖式下跌。所以下面先把摄像头这条链路打通。2.2 调起后置摄像头的完整代码// 请求摄像头并绑定到 video 元素 async function startCamera(videoEl) { // 优先请求后置摄像头facingMode: environment const constraints { audio: false, video: { facingMode: { ideal: environment }, // 后置优先 width: { ideal: 1280 }, // 分辨率别贪高1280 够用 height: { ideal: 720 }, frameRate: { ideal: 30 } } }; try { const stream await navigator.mediaDevices.getUserMedia(constraints); videoEl.srcObject stream; videoEl.setAttribute(playsinline, true); // iOS 关键防止全屏播放 await videoEl.play(); return stream; } catch (err) { // 常见错误NotAllowedError 用户拒绝 / NotFoundError 无摄像头 console.error(摄像头启动失败:, err.name, err.message); throw err; } }逻辑说明getUserMedia是整条链路的入口返回一个MediaStream。把它赋给video.srcObject后调用play()就能出画面。参数上facingMode用ideal而不是exact是因为部分设备没有严格意义上的后置摄像头标识用exact会直接抛错width/height给ideal让浏览器自己协商硬写死某些机型会失败。playsinline必须设否则 iOS Safari 会把视频顶到全屏播放器里扫码界面就废了。提示getUserMedia只能在 HTTPS 或 localhost 下调用HTTP 域名下浏览器会直接拒绝这是最常见的「本地能跑线上黑屏」原因。2.3 用 BarcodeDetector 做逐帧识别// 探测能力并启动识别循环 async function startDetect(videoEl, onResult) { if (!(BarcodeDetector in window)) { throw new Error(当前浏览器不支持 BarcodeDetector); } // 指定要识别的条码格式减少误识别 const formats await BarcodeDetector.getSupportedFormats(); const wanted [ean_13, ean_8, code_128, code_39, upc_a] .filter(f formats.includes(f)); const detector new BarcodeDetector({ formats: wanted }); let running true; async function loop() { if (!running) return; try { const codes await detector.detect(videoEl); if (codes.length 0) { onResult(codes[0].rawValue, codes[0].format); running false; // 识别到就停避免重复回调 return; } } catch (e) { // detect 偶发抛错忽略继续下一帧 } requestAnimationFrame(loop); } loop(); return () { running false; }; }逻辑说明BarcodeDetector.getSupportedFormats()先问系统支持哪些格式再取交集避免传入不支持的格式导致构造失败。detect()接收 video 元素返回识别到的码数组每项含rawValue原始字符串和format码制。用requestAnimationFrame驱动循环和屏幕刷新同步比setInterval更省电也更跟手。识别到第一个结果就停是因为扫码业务通常只需要一个码继续跑纯属浪费。参数上formats列表按业务裁剪很重要。如果你只扫商品条码就留ean_13、upc_a如果扫快递单code_128是主力。格式列得越多误识别的概率越高这是血泪经验。3. 识别率上不去分辨率、对焦与降级策略3.1 分辨率和对焦的真实取舍上一章把链路跑通了但你会发现识别率时好时坏。核心变量有两个分辨率和对焦。分辨率不是越高越好。1280×720 对条形码识别已经足够因为解码靠的是条空对比度不是像素总量。把分辨率拉到 1920 甚至 4K单帧数据量翻几倍detect()耗时上升帧率反而掉下来低端机上直接卡成幻灯片。我一般会从 1280 起步如果识别慢再降到 960。对焦是更隐蔽的坑。getUserMedia拿到的流默认是连续自动对焦但有些安卓机在近距离10~20cm扫小条码时对不上焦画面一直糊。这时可以尝试用applyConstraints手动触发对焦不过支持度参差// 尝试触发一次对焦支持度有限失败不影响主流程 async function tryFocus(stream) { const track stream.getVideoTracks()[0]; const caps track.getCapabilities ? track.getCapabilities() : {}; if (caps.focusMode caps.focusMode.includes(continuous)) { try { await track.applyConstraints({ advanced: [{ focusMode: continuous }] }); } catch (e) { // 部分机型不支持忽略 } } }逻辑说明getCapabilities()返回设备支持的能力集先判断有没有focusMode再尝试设置。这段代码在多数机型上不会报错但也不保证生效属于「能设就设设不了拉倒」的增强项不要把它当成识别率的主依赖。3.2 降级到 quagga2 的兜底方案当BarcodeDetector不可用时得有个兜底。quagga2是纯 JS 解码里比较稳的选择它自己接管摄像头和逐帧解码。// BarcodeDetector 不可用时的降级路径 function startQuagga(onResult) { Quagga.init({ inputStream: { type: LiveStream, constraints: { facingMode: environment, width: 1280, height: 720 }, target: document.querySelector(#scanner-container) }, decoder: { readers: [ean_reader, code_128_reader, code_39_reader] }, locate: true // 开启定位提升倾斜条码识别率 }, function (err) { if (err) { console.error(Quagga 初始化失败, err); return; } Quagga.start(); }); Quagga.onDetected(function (data) { onResult(data.codeResult.code, data.codeResult.format); Quagga.stop(); }); }逻辑说明readers对应要解的各种码制和BarcodeDetector的formats一个道理按需裁剪。locate: true会让 Quagga 先定位条码区域再解码对倾斜、部分遮挡的条码更友好代价是每帧多算一步帧率略降。onDetected里拿到结果后立刻stop()释放摄像头。两条路径的取舍可以看这张表维度BarcodeDetectorquagga2兼容性较新浏览器广泛识别速度快中等偏慢CPU 占用低高代码量少多倾斜条码一般较好locate 开启后常见做法是运行时探测能走原生就走原生不能走再动态加载 quagga2避免所有用户都背上这个库的体积。3.3 识别循环的节流与生命周期管理扫码页面最容易翻车的地方是生命周期。用户切到后台、锁屏、跳转页面摄像头流没释放回来就黑屏或者报「设备被占用」。// 页面隐藏时暂停可见时恢复 let stopDetect null; document.addEventListener(visibilitychange, async () { if (document.hidden) { stopDetect stopDetect(); // 停识别循环 stream stream.getTracks().forEach(t t.stop()); // 释放摄像头 } else { stream await startCamera(videoEl); // 重新拿流 stopDetect await startDetect(videoEl, handleResult); } });逻辑说明visibilitychange是处理这类问题的标准入口。隐藏时把MediaStreamTrack全部stop()这是真正释放摄像头的唯一方式只停识别循环不够。恢复时重新走一遍startCamera因为旧的 track 已经废了。这段逻辑不加用户切个微信回来就得刷新页面体验直接崩。4. 避坑与排查扫码 H5 最常见的五个翻车现场4.1 现象iOS 上视频全屏弹出扫码界面被顶掉原因iOS Safari 对video默认走原生全屏播放器没设playsinline就会这样。 解决给 video 元素加playsinline属性同时用setAttribute在 JS 里也设一遍双保险。4.2 现象线上 HTTPS 正常本地 HTTP 调不起摄像头原因getUserMedia要求安全上下文HTTP 域名下浏览器直接拒绝报NotAllowedError或undefined。 解决本地用localhost调试localhost 被视为安全上下文或者给测试域名配 HTTPS。别想着绕过这是浏览器硬性限制。4.3 现象识别率忽高忽低同一张条码有时秒出有时死活不出原因多半是对焦没跟上或光照不足。近距离小条码在自动对焦下容易糊暗光环境条空对比度不够。 解决引导用户把条码放在画面中央、距离 15~25cm界面上加个取景框提示。必要时开补光灯track.applyConstraints({ advanced: [{ torch: true }] })支持度有限。4.4 现象连续识别到同一个码回调触发好几次原因识别循环没在拿到结果后停止或者业务层没做去重。 解决detect拿到第一个结果就停循环业务层再加一层时间窗去重比如 2 秒内相同rawValue只处理一次。4.5 现象切后台再回来摄像头黑屏或报设备被占用原因页面隐藏时没释放MediaStreamTrack摄像头被旧流占着。 解决监听visibilitychange隐藏时stop()所有 track可见时重新初始化。这是最容易被忽略、又最影响体验的一条。5. 把扫码结果接进业务去重、格式校验与一个自检习惯链路跑通、坑也避了最后一步是把识别结果稳稳地交给业务。这里有个容易被跳过的环节结果校验。BarcodeDetector和 quagga2 都可能返回误识别的码尤其是画面模糊时。我一般会在回调里做三件事。第一格式校验。EAN-13 必须是 13 位数字Code-128 允许字母数字混合。用正则先过一遍不符合的直接丢弃别往接口发。// 按码制做基础校验 function validateCode(raw, format) { if (format ean_13) return /^\d{13}$/.test(raw); if (format ean_8) return /^\d{8}$/.test(raw); if (format upc_a) return /^\d{12}$/.test(raw); if (format code_128 || format code_39) { return raw.length 4 raw.length 48; } return true; }逻辑说明不同码制有固定的长度和字符集约束用正则卡一道能挡掉相当一部分误识别。code_128长度范围宽只做长度兜底。校验不过就继续扫不要弹错误提示打断用户。第二去重。前面提过用时间窗。我习惯用一个 Map 记录最近识别到的码和对应时间戳超过 3 秒的清理掉避免内存泄漏。第三结果回传的时机。识别到有效码后先给用户一个视觉反馈震动或高亮再发请求。navigator.vibrate(100)在安卓上可用iOS 不支持但可以接受。反馈的意义是让用户知道「扫到了」否则他会一直举着手机等。进阶一点如果你要做连续扫码比如批量入库就别在识别到第一个码后停循环而是改成「识别到 → 校验 → 去重 → 入队 → 继续扫」的模式同时界面上滚动显示已扫列表。这时帧率管理更重要可以在两次成功识别之间加一个短暂冷却避免同一个码被反复入队。最后说个自检习惯。扫码这类依赖硬件的功能光在 Chrome 桌面模拟器里调是不够的模拟器不会暴露对焦、光照、权限这些真实问题。我现在的习惯是任何扫码改动至少在一台安卓真机和一台 iPhone 上各走一遍完整流程——授权、扫码、切后台、切回来、再扫。这套走下来能挡掉八成上线后才暴露的玄学问题。从那以后我每次改扫码相关代码都强制走一遍这个真机自检清单省了太多半夜被叫起来排查的麻烦。希望帮到你。本文还有配套的精品资源点击获取 H5原生扫码实战：BarcodeDetector与摄像头调起全解析
简介这是一份面向移动端Web开发者的HTML5条形码识别实战资源聚焦如何调用手机摄像头完成实时扫码可应用于电商、物流、库存管理等需要快速录入条码的场景适合具备一定JavaScript基础的前端学习者参考。压缩包共3个文件以2个js脚本和1个html页面为主整体约291KB其中html负责搭建摄像头视频流与扫描界面js文件承载条形码识别逻辑及依赖库结构精简便于直接运行调试。资源围绕video标签与getUserMedia获取实时视频流并借助QuaggaJS配置识别类型与扫描区域通过onDetected回调处理识别结果读者可据此理解从调用摄像头到输出条码的完整链路并在此基础上扩展多码制识别、优化扫描性能或对接后台系统。目前已有1683人学习下载适合希望快速上手H5扫码功能的开发者借鉴。1. 调起手机摄像头扫条形码H5 里最容易被低估的 200 行代码很多人第一次接到「H5 扫条形码」需求时第一反应是去找个现成的扫码插件结果翻遍 npm 发现要么体积大得离谱要么在 iOS 微信里直接黑屏。真实情况是现代浏览器已经原生提供了BarcodeDetectorAPI配合getUserMedia就能在 H5 里直接调起手机摄像头完成条形码识别不需要任何第三方 SDK。这套方案在 Android Chrome、部分 Android 微信内核里已经可用iOS Safari 从 17 开始也逐步放开。它解决的核心问题是让一个网页在手机浏览器里直接调用后置摄像头实时识别 EAN-13、Code-128 这类常见条形码把结果回传给业务逻辑。适合做扫码入库、快递单号录入、商品比价这类轻量场景的前端同学也适合不想引入重型扫码库、希望自己掌控整条链路的团队。2. 摄像头调起与 BarcodeDetector从权限到第一帧2.1 为什么优先用原生 API 而不是第三方库先讲选型。市面上常见的 H5 扫码方案大致三类一是html5-qrcode、quagga2这类纯 JS 解码库靠 canvas 逐帧取像素自己算二是BarcodeDetector原生 API三是调起原生 App 或小程序的能力。第三类不算纯 H5先排除。纯 JS 解码库的优点是兼容性广缺点是 CPU 占用高、识别慢尤其在低端安卓机上一秒钟能跑几帧就不错了手机还烫。BarcodeDetector把解码交给系统底层帧率和功耗都好很多代码量也小。代价是兼容性有缺口——iOS 上要较新版本部分国产浏览器内核还没实现。所以常见做法是优先探测BarcodeDetector不支持时再降级到quagga2之类的库。这样主流机型走快路径老设备走兜底路径。这里有个反直觉的点很多人以为扫码难在「识别」其实难在「拿到一帧能识别的画面」。摄像头权限、分辨率、对焦、光照任何一环出问题识别率都会断崖式下跌。所以下面先把摄像头这条链路打通。2.2 调起后置摄像头的完整代码// 请求摄像头并绑定到 video 元素 async function startCamera(videoEl) { // 优先请求后置摄像头facingMode: environment const constraints { audio: false, video: { facingMode: { ideal: environment }, // 后置优先 width: { ideal: 1280 }, // 分辨率别贪高1280 够用 height: { ideal: 720 }, frameRate: { ideal: 30 } } }; try { const stream await navigator.mediaDevices.getUserMedia(constraints); videoEl.srcObject stream; videoEl.setAttribute(playsinline, true); // iOS 关键防止全屏播放 await videoEl.play(); return stream; } catch (err) { // 常见错误NotAllowedError 用户拒绝 / NotFoundError 无摄像头 console.error(摄像头启动失败:, err.name, err.message); throw err; } }逻辑说明getUserMedia是整条链路的入口返回一个MediaStream。把它赋给video.srcObject后调用play()就能出画面。参数上facingMode用ideal而不是exact是因为部分设备没有严格意义上的后置摄像头标识用exact会直接抛错width/height给ideal让浏览器自己协商硬写死某些机型会失败。playsinline必须设否则 iOS Safari 会把视频顶到全屏播放器里扫码界面就废了。提示getUserMedia只能在 HTTPS 或 localhost 下调用HTTP 域名下浏览器会直接拒绝这是最常见的「本地能跑线上黑屏」原因。2.3 用 BarcodeDetector 做逐帧识别// 探测能力并启动识别循环 async function startDetect(videoEl, onResult) { if (!(BarcodeDetector in window)) { throw new Error(当前浏览器不支持 BarcodeDetector); } // 指定要识别的条码格式减少误识别 const formats await BarcodeDetector.getSupportedFormats(); const wanted [ean_13, ean_8, code_128, code_39, upc_a] .filter(f formats.includes(f)); const detector new BarcodeDetector({ formats: wanted }); let running true; async function loop() { if (!running) return; try { const codes await detector.detect(videoEl); if (codes.length 0) { onResult(codes[0].rawValue, codes[0].format); running false; // 识别到就停避免重复回调 return; } } catch (e) { // detect 偶发抛错忽略继续下一帧 } requestAnimationFrame(loop); } loop(); return () { running false; }; }逻辑说明BarcodeDetector.getSupportedFormats()先问系统支持哪些格式再取交集避免传入不支持的格式导致构造失败。detect()接收 video 元素返回识别到的码数组每项含rawValue原始字符串和format码制。用requestAnimationFrame驱动循环和屏幕刷新同步比setInterval更省电也更跟手。识别到第一个结果就停是因为扫码业务通常只需要一个码继续跑纯属浪费。参数上formats列表按业务裁剪很重要。如果你只扫商品条码就留ean_13、upc_a如果扫快递单code_128是主力。格式列得越多误识别的概率越高这是血泪经验。3. 识别率上不去分辨率、对焦与降级策略3.1 分辨率和对焦的真实取舍上一章把链路跑通了但你会发现识别率时好时坏。核心变量有两个分辨率和对焦。分辨率不是越高越好。1280×720 对条形码识别已经足够因为解码靠的是条空对比度不是像素总量。把分辨率拉到 1920 甚至 4K单帧数据量翻几倍detect()耗时上升帧率反而掉下来低端机上直接卡成幻灯片。我一般会从 1280 起步如果识别慢再降到 960。对焦是更隐蔽的坑。getUserMedia拿到的流默认是连续自动对焦但有些安卓机在近距离10~20cm扫小条码时对不上焦画面一直糊。这时可以尝试用applyConstraints手动触发对焦不过支持度参差// 尝试触发一次对焦支持度有限失败不影响主流程 async function tryFocus(stream) { const track stream.getVideoTracks()[0]; const caps track.getCapabilities ? track.getCapabilities() : {}; if (caps.focusMode caps.focusMode.includes(continuous)) { try { await track.applyConstraints({ advanced: [{ focusMode: continuous }] }); } catch (e) { // 部分机型不支持忽略 } } }逻辑说明getCapabilities()返回设备支持的能力集先判断有没有focusMode再尝试设置。这段代码在多数机型上不会报错但也不保证生效属于「能设就设设不了拉倒」的增强项不要把它当成识别率的主依赖。3.2 降级到 quagga2 的兜底方案当BarcodeDetector不可用时得有个兜底。quagga2是纯 JS 解码里比较稳的选择它自己接管摄像头和逐帧解码。// BarcodeDetector 不可用时的降级路径 function startQuagga(onResult) { Quagga.init({ inputStream: { type: LiveStream, constraints: { facingMode: environment, width: 1280, height: 720 }, target: document.querySelector(#scanner-container) }, decoder: { readers: [ean_reader, code_128_reader, code_39_reader] }, locate: true // 开启定位提升倾斜条码识别率 }, function (err) { if (err) { console.error(Quagga 初始化失败, err); return; } Quagga.start(); }); Quagga.onDetected(function (data) { onResult(data.codeResult.code, data.codeResult.format); Quagga.stop(); }); }逻辑说明readers对应要解的各种码制和BarcodeDetector的formats一个道理按需裁剪。locate: true会让 Quagga 先定位条码区域再解码对倾斜、部分遮挡的条码更友好代价是每帧多算一步帧率略降。onDetected里拿到结果后立刻stop()释放摄像头。两条路径的取舍可以看这张表维度BarcodeDetectorquagga2兼容性较新浏览器广泛识别速度快中等偏慢CPU 占用低高代码量少多倾斜条码一般较好locate 开启后常见做法是运行时探测能走原生就走原生不能走再动态加载 quagga2避免所有用户都背上这个库的体积。3.3 识别循环的节流与生命周期管理扫码页面最容易翻车的地方是生命周期。用户切到后台、锁屏、跳转页面摄像头流没释放回来就黑屏或者报「设备被占用」。// 页面隐藏时暂停可见时恢复 let stopDetect null; document.addEventListener(visibilitychange, async () { if (document.hidden) { stopDetect stopDetect(); // 停识别循环 stream stream.getTracks().forEach(t t.stop()); // 释放摄像头 } else { stream await startCamera(videoEl); // 重新拿流 stopDetect await startDetect(videoEl, handleResult); } });逻辑说明visibilitychange是处理这类问题的标准入口。隐藏时把MediaStreamTrack全部stop()这是真正释放摄像头的唯一方式只停识别循环不够。恢复时重新走一遍startCamera因为旧的 track 已经废了。这段逻辑不加用户切个微信回来就得刷新页面体验直接崩。4. 避坑与排查扫码 H5 最常见的五个翻车现场4.1 现象iOS 上视频全屏弹出扫码界面被顶掉原因iOS Safari 对video默认走原生全屏播放器没设playsinline就会这样。 解决给 video 元素加playsinline属性同时用setAttribute在 JS 里也设一遍双保险。4.2 现象线上 HTTPS 正常本地 HTTP 调不起摄像头原因getUserMedia要求安全上下文HTTP 域名下浏览器直接拒绝报NotAllowedError或undefined。 解决本地用localhost调试localhost 被视为安全上下文或者给测试域名配 HTTPS。别想着绕过这是浏览器硬性限制。4.3 现象识别率忽高忽低同一张条码有时秒出有时死活不出原因多半是对焦没跟上或光照不足。近距离小条码在自动对焦下容易糊暗光环境条空对比度不够。 解决引导用户把条码放在画面中央、距离 15~25cm界面上加个取景框提示。必要时开补光灯track.applyConstraints({ advanced: [{ torch: true }] })支持度有限。4.4 现象连续识别到同一个码回调触发好几次原因识别循环没在拿到结果后停止或者业务层没做去重。 解决detect拿到第一个结果就停循环业务层再加一层时间窗去重比如 2 秒内相同rawValue只处理一次。4.5 现象切后台再回来摄像头黑屏或报设备被占用原因页面隐藏时没释放MediaStreamTrack摄像头被旧流占着。 解决监听visibilitychange隐藏时stop()所有 track可见时重新初始化。这是最容易被忽略、又最影响体验的一条。5. 把扫码结果接进业务去重、格式校验与一个自检习惯链路跑通、坑也避了最后一步是把识别结果稳稳地交给业务。这里有个容易被跳过的环节结果校验。BarcodeDetector和 quagga2 都可能返回误识别的码尤其是画面模糊时。我一般会在回调里做三件事。第一格式校验。EAN-13 必须是 13 位数字Code-128 允许字母数字混合。用正则先过一遍不符合的直接丢弃别往接口发。// 按码制做基础校验 function validateCode(raw, format) { if (format ean_13) return /^\d{13}$/.test(raw); if (format ean_8) return /^\d{8}$/.test(raw); if (format upc_a) return /^\d{12}$/.test(raw); if (format code_128 || format code_39) { return raw.length 4 raw.length 48; } return true; }逻辑说明不同码制有固定的长度和字符集约束用正则卡一道能挡掉相当一部分误识别。code_128长度范围宽只做长度兜底。校验不过就继续扫不要弹错误提示打断用户。第二去重。前面提过用时间窗。我习惯用一个 Map 记录最近识别到的码和对应时间戳超过 3 秒的清理掉避免内存泄漏。第三结果回传的时机。识别到有效码后先给用户一个视觉反馈震动或高亮再发请求。navigator.vibrate(100)在安卓上可用iOS 不支持但可以接受。反馈的意义是让用户知道「扫到了」否则他会一直举着手机等。进阶一点如果你要做连续扫码比如批量入库就别在识别到第一个码后停循环而是改成「识别到 → 校验 → 去重 → 入队 → 继续扫」的模式同时界面上滚动显示已扫列表。这时帧率管理更重要可以在两次成功识别之间加一个短暂冷却避免同一个码被反复入队。最后说个自检习惯。扫码这类依赖硬件的功能光在 Chrome 桌面模拟器里调是不够的模拟器不会暴露对焦、光照、权限这些真实问题。我现在的习惯是任何扫码改动至少在一台安卓真机和一台 iPhone 上各走一遍完整流程——授权、扫码、切后台、切回来、再扫。这套走下来能挡掉八成上线后才暴露的玄学问题。从那以后我每次改扫码相关代码都强制走一遍这个真机自检清单省了太多半夜被叫起来排查的麻烦。希望帮到你。本文还有配套的精品资源点击获取