接了三年USB设备，每次都要写原生代码——今天浏览器把这件事彻底变了

移动端场景下，接入一个 USB 硬件，传统做法是：下载厂商驱动 → 配环境 → 写原生桥接代码 → 打包 App。用户要装 App，开发者要维护多端 SDK，说到底是因为浏览器里的 USB 权限被锁死了。

Chrome 128 带来了 Unrestricted WebUSB，结合 Isolated Web Apps（IWA）模型，移动端浏览器第一次可以绕过原来的黑名单限制，直接和以前只有原生 App 才能碰的设备通信。

Unrestricted WebUSB 到底解了什么

标准 WebUSB 有一个接口黑名单（HID、大容量存储、智能卡、无线控制器等），这些设备类被浏览器主动屏蔽，原因是它们拿到低层访问权限后风险太高。但 Unrestricted WebUSB 给出了一个条件：通过 IWA 的信任模型——即应用需要管理员或浏览器签名验证权限声明——把这个黑名单放行。

W3C WICG 的 Unrestricted WebUSB Explainer 说得很清楚：这个能力只授权给 Isolated Web Apps，普通网页拿不到。这意味着手机浏览器里一个普通的 HTTP 网站，还是碰不了这些设备。

IWA 隔离模型让这件事在移动端也成立

Isolated Web Apps 和普通 PWA 的核心区别在于它跑在独立协议（isolated-app://）上，和正常浏览上下文完全隔离。Chrome 128 在 ChromeOS 企业托管设备上正式支持 IWA 安装，这个模型向移动端蔓延只是时间问题。

Google Chrome for Developers 的 IWA 开发者政策明确列出：Unrestricted WebUSB 允许操作没有高层 Web API 可用的专有或传统硬件，比如工业控制器。同时禁止用它绕过专用 API——智能卡要用 Smart Card API，外接存储要用 File System Access API。

这对移动端场景意味着什么

医疗仪器、工业传感器、老型号打印机——这些设备在移动端长期没有好的接入方案，必须装厂商原生 App。Unrestricted WebUSB + IWA 让浏览器有能力成为这个桥梁，而且是跨平台的，一次开发安卓和 ChromeOS 都能用。

对于前端工程师来说，这件事的信号是：浏览器正在成为真正的应用运行时。USB 权限模型打开的口子，和 Web Bluetooth、Web Serial 一起，正在把只有原生 App 能做的事一件一件还给 Web。

下一步可以做的：如果你有现成的 WebUSB 应用，现在可以评估迁移到 IWA 模型；如果你维护的硬件在等一个移动端 Web 方案，这可能是最近三年最接近答案的一次机会。