過去很多年里誰要在網(wǎng)頁里讀一張卡、掃一個(gè)條碼、點(diǎn)一個(gè)物理按鈕基本都得繞一大圈要么裝驅(qū)動(dòng)、要么寫一個(gè)本地服務(wù)要么靠瀏覽器插件甚至 ActiveX 這類早就該進(jìn)博物館的東西。WebHID 出來之后這條路終于被徹底改寫了——瀏覽器可以直接和 HID 類外設(shè)通信刷卡器、掃描槍、自定義按鈕面板、大手柄這些以前必須通過中間層才能訪問的設(shè)備現(xiàn)在幾行 JavaScript 就能搞定。這篇文章我想結(jié)合自己最近做的一個(gè)跨平臺(tái)演示項(xiàng)目把這套東西從頭到尾捋一遍包括協(xié)議基礎(chǔ)、權(quán)限邊界、完整實(shí)操還有我踩過的幾個(gè)坑。適合想把 WebHID 用進(jìn)真實(shí)項(xiàng)目或者正在做設(shè)備調(diào)試工具、內(nèi)部管理系統(tǒng)的人讀完你至少能判斷這個(gè)東西適不適合你的場(chǎng)景如果適合第一步怎么邁、最該防什么。1. 先想清楚這20年里瀏覽器為什么碰不了外設(shè)1.1 沒有瀏覽器原生能力之前我們是怎么讀寫外設(shè)的我最早接觸這塊是在很多年前當(dāng)時(shí)某個(gè)老系統(tǒng)要在網(wǎng)頁上讀 USB 刷卡器。那套架構(gòu)現(xiàn)在回頭看簡(jiǎn)直能用“疊床架屋”來形容刷卡器插在電腦上驅(qū)動(dòng)裝一遍然后本機(jī)跑一個(gè)常駐服務(wù)網(wǎng)頁再通過 HTTP 輪詢或 WebSocket 跟本地服務(wù)通信服務(wù)拿到數(shù)據(jù)再返回給頁面。聽起來能用但用戶那邊一旦換個(gè)插口、重裝系統(tǒng)、服務(wù)崩了整個(gè)流程就斷掉運(yùn)維成本全攤在腦袋上。后來也流行過瀏覽器插件方案頁面通過插件調(diào)用系統(tǒng) API 或者廠商 SDK。方便是方便一些但插件的安裝、簽名、跨瀏覽器兼容都是問題。尤其現(xiàn)在很多現(xiàn)代瀏覽器已經(jīng)不支持舊式插件這條路基本等于沒了。再后來有人嘗試把外設(shè)數(shù)據(jù)先轉(zhuǎn)發(fā)到云端再回傳但這套東西延遲大、依賴網(wǎng)絡(luò)在設(shè)備離線或內(nèi)網(wǎng)環(huán)境里壓根跑不通。你會(huì)發(fā)現(xiàn)這些老方案的本質(zhì)都一樣瀏覽器缺少直接訪問設(shè)備的通道所以必須在中間塞一層“信使”。WebHID 的意義正在于此。它不是給原有的中間層打補(bǔ)丁而是把 HID 設(shè)備的通信能力直接做進(jìn)了瀏覽器 API。以前你需要在本地寫一個(gè)程序去和設(shè)備交互現(xiàn)在這段邏輯可以換成頁面上的一段 JavaScript。不是所有外設(shè)問題都被解決了但凡是 HID 協(xié)議族里的設(shè)備這條路走起來特別通暢。1.2 WebHID、WebUSB、Web Serial 的分工邊界瀏覽器為了補(bǔ)上“不能碰外設(shè)”這塊短板其實(shí)陸續(xù)放出了一系列 API除了 WebHID還有 WebUSB、Web Serial、Web Bluetooth。很多第一次接觸的人會(huì)把它們混為一談實(shí)際上它們面向的設(shè)備類型完全不同選擇哪個(gè)取決于你手里設(shè)備用的是什么協(xié)議。API主要面向連接方式典型設(shè)備WebHIDHID 類設(shè)備免驅(qū)動(dòng)系統(tǒng)自帶 HID 協(xié)議棧刷卡器、掃描槍、控制面板、手柄WebUSBUSB 設(shè)備非 HID 類需要設(shè)備支持廠商自定義 USB 協(xié)議傳感器、定制 USB 設(shè)備、部分打印機(jī)Web Serial串口設(shè)備通過 COM/TTY 端口暴露Arduino、單片機(jī)、工業(yè)串口設(shè)備Web BluetoothBLE 無線設(shè)備藍(lán)牙配對(duì)連接心率帶、藍(lán)牙信標(biāo)、低功耗傳感器我自己的感覺是如果設(shè)備本身就是標(biāo)準(zhǔn) HID那優(yōu)先考慮 WebHID。因?yàn)?HID 設(shè)備在操作系統(tǒng)層面一般自帶驅(qū)動(dòng)插上就能被系統(tǒng)識(shí)別不需要用戶額外裝廠商驅(qū)動(dòng)。而且 WebHID 的開發(fā)模型比 WebUSB 簡(jiǎn)單不少不用自己設(shè)計(jì) USB 控制傳輸和批量傳輸那套復(fù)雜流程。當(dāng)然如果你的設(shè)備不是 HID 類比如一個(gè)自定義 USB 傳感器它并不向系統(tǒng)聲明自己是鍵盤或刷卡器那就得走 WebUSB 或 Web Serial 通道。做技術(shù)選型時(shí)先搞清楚設(shè)備屬于哪一類能省掉后面大量返工。2. WebHID 到底念了哪本“協(xié)議經(jīng)”HID 報(bào)告與設(shè)備模型2.1 HID 設(shè)備為什么能免驅(qū)動(dòng)鍵盤、鼠標(biāo)插到電腦上就能用你覺得理所當(dāng)然但這背后其實(shí)是 HID 協(xié)議在起作用。HID 全稱 Human Interface Device它不是指某一種具體的設(shè)備而是一套通信標(biāo)準(zhǔn)。設(shè)備只要按照這套標(biāo)準(zhǔn)向主機(jī)描述自己操作系統(tǒng)就能用內(nèi)置的通用驅(qū)動(dòng)和它對(duì)話這就是“免驅(qū)”的真相。每臺(tái) HID 設(shè)備內(nèi)部都有一份“報(bào)告描述符”里面寫清楚設(shè)備有幾個(gè)輸入通道、每個(gè)通道的數(shù)據(jù)多寬、某一段字節(jié)代表什么含義。OS 閱讀這份描述符后就能正確解析設(shè)備發(fā)來的數(shù)據(jù)。瀏覽器里的device.collections就是把這些描述符信息暴露給前端的結(jié)果你可以在里面查到集合的usagePage、usage以及對(duì)應(yīng)的輸入輸出報(bào)告。WebHID 做的事情本質(zhì)上是讓頁面的 JavaScript 也能“看見”并讀寫這些報(bào)告。舉個(gè)例子很多 USB 條碼掃描槍在出廠時(shí)默認(rèn)模擬鍵盤輸入它掃描到條碼后會(huì)像鍵盤一樣把字符逐個(gè)敲進(jìn)當(dāng)前聚焦的輸入框。這就是為什么以前你打開一個(gè)記事本掃一下條碼文字就出現(xiàn)在光標(biāo)處。這種模式不需要任何開發(fā)但體驗(yàn)并不好因?yàn)閽呙铇寱?huì)“搶占”鍵盤焦點(diǎn)如果在網(wǎng)頁上用恰恰可能把數(shù)據(jù)打到不該打的輸入框里。聰明的做法是把掃描槍切換到“原始 HID 模式”讓瀏覽器通過 WebHID 直接讀取掃描結(jié)果而不是模擬鍵盤鍵入。這種設(shè)備形態(tài)的靈活切換正是前面說的“發(fā)散創(chuàng)新”的起點(diǎn)。2.2 輸入報(bào)告、輸出報(bào)告、功能報(bào)告的區(qū)別在 HID 協(xié)議里數(shù)據(jù)通過“報(bào)告”來傳輸。有三種報(bào)告輸入報(bào)告、輸出報(bào)告和功能報(bào)告。我用一個(gè)生活化的類比解釋一下輸入報(bào)告是設(shè)備主動(dòng)對(duì)主機(jī)“喊話”比如刷卡器刷到一張卡立刻把一串卡號(hào)數(shù)據(jù)發(fā)給瀏覽器輸出報(bào)告是主機(jī)對(duì)設(shè)備“下指令”比如讓一個(gè)帶震動(dòng)馬達(dá)的讀卡器“滴”一聲并閃一下綠燈功能報(bào)告則像是設(shè)備的“設(shè)置項(xiàng)”通常用于讀寫設(shè)備內(nèi)部配置比如修改讀卡器蜂鳴器音量或者調(diào)整掃描槍的掃描模式。開發(fā)時(shí)對(duì)應(yīng)關(guān)系也很清楚。輸入報(bào)告通過inputreport事件接收event.data就是一個(gè)DataView里面就是設(shè)備發(fā)來的原始字節(jié)。輸出報(bào)告通過sendReport()發(fā)送發(fā)的時(shí)候要帶上報(bào)告 ID 和字節(jié)負(fù)載。功能報(bào)告則用receiveFeatureReport()和sendFeatureReport()讀寫。你需要關(guān)心的完整數(shù)據(jù)鏈路就是設(shè)備產(chǎn)生數(shù)據(jù) → 系統(tǒng) HID 棧接收 → 瀏覽器觸發(fā)inputreport事件 → 頁面 JS 解析字節(jié) → 業(yè)務(wù)邏輯處理。2.3 從 navigator.hid 到 inputreport 的數(shù)據(jù)鏈路看一段最簡(jiǎn)單的核心代碼你就能理解整套鏈路。用戶點(diǎn)按鈕 →navigator.hid.requestDevice彈出系統(tǒng)設(shè)備選擇器 → 用戶選設(shè)備 →device.open()打開通道 → 監(jiān)聽inputreport接收數(shù)據(jù)。let device null; async function connectHID() { // 必須由用戶手勢(shì)觸發(fā)瀏覽器會(huì)彈窗讓用戶選擇設(shè)備 const devices await navigator.hid.requestDevice({ filters: [ { vendorId: 0x1234 }, // 按廠商 ID 過濾 { usagePage: 0xff00 } // 或者按用途頁過濾 ] }); if (devices.length 0) { console.log(沒有選擇設(shè)備); return; } device devices[0]; await device.open(); // 打開設(shè)備通道 device.addEventListener(inputreport, (event) { const data event.data; console.log(收到輸入報(bào)告reportId:, event.reportId); console.log(原始字節(jié):, data); // 按設(shè)備協(xié)議解析 data const cardNumber parseCardNumber(data); handleCard(cardNumber); }); }requestDevice里返回的是一個(gè)HIDDevice對(duì)象它可以有多個(gè)集合device.collections每個(gè)集合對(duì)應(yīng)一組輸入/輸出/功能報(bào)告。大多數(shù)消費(fèi)類設(shè)備只有一個(gè)集合所以初學(xué)階段不必過度糾結(jié)繼續(xù)往下做就行。DataView的讀取方式后面我會(huì)專門講因?yàn)樗鼱砍兜阶止?jié)序和數(shù)據(jù)寬度是坑最多的地方。3. 實(shí)操第一站把一臺(tái) HID 刷卡器變成網(wǎng)頁的數(shù)據(jù)源3.1 用戶手勢(shì)與權(quán)限彈窗這是安全邊界的關(guān)鍵第一次跑通 WebHID 的時(shí)候我最意外的就是requestDevice必須由用戶手勢(shì)觸發(fā)。也就是說你不能在頁面加載后就悄悄請(qǐng)求設(shè)備必須放在一個(gè)明確點(diǎn)擊事件的回調(diào)里。這是瀏覽器的安全模型決定的訪問外設(shè)是敏感操作必須讓用戶明確知道并主動(dòng)授權(quán)。在彈窗里瀏覽器的設(shè)備選擇器會(huì)列出所有匹配當(dāng)前過濾條件的 HID 設(shè)備。過濾器可以按vendorId、productId、usagePage、usage來寫。如果沒傳過濾器彈窗里會(huì)列出所有可訪問的 HID 設(shè)備。但有一點(diǎn)要特別注意鍵盤、鼠標(biāo)這類“系統(tǒng)受保護(hù)設(shè)備”默認(rèn)不會(huì)出現(xiàn)在選擇列表里瀏覽器不會(huì)允許網(wǎng)頁隨意讀取用戶鍵盤輸入。這是刻意設(shè)計(jì)的防止惡意網(wǎng)頁偷偷記錄按鍵。開發(fā)時(shí)如果你調(diào)試的設(shè)備恰好碰了這些類目要么換一個(gè)非保護(hù)的 HID 設(shè)備要么在瀏覽器實(shí)驗(yàn)設(shè)置里暫時(shí)關(guān)閉保護(hù)僅限本機(jī)調(diào)試不推薦在生產(chǎn)環(huán)境做。權(quán)限選擇的第二層是“持久性”。用戶授權(quán)某個(gè)站點(diǎn)訪問某個(gè)設(shè)備之后這個(gè)授權(quán)會(huì)被瀏覽器記住下次打開頁面時(shí)可以直接requestDevice或者用getDevices()枚舉到之前授權(quán)的設(shè)備不需要再次彈窗。這一點(diǎn)對(duì)“免配置”的體驗(yàn)相當(dāng)重要設(shè)備插上、頁面一開直接就能用。不過也要小心如果權(quán)限記錄太順對(duì)設(shè)備安全并不完全是好事所以用戶仍然可以在站點(diǎn)設(shè)置里撤銷授權(quán)。3.2 讀取輸入報(bào)告并解析卡號(hào)數(shù)據(jù)我做演示項(xiàng)目用的是一臺(tái)比較常見的 HID 刷卡器它會(huì)把卡片序列號(hào)按 ASCII 字符編碼成一段字節(jié)流發(fā)上來。假設(shè)協(xié)議格式固定為前 3 個(gè)字節(jié)是廠商前綴ESC 設(shè)備類型接著是 10 個(gè) ASCII 字符的卡號(hào)最后 2 個(gè)字節(jié)是回車換行?？梢灾苯舆@樣解析device.addEventListener(inputreport, (event) { const view event.data; if (view.byteLength 15) { console.warn(數(shù)據(jù)長(zhǎng)度不足可能不是完整報(bào)告); return; } // 讀取前3字節(jié)判斷是否為預(yù)期的前綴 const prefix String.fromCharCode( view.getUint8(0), view.getUint8(1), view.getUint8(2) ); if (prefix ! \x1bR1) { console.log(未知前綴:, prefix); return; } // 從第3字節(jié)開始讀取10個(gè)ASCII字符 let cardNumber ; for (let i 3; i 13; i) { cardNumber String.fromCharCode(view.getUint8(i)); } cardNumber cardNumber.trim(); console.log(解析到卡號(hào):, cardNumber); document.getElementById(cardOutput).textContent cardNumber; });這里要提醒兩點(diǎn)。第一不要以為數(shù)據(jù)一定是從字節(jié) 0 開始就是有效內(nèi)容。真實(shí)設(shè)備往往會(huì)有前綴、校驗(yàn)位甚至?xí)锌勺冮L(zhǎng)度字段。一定要先打印原始字節(jié)對(duì)照設(shè)備協(xié)議說明來解析。第二字節(jié)流里的很多字段可能是“文本”而非“數(shù)字”尤其是卡號(hào)、廠商信息。直接讀單字節(jié)轉(zhuǎn)字符是通用做法但如果內(nèi)容是 Unicode就要按設(shè)備協(xié)議指定的編碼方式處理別上來就假設(shè)是 ASCII。還有一種場(chǎng)景設(shè)備發(fā)的數(shù)據(jù)不是一條完整報(bào)告而是跨報(bào)告分段傳的。比如一次掃碼內(nèi)容太長(zhǎng)設(shè)備拆成了兩個(gè)輸入報(bào)告。這時(shí)候需要自己維護(hù)一個(gè)拼接緩沖區(qū)等收到結(jié)束標(biāo)志后再處理。這類邏輯對(duì)排錯(cuò)能力要求更高我是建議在正式代碼里最好加一個(gè)狀態(tài)機(jī)而不是簡(jiǎn)單回應(yīng)“收到一條”。3.3 通過輸出報(bào)告控制設(shè)備反饋震動(dòng)、指示燈讀數(shù)據(jù)只是第一步。很多 HID 設(shè)備還有輸出通道你可以給設(shè)備發(fā)送指令讓它產(chǎn)生物理反饋。比如讀卡器上有蜂鳴器和 LED 燈你希望在識(shí)別到合法卡后讓設(shè)備“滴”一聲在非法卡時(shí)報(bào)警。這就要用到sendReport()。async function beep(device) { // 以某設(shè)備協(xié)議為例reportId0x01負(fù)載1字節(jié)控制命令 // 0x01 表示短鳴0x02 表示長(zhǎng)鳴0x00 表示關(guān)閉蜂鳴 const reportId 0x01; const data new Uint8Array([0x01]); await device.sendReport(reportId, data); } async function setLED(device, color) { // 假設(shè) reportId0x02負(fù)載3字節(jié) RGB const reportId 0x02; const data new Uint8Array(color); // [R, G, B] await device.sendReport(reportId, data); }輸出報(bào)告的格式由設(shè)備協(xié)議決定device.collections里的描述符能幫你確認(rèn)存在哪些輸出報(bào)告以及可用的reportId。我遇到過一些設(shè)備sendReport的reportId必須寫描述符里的實(shí)際 ID如果寫 0 可能在某些設(shè)備上觸發(fā)“空 ID”沖突。所以不要憑感覺猜先打印device.collections看輸出報(bào)告結(jié)構(gòu)再準(zhǔn)備數(shù)據(jù)。還有一點(diǎn)sendReport是異步操作調(diào)用時(shí)最好加上超時(shí)保護(hù)。有些設(shè)備接收指令后并不給任何 ACK如果鏈路狀態(tài)異常await可能永遠(yuǎn)掛起。我一般在外面包一層Promise.race超時(shí) 3 秒就放棄并提示用戶檢查設(shè)備連接。4. 發(fā)散創(chuàng)新案例會(huì)議室面板、掃描槍收銀臺(tái)和宏鍵盤配置頁4.1 會(huì)議室物理快捷鍵面板十行代碼替代定制小程序先說一個(gè)我實(shí)際做過的場(chǎng)景。一個(gè)會(huì)議室里裝了一塊 USB 按鈕面板上面有四五個(gè)大按鈕用來控制投影切換、幕布升降、燈光情景模式。傳統(tǒng)做法是要么買一套定制中控系統(tǒng)要么找廠商寫小程序控制。其實(shí)按鈕面板本身就是一個(gè)標(biāo)準(zhǔn) HID 設(shè)備每個(gè)按鈕按下后會(huì)發(fā)送一個(gè)輸入報(bào)告里面記錄了按鈕編號(hào)和狀態(tài)。用 WebHID 來做邏輯短得不可思議。頁面打開后監(jiān)聽inputreport每個(gè)按鈕對(duì)應(yīng)一個(gè)usage值或者字節(jié)位置按下時(shí)調(diào)用相應(yīng)業(yè)務(wù)函數(shù)即可。比如按鈕 1 對(duì)應(yīng)getUint8(0) 1按下就觸發(fā)“切換投影信號(hào)源”。這個(gè)方案的好處是管理后臺(tái)和會(huì)議室控制界面都可以直接做成網(wǎng)頁部署在一臺(tái)迷你主機(jī)上打開瀏覽器就能全屏運(yùn)行。前端開發(fā)者一個(gè)人就能搞定不需要專門的中控開發(fā)環(huán)境。有人可能會(huì)問為什么不用 WebSocket 或局域網(wǎng)協(xié)議直接控制設(shè)備你問到了關(guān)鍵點(diǎn)。如果控制設(shè)備本身支持網(wǎng)絡(luò)通信那當(dāng)然走網(wǎng)絡(luò)更好。但很多物理按鈕、面板、腳踏板本質(zhì)上只是 USB HID 設(shè)備并沒有 TCP/IP 接口。你要么給它們配一個(gè)網(wǎng)關(guān)盒子做協(xié)議轉(zhuǎn)換要么就用瀏覽器直連。WebHID 正是后者的最優(yōu)解。4.2 掃描槍與網(wǎng)頁收銀臺(tái)把整個(gè)桌面收銀流程搬進(jìn)瀏覽器條碼掃描槍在市面上有兩種工作模式。第一種是“鍵盤模擬模式”出廠默認(rèn)掃一下條碼就像鍵盤打字一樣把內(nèi)容輸入光標(biāo)處。第二種是“原始 HID 模式”掃描槍作為 HID 設(shè)備直接輸出報(bào)告網(wǎng)頁可以精確地拿到掃描結(jié)果。收銀場(chǎng)景下我曾經(jīng)接過一個(gè)內(nèi)部演示需要在網(wǎng)頁收銀臺(tái)里支持掃碼錄入商品并且不希望掃描槍搶走鍵盤焦點(diǎn)。用鍵盤模擬模式實(shí)在難受因?yàn)轫撁娴帽ＷC用戶始終把焦點(diǎn)落在一個(gè)輸入框里稍有偏差數(shù)據(jù)就不知道飛到哪去了。切換到原始 HID 模式后掃描槍的數(shù)據(jù)被inputreport事件帶給頁面跟焦點(diǎn)完全無關(guān)體驗(yàn)特別穩(wěn)。你還可以在頁面里同時(shí)處理掃碼輸入和鍵盤快捷鍵兩者互不干擾。這樣做還有一個(gè)額外好處頁面可以在解析出條碼后立刻去查數(shù)據(jù)庫匹配商品后自動(dòng)加入訂單整個(gè)過程不需要回車鍵干預(yù)。當(dāng)然這里有個(gè)前置條件掃描槍必須能被配置成原始 HID 模式。大多數(shù)工業(yè)級(jí)掃描槍都支持這個(gè)選項(xiàng)有的通過掃描特定配置碼改變模式有的需要廠商工具下發(fā)配置。動(dòng)手前先查設(shè)備手冊(cè)或者問一下廠商技術(shù)支持確認(rèn)它支持 HID 原生報(bào)告模式。如果設(shè)備只支持鍵盤模擬WebHID 也能看到它但讀到的只是“鍵盤按鍵事件”處理起來會(huì)很別扭。4.3 宏鍵盤的云端配置頁免驅(qū)免軟件再說一個(gè)我認(rèn)為特別有價(jià)值的“發(fā)散”方向給外設(shè)做基于瀏覽器的配置工具。很多宏鍵盤、自定義控制鍵盤、可編程按鈕面板廠商都需要用戶安裝一個(gè)配套軟件來配置按鍵映射。這個(gè)軟件往往只支持 Windows有的還要求注冊(cè)賬號(hào)。背后原因很簡(jiǎn)單廠商不想做一個(gè)跨平臺(tái)客戶端成本太高。WebHID 直接給了廠商一條更輕的路。設(shè)備接入網(wǎng)頁后網(wǎng)頁通過功能報(bào)告或輸出報(bào)告把宏定義表寫入設(shè)備內(nèi)部 Flash。用戶在瀏覽器里就能自定義按鍵、設(shè)置連發(fā)速度、配置燈光顏色甚至還能把配置導(dǎo)出成 JSON 文件存在本地。我模擬過這個(gè)思路設(shè)備每次連接后瀏覽器讀取設(shè)備配置報(bào)告的校驗(yàn)值如果發(fā)現(xiàn)和云端最新配置不一致就自動(dòng)彈窗詢問用戶是否同步配置。整體體驗(yàn)比裝一個(gè) 200MB 的客戶端利落得多而且天然跨平臺(tái)。這背后的關(guān)鍵點(diǎn)是 HID 設(shè)備通常都支持“功能報(bào)告”Feature Report讀寫配置sendFeatureReport和receiveFeatureReport兩個(gè) API 專門干這個(gè)。結(jié)構(gòu)類似sendReport但它訪問的不是輸入輸出管道而是一組獨(dú)立的配置管道非常適合做“設(shè)備設(shè)置應(yīng)用”。開發(fā)者需要仔細(xì)閱讀設(shè)備的 HID 協(xié)議文檔了解哪些報(bào)告 ID 對(duì)應(yīng)哪些配置項(xiàng)避免誤寫進(jìn)系統(tǒng)保護(hù)的配置段。5. 實(shí)戰(zhàn)過程中繞不開的坑占用、字節(jié)序與斷線重連5.1 設(shè)備被占用Windows 上的經(jīng)典報(bào)錯(cuò)我在演示項(xiàng)目里第一次連設(shè)備時(shí)一切順利但當(dāng)我開兩個(gè)瀏覽器標(biāo)簽頁同時(shí)訪問同一臺(tái)設(shè)備時(shí)第二個(gè)頁面就崩了。原因是系統(tǒng)不允許同一個(gè) HID 設(shè)備的句柄被多個(gè)上下文同時(shí)打開。第一個(gè)頁面已經(jīng)device.open()把設(shè)備獨(dú)占第二個(gè)頁面再打開瀏覽器拋出了“設(shè)備已被占用”的錯(cuò)誤。遇到這種情況先檢查有沒有其他標(biāo)簽頁、其他網(wǎng)頁應(yīng)用正連著同一臺(tái)設(shè)備。網(wǎng)頁端只能單頁面持有設(shè)備的訪問權(quán)其他頁面如果也要用需要做好互斥設(shè)計(jì)比如用一個(gè)全局鎖標(biāo)志或者在頁面之間通過 Local Storage 通信避免同時(shí)發(fā)起open()。設(shè)備層面的占用還有另一種情況該設(shè)備正被某個(gè)系統(tǒng)進(jìn)程或其他本地軟件使用。Windows 上尤其常見比如廠商的官方配置軟件如果正在后臺(tái)跑會(huì)一直占著設(shè)備網(wǎng)頁怎么open都失敗。解決方式是先關(guān)掉那些常駐軟件或者讓用戶手動(dòng)拔插一次設(shè)備。對(duì)于可以預(yù)見的崩潰場(chǎng)景頁面應(yīng)該監(jiān)聽disconnect事件并給出友好提示。HID 設(shè)備從 USB 口拔掉時(shí)瀏覽器會(huì)觸發(fā)這個(gè)事件你可以把界面狀態(tài)切成“設(shè)備未連接”引導(dǎo)用戶重新插上。別等到用戶自己發(fā)現(xiàn)“怎么沒反應(yīng)了”才去排查。5.2 報(bào)告解析錯(cuò)位字節(jié)序和數(shù)據(jù)寬度HID 報(bào)告里的數(shù)據(jù)有很多是超過單字節(jié)的比如一個(gè) 16 位的開關(guān)狀態(tài)、一個(gè) 32 位的累計(jì)脈沖數(shù)。解析這類數(shù)據(jù)時(shí)最容易栽在字節(jié)序上。多數(shù) HID 設(shè)備在傳輸多字節(jié)數(shù)值時(shí)按照小端序低字節(jié)在前但也有很多設(shè)備按大端傳。用DataView的方法時(shí)顯式聲明端序是一個(gè)好習(xí)慣// 讀取一個(gè) 16 位無符號(hào)整數(shù)使用小端序 const value16 view.getUint16(offset, true); // 讀取一個(gè) 32 位無符號(hào)整數(shù)使用大端序 const value32 view.getUint32(offset, false);建議寫一個(gè)統(tǒng)一的解析工具函數(shù)傳入偏移量和寬度然后統(tǒng)一用設(shè)備文檔里確認(rèn)的端序去讀。千萬別依賴默認(rèn)值不同環(huán)境的DataView默認(rèn)端序可能是大端一旦忽略所有多字節(jié)字段都會(huì)錯(cuò)位而且這種 bug 很難直觀發(fā)現(xiàn)你只會(huì)覺得數(shù)據(jù)怎么忽對(duì)忽錯(cuò)。另一個(gè)容易漏的坑是報(bào)告 ID。有些設(shè)備每個(gè)報(bào)告的reportId不一定為 0解析數(shù)據(jù)時(shí)不能把event.reportId當(dāng)成數(shù)據(jù)的一部分。正確做法是數(shù)據(jù)總是從DataView的byteOffset 0開始reportId是事件屬性不是數(shù)據(jù)內(nèi)容。5.3 連接斷開的自動(dòng)重連外設(shè)這東西經(jīng)常“說沒就沒”。USB 線松了、設(shè)備休眠后喚醒失敗、系統(tǒng)電源管理把設(shè)備掛起都會(huì)導(dǎo)致連接斷開。我在做過一次演示時(shí)臺(tái)下設(shè)備剛好休眠頁面直接卡死在無響應(yīng)狀態(tài)。從那以后我對(duì)所有 WebHID 代碼都做了一個(gè)要求必須包含自動(dòng)重連邏輯。監(jiān)聽disconnect事件觸發(fā)后進(jìn)入“重連”狀態(tài)let reconnecting false; device.addEventListener(disconnect, () { console.warn(設(shè)備已斷開); device null; if (!reconnecting) { scheduleReconnect(); } }); function scheduleReconnect() { reconnecting true; // 每 3 秒嘗試重新枚舉已授權(quán)的設(shè)備并打開 const timer setInterval(async () { const devices await navigator.hid.getDevices(); if (devices.length 0) { device devices[0]; await device.open(); bindEvents(device); clearInterval(timer); reconnecting false; console.log(重連成功); } }, 3000); }navigator.hid.getDevices()返回的是當(dāng)前站點(diǎn)已獲得授權(quán)的設(shè)備不需要重新彈窗這讓靜默重連成為可能。用戶拔插之后瀏覽器會(huì)再次枚舉到設(shè)備頁面就能自動(dòng)恢復(fù)。如果需要重新授權(quán)那就只能再次調(diào)用requestDevice這就必須依賴用戶點(diǎn)擊了。自動(dòng)重連還有一個(gè)細(xì)節(jié)重連成功后之前添加的inputreport監(jiān)聽器并不會(huì)自動(dòng)恢復(fù)到新設(shè)備對(duì)象上必須重新addEventListener所以最好把事件綁定封裝成一個(gè)獨(dú)立函數(shù)。6. 安全模型與瀏覽器兼容性的真實(shí)邊界6.1 權(quán)限邊界必須 HTTPS、用戶手勢(shì)、受限設(shè)備WebHID 不是任何人打開一個(gè)網(wǎng)頁就能隨便讀你外設(shè)的。它有幾道安全邊界。第一頁面必須運(yùn)行在安全上下文中也就是 HTTPS 或者localhost。你在公網(wǎng)上搞一個(gè) HTTP 頁面navigator.hid根本不會(huì)存在。第二requestDevice必須由用戶點(diǎn)擊手勢(shì)觸發(fā)頁面加載時(shí)不能主動(dòng)彈窗。第三系統(tǒng)會(huì)默認(rèn)隱藏受保護(hù)的 HID 設(shè)備比如鍵盤、鼠標(biāo)防止惡意頁面監(jiān)聽輸入。這三道邊界合在一起把 WebHID 的濫用風(fēng)險(xiǎn)壓到了比較低的水平。但開發(fā)者也得負(fù)起責(zé)任。網(wǎng)頁拿到設(shè)備數(shù)據(jù)后會(huì)不會(huì)加密傳輸設(shè)備的原始數(shù)據(jù)會(huì)不會(huì)被無關(guān)第三方看到如果頁面本身被注入了惡意腳本設(shè)備數(shù)據(jù)可能一起泄露。做過這類應(yīng)用的人應(yīng)該明白數(shù)據(jù)脫敏和訪問控制比功能本身更重要。例如刷卡器的卡號(hào)屬于敏感信息不應(yīng)該被偷偷外發(fā)到未知服務(wù)端。6.2 兼容性現(xiàn)狀與降級(jí)方案目前 WebHID 的支持情況不能算遍地開花但對(duì)有意采用的人已經(jīng)夠用。支持 Chrome 和 Edge 的桌面版本Opera 也有跟進(jìn)。Firefox 和 Safari 一直沒放開移動(dòng)端瀏覽器的支持也比較有限。如果你的用戶畫像鎖定在需要接 USB 外設(shè)的桌面工作者比如收銀、實(shí)驗(yàn)室、會(huì)議室管理那 Chrome/Edge 覆蓋率高得完全可以用。反之如果你的用戶拿著手機(jī)瀏覽器訪問WebHID 就不是可行方案。安排降級(jí)方案時(shí)常用的一個(gè)思路是先檢測(cè)navigator.hid是否存在不存在就給用戶展示“當(dāng)前瀏覽器不支持請(qǐng)安裝 Chrome/Edge”的提示。對(duì)于支持但總線不穩(wěn)的場(chǎng)景前面說的重連邏輯能兜底。如果你的場(chǎng)景必須在不支持 WebHID 的瀏覽器里也工作那就只能退回老的中間件方案或本地服務(wù)方案這一點(diǎn)要在項(xiàng)目啟動(dòng)前就想清楚別做到一半才發(fā)現(xiàn)瀏覽器不支持。6.3 設(shè)備出廠前可以做的幾件事如果你恰好是設(shè)備廠商或開源硬件愛好者想讓自己的新設(shè)備完美適配 WebHID有幾點(diǎn)可以提前規(guī)劃。第一編寫清晰完整的 HID 報(bào)告描述符把每個(gè)字段的含義、偏移、長(zhǎng)度都定義清楚第二優(yōu)先使用標(biāo)準(zhǔn)的usagePage和usage這樣瀏覽器可以正確分類設(shè)備第三避免讓設(shè)備模擬鍵盤發(fā)送數(shù)據(jù)盡量提供原生 HID 報(bào)告模式第四提供獨(dú)立的配置報(bào)告方便網(wǎng)頁端做免驅(qū)配置。這些細(xì)節(jié)決定了開發(fā)者接入你的設(shè)備時(shí)是 10 分鐘搞定還是抓瞎兩天。我在實(shí)際使用中發(fā)現(xiàn)一個(gè)很有用的調(diào)試習(xí)慣做 WebHID 開發(fā)時(shí)先用 Chromium 系瀏覽器打開chrome://device-log這里能看到系統(tǒng)底層對(duì)該 USB 設(shè)備的枚舉和報(bào)告?zhèn)鬏斎罩?。遇到設(shè)備沒反應(yīng)、報(bào)告沒收到這里往往能直接看出是系統(tǒng)沒識(shí)別還是報(bào)告根本沒發(fā)出來。另一個(gè)習(xí)慣是先把設(shè)備的collections結(jié)構(gòu)和原始報(bào)告字節(jié)完整打印到控制臺(tái)對(duì)照設(shè)備文檔核對(duì)一遍再進(jìn)行開發(fā)而不是拿著猜測(cè)的協(xié)議直接寫解析代碼。這個(gè)習(xí)慣幫我省過無數(shù)次返工。如果你在考慮把某個(gè)桌面流程遷移到瀏覽器我建議優(yōu)先挑那些“設(shè)備本身是 HID、當(dāng)前卻要靠本地軟件驅(qū)動(dòng)”的場(chǎng)景。刷卡、掃碼、按鈕控制、宏配置這幾個(gè)方向我都跑通了普適性很強(qiáng)。真正要注意的反而是業(yè)務(wù)層面的思考頁面拿到設(shè)備數(shù)據(jù)之后要做什么、權(quán)限怎么管、設(shè)備掉線怎么辦。把這些問題想透WebHID 用起來還是很趁手的。