唯一靠谱的纯前端条形码检测方案是浏览器原生 BarcodeDetector API,仅 Chromium 系统(Chrome 87+/Edge 87+/Opera 73+)稳定支持,Safari 和 Firefox 明确不支持,需先检测 'BarcodeDetector' in window 再降级至 jsQR 或 html5-qrcode。
纯前端做条形码检测,不依赖后端、不发请求,唯一靠谱的路径是用浏览器原生 BarcodeDetector API——但它只在 Chromium 系统(Chrome/Edge/新版 Opera)中稳定可用,Safari 和 Firefox 完全不支持,别白费劲配 polyfill。
先确认你的目标用户是否真能用上这个 API。运行 'BarcodeDetector' in window,返回 false 就直接走备用方案。它不是“未来会支持”,而是「当前明确不支持」:Safari 无计划、Firefox 明确拒绝实现(WICG 讨论已关闭)。如果你的业务必须覆盖 iOS 用户,BarcodeDetector 就不该出现在主流程里。
CODE128、EAN13、qr_code 等)detect() 抛 NotAllowedError 或静默失败不能直接传 <video></video> 元素,得传 ImageBitmap 或 HTMLCanvasElement。典型流程是:绑视频流 → 拿到 video 元素 → 每帧 draw 到 canvas → 转成 ImageBitmap → 丢给 detect()。注意别在 requestAnimationFrame 里无节制调用,否则 CPU 拉满、解码延迟飙升。
detect() 耗时翻倍video.readyState === 4 判断是否可播放,否则 drawImage() 无效rawValue(字符串)、format(如 "ean_13")、boundingBox(DOMRect)detect() 时加节流,比如限制每 500ms 最多一次,避免重复识别同一码没报错但一直扫不出码,八成是这几个原因:光照不足(尤其反光商品包装)、条码倾斜超 15°、码被遮挡超 30%、或 canvas 内容未真正更新(video 暂停了但 canvas 还在画旧帧)。别信“自动对焦”——大部分手机浏览器根本没触发对焦逻辑。
立即学习“前端免费学习笔记(深入)”;
video 的 playbackRate 是否为 0(暂停状态)detector.getSupportedFormats() 确认你要的格式(如 "code_128")确实在返回列表里canvas.toDataURL() 截一帧图保存下来,肉眼确认条码是否清晰、居中、无畸变getUserMedia,需引导用户手动开「相机后台使用权限」只要 BarcodeDetector 不可用,就该立刻切到 jsQR(轻量、专注 QR)或 html5-qrcode(支持更多一维码、自带 UI)。别自己封装“混合检测器”——它们底层策略冲突,比如 html5-qrcode 默认用 ZXing.js,而 ZXing.js 在低光下比 BarcodeDetector 更容易误识。
jsQR 只认 QR 码,体积仅 50KB,适合扫码登录等单一场景html5-qrcode 启动慢(要加载 WASM)、首扫时间长(TTFF > 2s),但支持 CODE39、ITF14 等冷门码制html5-qrcode,务必关掉 fps 以外的冗余选项(如 disableFlip、qrcodeMode),否则移动端卡顿明显真正难的从来不是“怎么写”,而是判断哪一帧该交出去检测、哪一帧该丢弃——光线变化、手指抖动、屏幕反光,都会让同一张条码在连续帧里呈现完全不同的像素分布。API 只管解码,剩下全是业务逻辑的事。