HTML本身不能直接扫码，需结合JavaScript、MediaDevices API及第三方解码库（如@zxing/library）实现；须HTTPS/localhost环境，注意兼容性、权限、重复触发及真机测试。
HTML 能直接扫码识别吗？不能，但可以调用摄像头配合 JS 库实现
纯 HTML 本身没有扫码能力，<input type="file" accept="image/*"> 只能选图，无法实时捕获视频流并解码二维码。真正起作用的是 JavaScript + 浏览器 MediaDevices API + 第三方解码库（如 jsQR 或 @zxing/library）。关键在于：浏览器必须运行在 HTTPS（或 localhost）环境下，否则 navigator.mediaDevices.getUserMedia 会被拒绝。
为什么用 @zxing/library 而不是 jsQR？兼容性与易用性权衡
@zxing/library 支持更多码制（QR、Aztec、DataMatrix、UPC 等），API 更统一；jsQR 更轻量但只专注 QR 码，且需手动做 canvas 帧提取和灰度转换。实际项目中推荐 @zxing/library，尤其当需要识别条形码或容错率要求高时：
- 它内置了
BrowserMultiFormatReader，自动适配摄像头/图片/视频流输入 - 支持
decodeFromVideoElement直接绑定<video></video>，省去 canvas 拷贝帧的步骤 - 但要注意：它默认不启用摄像头自动对焦，某些安卓机型扫码失败，需手动加
constraints: { focusMode: 'continuous' } - 首次解码可能延迟 300–800ms，建议加 loading 提示，避免用户反复晃动设备
navigator.mediaDevices.getUserMedia 常见报错及绕过方式
最常遇到的错误是：NotAllowedError: Permission denied 或 NotFoundError: No video input devices found。根本原因不是代码写错，而是环境或权限问题：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 非 HTTPS 页面（包括
http://192.168.x.x）一律被 Chrome/Firefox 拒绝访问摄像头 —— 必须用https://或http://localhost - 移动 Safari 对
getUserMedia支持较晚，iOS 14.3+ 才稳定支持后台持续扫码，旧版本需保持前台激活 - 部分安卓 WebView（如微信内置浏览器）禁用该 API，可先用
if (navigator.mediaDevices?.getUserMedia)检测，降级为文件上传 - 用户点击“拒绝”后，Chrome 不会再次弹窗，需引导其手动到地址栏点击摄像头图标重新授权
扫码成功后怎么防重复触发？别只靠 result 判断
摄像头每秒输出 20–30 帧，@zxing/library 默认连续解码，同一码可能在几帧内重复返回相同 result.getText()，导致多次提交。不能只靠“有结果就执行”，得加状态控制：
立即学习“前端免费学习笔记（深入）”；
- 用布尔变量
isScanning控制是否允许下一次解码，扫码成功后立即设为false，处理完逻辑再重置 - 更稳妥的做法是比对上一次成功结果：
if (result.getText() !== lastSuccessText)，避免因帧抖动误判 - 移动端强烈建议加 1.5 秒冷却期（
setTimeout），防止用户手抖连续扫出多个相同结果 - 若需持续扫码（如仓库盘点），应主动调用
reset()并清空上次结果，而不是依赖库自动重试
真正在生产环境跑通扫码，最难的往往不是解码逻辑，而是各种浏览器策略、权限弹窗时机、低端机帧率不足导致的漏扫——这些没法靠改一两行代码解决，得在真实机型上反复测，尤其是 Android 旧机型和 iOS 微信 WebView。
