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