用串口调试这件事Windows用户有SSCOM、XCOMmacOS用户有CoolTerm、screen命令Linux用户又得翻出CuteCom或者minicom。每一次换电脑、换系统都得重新找工具、重新配环境数据线和板子没变折腾的时间倒是翻了几倍。我最近半年频繁在Windows笔记本和MacBook之间切换调试ESP32和STM32实在受不了这种碎片化的工具链才开始认真尝试基于Web Serial API的在线串口调试工具。试过几款之后发现这类工具在跨平台场景下确实能解决大部分日常调试需求而且功能比我预想的要完整得多。这篇文章把我实际测试过的几款在线串口调试工具、完整的连接流程、以及踩过的坑都整理出来。如果你经常在三套系统之间切换调试或者刚入行不想装一堆桌面软件这份经验应该能直接帮你省下不少时间。1. 串口调试的跨平台困境为何总在换工具1.1 从SSCOM到screen碎片化的工具生态先说说我为什么对这事这么执着。做嵌入式开发的人都知道串口调试工具几乎可以说是每天都要摸的家伙。但是我翻了一下自己电脑里装过的工具列表Windows上有过SSCOM、XCOM、友善串口助手macOS上试过CoolTerm、串口猎人Linux下折腾过minicom、CuteCom、picocom。每换一个平台都要重新熟悉一遍界面布局、快捷键、配置方式更别提那些老旧的工具在Win10/Win11上动不动就崩溃、乱码、丢数据的问题。举一个很具体的例子在Windows上用惯了SSCOM的按十六进制发送和自动加校验位的功能到了macOS上的CoolTerm这些功能虽然也有但位置完全不同CKD、流控的配置方式也不一样。而用Linux的minicom时连退出都要先按CtrlA再按X第一次用的时候我卡了半天没退出去直接关了终端结果串口还被进程占着第二次打开直接报Device or resource busy。这些工具本身都没问题问题在于每个平台、每个工具都有自己的脾气。如果只是偶尔跨平台还好但如果你像我一样上午用Windows连STM32烧录调试下午切到Mac写Python脚本读传感器数据晚上又要在Linux服务器上跑一段串口通信的测试程序那这套工具切换的成本就非常可观了。1.2 在线方案的价值一次部署三平台通用在线串口调试工具的核心思路是串口通信的逻辑全部跑在浏览器里通过Web Serial API直接访问系统串口你在任何能装Chrome或Edge的平台上打开同一个网址就能看到一模一样的界面、用一模一样的配置方式、一模一样的快捷键。这意味着什么意味着可以彻底告别换平台就换工具的循环。在Windows上调试好的波特率、数据位、校验位配置到Mac上打开同一个页面重新选一下串口号就能直接干活。我没有专门去重新学习一套新工具的界面逻辑因为用的是同一个工具。更重要的是在线工具天然具备跨设备的可移植性。我有一台安装了Linux的开发服务器平时放在机房里跑数据采集程序需要临时看一眼串口输出的时候不用再SSH进去找minicom配半天直接在本地浏览器打开在线工具选一下远程机器上映射过来的串口设备就行。这一条在实际工作中省下的时间比我预想的要多得多。2. Web Serial API在线串口调试的技术底座2.1 浏览器直连串口的原理与限制在线串口调试工具能跑起来靠的是Chrome和Edge浏览器内置的Web Serial API。这个API本质上允许网页通过系统串口驱动直接读写数据不需要在浏览器外安装任何插件或客户端。它做的事情很简单网页调用navigator.serial.requestPort()弹出设备选择框用户选中目标串口后网页拿到端口对象并调用open()方法配置波特率之后就可以通过readable和writable两个数据流进行收发。这里最关键的一个点是浏览器本身不包含任何串口驱动它依赖的是操作系统已经安装好的、可被常规桌面软件调用的串口驱动。也就是说系统里插上USB转串口模块CP2102、CH340、FT232等后只要能出现在设备管理器或系统信息里Web Serial API通常就能访问到。它并不是绕过驱动而是站在驱动之上做了一层标准化的访问接口。限制也同样明显首先是浏览器兼容性Web Serial API目前只在Chrome和Edge都是Chromium内核中可用Firefox和Safari都不支持这就意味着如果你只有Safari在线方案就走不通。其次出于安全性考虑API要求页面必须运行在HTTPS协议或localhost环境下普通HTTP页面无法调用串口。最后是权限模型浏览器每次连接串口都需要用户手动点击授权这既是安全机制也意味着脚本完全自动化操作串口的路径被切断了。2.2 为什么是Chrome/Edge而不是Firefox我测试的时候专门对比过Firefox和Chrome。Firefox对Web Serial API的支持一直是正在实现状态直到我写完这篇文章的时点普通用户版的Firefox依然无法直接调用串口。Safari更是完全没有这个计划。所以在实际部署的时候我会直接告诉同事用Chrome或者Edge其他浏览器别折腾了。Win10和Win11自带的Edge其实就是Chromium内核所以Windows用户基本不用额外装任何东西macOS用户需要装一个ChromeLinux用户如果装的是Chrome需要注意Google官方源在你的发行版上是否可用如果不行可以用Chromium开源版内核一样Web Serial功能没差别。还有一个容易被忽略的细节Chrome浏览器本身如果开启了安全浏览增强模式某些在线串口工具的域名如果没有备案或证书不完整会被直接拦截。我遇到过一次serialterminal.com在Chrome里面正常打开但同事的Chrome因为开了严格安全模式页面被警告恶意软件的情况。这个不一定是工具本身有问题但确实值得留意。3. 实测推荐三款可用在线串口调试工具3.1 Serial Terminal Online功能最完整的在线方案我主力使用的在线串口调试工具是Serial Terminal Online网址是serialterminal.com。这款工具的功能完整度可以说超出了我对在线工具的预期。界面分区非常清晰左侧是串口配置区可以选择端口、设置波特率、数据位、停止位、校验位、流控右侧是数据显示区支持ASCII和Hex两种显示模式底部是发送区支持文本发送和Hex发送还可以设置定时发送。我重点测试了它的Hex收发能力。做单片机开发时经常需要直接和寄存器打交道发送0x01 0x03 0x00 0x00 0x00 0x0A 0xC5 0xCD这种Modbus指令在Serial Terminal Online里直接把Hex输入框填好点发送返回的数据会自动按Hex和ASCII两种形式同时显示出来。这个功能在调试传感器协议时帮了大忙能直观地看到字节与ASCII字符的对应关系。它还支持日志导出。调试过程中数据刷得很快肉眼根本看不过来Serial Terminal Online可以把接收区的所有内容一键导出为TXT文件保存后可以慢慢翻也可以用脚本处理。实测导出一个小时连续接收的数据大约几万行文件生成速度和完整性都很好。不过它也有缺点界面是全英文的对部分新手可能不太友好免费版对发送频率有一点限制连续高频发送时偶尔会感觉到卡顿另外它依赖浏览器进程如果标签页被关了正在进行的串口连接会直接断开不像桌面工具关掉窗口还可能最小化到托盘。3.2 Web Serial Terminal轻量快速的开源选择第二款值得推荐的开源项目叫Web Serial Terminal它在GitHub上有完整源码部署特别简单。相比Serial Terminal Online它的界面更朴素但胜在轻量——页面体积小、加载快在低配的Linux工控机上也能流畅运行。这款工具的核心功能没有Serial Terminal Online那么多但基本收发、Hex模式、波特率选择、时间戳显示都有。它的特点是比较克制界面零广告、零冗余打开就是干活的页面。适合那些只是想快速看一眼串口输出、或者跑一个简单环路测试的场景。我一般在Linux服务器上临时调试时会用这个。因为页面很简洁连配置项都少不容易出错。比如我要快速确认某个USB转串口模块的收发是否正常打开页面、选端口、设波特率、发一个AT命令看返回结果整个过程不超过30秒。相比之下如果打开Serial Terminal Online还要面对一堆配置项反而有点杀鸡用牛刀的感觉。需要提醒的是这款开源工具如果在本地部署需要注意用HTTPS或localhost访问否则Web Serial API无法启用。如果直接使用别人搭建的在线版本要确认它的证书是否有效。3.3 备选方案与各自适用场景除了上面两款主力工具我还测试过一些其他方案各有各的适用场景browser-serial-terminal一个基于Node.js的开源项目特点是支持快捷键操作和分组管理比较弱但可以嵌入到其他Web应用中。如果你的工作流是内部系统集成串口调试功能可以参考这个项目做二次开发。Chrome的原生实验工具在Chrome的chrome://flags里开启相关实验项后可以通过开发者工具访问串口。这个方案极其简陋只适合做技术验证不适合日常使用。Wokwi的串口监控器主要在Wokwi仿真环境中使用。如果你在Wokwi里跑ESP32仿真直接在串口监控器里看输出很方便但它是绑定仿真环境的不支持直接访问本机物理串口。这几款工具体验下来日常开发和硬件调试我会优先选Serial Terminal Online极简场景选Web Serial Terminal其他方向更多是特定场景的补充。4. 连接ESP32的完整实测流程4.1 硬件准备与浏览器配置我拿ESP32开发板作为实测对象它板载的USB转串口芯片通常是CP2102或CH340这类芯片在Windows、macOS、Linux下都有成熟的驱动。把开发板用USB线连到电脑上系统会自动识别出一个串口设备。这里有一个很重要的前置步骤确认驱动装好。Windows下打开设备管理器如果看到端口(COM和LPT)里面出现了一个USB Serial Port就说明驱动OKmacOS下打开终端执行ls /dev/tty.*能看到类似/dev/tty.usbserial-0001的设备名Linux下执行ls /dev/ttyUSB*或/dev/ttyACM*能看到对应设备节点。浏览器这边我建议提前做两件事。第一用最新版的Chrome或Edge老版本浏览器对Web Serial API的支持不完整可能出现奇怪的报错。第二如果是Linux系统普通用户访问串口经常遇到权限不足的问题。此时需要把当前用户加入dialout组sudo usermod -a -G dialout $USER然后重新登录一次。如果没做这一步打开在线工具后串口列表里可能根本看不到设备或者选择设备后报Failed to open之类的错误。4.2 波特率、换行符与流控制的设置技巧打开Serial Terminal Online后第一步是点Connect按钮浏览器会弹出设备选择框。选择框里列出的设备是系统当前可访问的所有串口ESP32开发板通常会以设备名称或VID/PID编号的形式出现建议通过试连一个已知设备来确认或者拔插USB线观察列表变化来锁定目标设备。选中设备后进入配置界面波特率选择115200数据位8停止位1校验位None流控关闭。这个组合是ESP32默认的也是最常见的串口参数。如果你的设备用的是9600或者57600改一下波特率就行其他参数基本不用动。在发送区需要重点关注换行符的设置。很多在线工具默认发送时是不附加换行符的而ESP32上的AT固件或命令行交互程序往往要求每条命令以回车换行结尾。如果发现发送命令后设备毫无反应先别怀疑硬件检查一下发送区旁边是不是有个Newline或Line Ending的下拉框把它设成CRLF或LF再试一次。我测试时用ESP32刷了一个简单的回环程序收到什么就返回什么并且在前面加上ECHO前缀。在在线工具里发送hello收到的返回是ECHO: hello收发正常数据没有乱码和丢字节。这就是一个非常标准的最小通信验证。4.3 收发数据验证与日志导出数据验证通过后我再测试一下连续传输的稳定性。给ESP32写了一段每秒打印一次系统运行时间的固件通过在线工具持续接收了大概10分钟输出的时间戳序列没有中断和乱行。期间我试着把发送区定时发送功能打开设置每2秒发送一次状态查询指令status设备的返回也都及时显示在接收区。日志导出的操作很简单在接收区上方找到Download Log或Export按钮点击后浏览器会自动下载一个TXT文件。我导出后看了一下文件里每条记录都保留了时间戳方便后续分析数据与操作之间的对应关系。如果接收到的数据量很大屏幕滚动速度太快导致看不清Serial Terminal Online有一个Pause Display的功能可以暂停刷新显示但后台数据仍在累积。这个功能在处理高速串口数据时非常实用等数据收集得差不多暂停显示后仔细看日志即可不用怕错过任何一条。5. 在线工具的高级玩法脚本、协议调试与浏览器自动化5.1 定时发送与协议序列很多做硬件调试的人忽略了一个事实在线串口工具的界面虽然简单但它的定时发送功能其实可以用来跑简单的协议序列测试。比如我在调试一个温湿度传感器模块时需要按固定顺序发送一组初始化命令再等待设备返回结果。在Serial Terminal Online里我可以把定时发送间隔设为1000ms把初始化命令作为发送内容就能实现每秒发送一次状态查询的效果。更复杂一点有些工具支持通过JavaScript或浏览器控制台直接操作Web Serial API的接口这给了我很大的自动化灵活度。举个例子在浏览器开发者工具的Console里我可以直接执行代码来批量发送指令、读取返回数据甚至实现简单的自动化逻辑。当然这需要一定的前端JavaScript基础但这对做硬件开发的人来说门槛不高。实际上我在调试一段自定义二进制协议时就是靠自己在Console里写了一段循环发送脚本一次跑完了一整轮协议握手测试。5.2 结合浏览器开发者工具做自动化这里展开说一下浏览器自动化调试串口的具体做法。Web Serial API暴露的接口并不复杂核心是navigator.serial对象。我通常在Console里做这样一个流程先通过navigator.serial.requestPort()选择一个端口用port.open({ baudRate: 115200 })建立连接通过port.readable.getReader()读取数据通过port.writable.getWriter()发送数据。在Console里执行完第一步后浏览器会弹出和点击Connect按钮时一样的设备选择框。选择后后续就可以在Console中反复读写了。这种方式让自动化测试变得非常简单比如连续发送100条AT指令并统计返回内容写一个for循环就够了。这段代码的效果是发送一次读取一次把上行的数据和下行的返回都打印出来。它的价值在于不用修改任何固件代码就能对设备进行压力测试和功能验证。// 在Console中选择串口并打开 const port await navigator.serial.requestPort(); await port.open({ baudRate: 115200 }); const reader port.readable.getReader(); const writer port.writable.getWriter(); const encoder new TextEncoder(); await writer.write(encoder.encode(AT\r\n)); const { value } await reader.read(); console.log(new TextDecoder().decode(value));这种做法和在线工具界面操作可以无缝衔接。先用界面手动连接再用Console获取到页面持有的端口对象做二次操作相当于给在线工具加了一个脚本扩展能力。虽然在线工具本身没有提供宏定义、脚本录制这类专业功能但凭借浏览器的开发者工具这些需求都能自己实现。5.3 多人协作远程调试的思路还有一个有趣的使用场景是远程协作调试。传统桌面串口工具只能绑定在本地电脑上如果设备在实验室里而你在办公室或家里就得靠远程桌面或者SSH转发来实现远程调试。在线串口工具的另外一个潜在优势是只要串口连接的设备能被某台电脑访问其他电脑就可以通过浏览器远程连接到这台电脑进行协作。当然这需要配合串口服务器或远程USB设备共享工具并不是在线工具原生支持的。不过当设备物理连接在一台机器上而你在另一台机器上用浏览器打开同一个在线工具时可以把远程机器上的串口映射为本地设备再通过在线工具进行操作。这种方案比远程桌面方案更轻量通信数据都在本地浏览器和本地串口之间流动远程传输的只是系统层的数据包延迟和卡顿感比远程桌面低很多。6. 踩坑记录兼容性、权限与驱动那些事6.1 驱动安装与权限细节在线工具虽然免去了装桌面软件的麻烦但操作系统的串口驱动这一步省不掉。我遇到过最典型的坑是在macOS上插上CH340芯片的开发板系统完全不识别。原因很简单新版macOS对非苹果官方芯片的USB转串口驱动有严格的签名要求CH340的驱动如果没有正确安装且通过系统安全验证就会直接无法使用。解决办法并不复杂去芯片厂商官网下载对应平台的最新驱动安装后在系统设置 - 隐私与安全性里允许加载该驱动然后重启电脑。这里有一个细节不是插上设备就一定要重启但macOS安全策略会拦截未签名的驱动扩展首次加载确实需要重启才能生效。Linux下的权限问题也值得多说一句。很多初学者在Linux下打开在线串口工具发现选不到设备或者选了之后无法打开。除了前面提到的dialout组权限问题还有一个隐蔽的小坑部分Linux发行版做了动态设备权限管理即使当前用户在dialout组里也需要重新插拔一次USB设备让udev重新分配设备节点权限变更才会生效。6.2 断开重连与系统休眠的坑在线工具在断线重连方面有一个体验上的显著差异桌面工具在串口设备被拔掉又插回后通常会保留原来的会话并尝试自动重连而在线工具在设备断开后浏览器端的Web Serial连接会直接进入异常状态往往需要手动点击断开再重新连接。实测中我发现一个最小的复现路径ESP32开发板通过USB连着电脑在线工具已经正常通信然后我把USB线拔下来再插回去。此时在Serial Terminal Online里点击发送没有任何响应接收区也没有数据。必须先在界面上点一下断开再点Connect重新选择设备才能恢复通信。这个体验在频繁插拔USB设备的外观测试场景中确实有点烦人。我的应对策略是如果需要频繁断电重连尽量减少在在线工具里的操作次数直接把USB线和开发板的电源控制结合起来避免每次重插都手动重连。系统休眠的问题也类似。笔记本合盖休眠后浏览器和串口之间的连接大概率会失效。有一次我让在线工具跑着接收数据中途合上笔记本盖子过了一小时再打开发现接收区的时间戳直接从合盖前跳到了唤醒后中间的数据一条都没收到。这不是在线工具本身的问题而是系统休眠时USB端口供电和数据通信都被暂停了连桌面工具也逃不掉。6.3 数据丢帧与缓冲区的处理在线工具还有一个容易被忽视的问题数据量大时可能出现丢帧。虽然浏览器内部的数据缓冲区会尽量接收串口数据但如果网页主线程被大量DOM更新阻塞例如接收区每秒要渲染几千条数据就可能在数据读取和渲染之间形成瓶颈。我自己实测过一组数据ESP32以921600波特率持续输出数据大约是每秒9万多字节。Serial Terminal Online在接收这个数据量时界面明显出现卡顿接收区的刷新速度跟不上数据到达速度导出日志后发现确实有少量的数据缺口。处理办法是分层次地降低压力。一个是把波特率降到115200或更低的水平这是嵌入式调试中最常用的速率在线工具应对起来非常轻松另一个是利用工具的暂停显示功能让浏览器只收数据但暂时不渲染到界面这样缓冲区的压力会小很多。如果确实需要高速率采集完整的数据那在线工具就不是最佳选择了我会建议回到桌面工具配合串口硬件缓冲来做无损抓包。7. 在线与桌面工具如何取舍7.1 什么时候该用CuteCom/MobaXterm在线工具虽然方便但它并不能完全替代桌面工具的全部功能。如果你的工作场景涉及以下几种情况桌面工具依然有不可替代的优势需要长时间、高可靠性、大批量地记录串口数据并且对数据完整性有硬性要求需要同时监控多个串口设备并且各个串口的通信配置差异很大希望集成更复杂的脚本逻辑比如python的pyserial库直接操作串口跑自动化测试用例在网络受限的内网环境浏览器无法加载在线工具的页面或者组织禁止将开发工具相关的访问指向外部域名。举一个具体例子我在Linux服务器上跑一个数据采集程序程序通过串口读取多个传感器数据存到数据库里。这种场景下我会直接写一个Python脚本来处理而不是把在线工具挂在服务器上。因为脚本可以重连、可以落盘、可以错误重试这些能力是在线工具的页面交互模型给不了的。MobaXterm这类集成了串口连接能力的终端工具在Windows上也值得保留。它除了串口调试还能管理SSH会话、SFTP传输算是一个多合一的工作台。如果你日常就需要SSH到远程服务器做运维同时还带一块串口设备做调试MobaXterm一个窗口就能搞定比在浏览器和SSH客户端之间来回切换要顺手。7.2 我的个人选择建议我现在的工作流是这样分配的日常快速调试、临时查看设备输出、跨平台场景首选在线串口调试工具涉及大批量数据采集、固定长周期测试、需要脚本自动化的任务直接切到Python脚本在Windows上处理多任务的时候保留一个MobaXterm作为备用防止在线工具因为浏览器标签页误关闭而导致连接中断。用在线工具前我总结了几条个人建议第一把常用的在线工具网址加入浏览器书签最好固定标签页。因为它们吃的是浏览器进程资源如果被误关恢复连接的成本还是比较高的。第二如果经常在Linux下使用提前把用户的dialout权限配好不然每次调试都要加sudo既麻烦又容易带来权限风险。第三留意在线工具是否已经适配了Web Serial API的最新变化。Chromium内核升级后偶尔会调整串口配置项的默认行为比如流控默认值的改变这可能导致原本正常的连接突然出错。遇到这种情况先检查工具的更新说明或者GitHub仓库的Issue区通常能找到答案。第四也是最重要的一点不要盲目相信工具始终保留一种不依赖图形界面的串口访问方式。在嵌入式调试的时候万一浏览器崩溃或者系统资源耗尽你还能用echo AT /dev/ttyUSB0或者screen /dev/ttyUSB0 115200这类命令快速应急确保现场调试进度不受影响。这几条建议都是我实际踩过坑之后总结出来的。比如有一次调试的关键时刻浏览器标签页被误关在线工具的连接直接断掉幸好我还会用Linux命令快速顶上去才没有耽误现场客户那边的联调。工具是辅助真正可靠的是你对串口协议本身的理解以及面对各种意外时能快速切换方案的能力。
用串口调试这件事Windows用户有SSCOM、XCOMmacOS用户有CoolTerm、screen命令Linux用户又得翻出CuteCom或者minicom。每一次换电脑、换系统都得重新找工具、重新配环境数据线和板子没变折腾的时间倒是翻了几倍。我最近半年频繁在Windows笔记本和MacBook之间切换调试ESP32和STM32实在受不了这种碎片化的工具链才开始认真尝试基于Web Serial API的在线串口调试工具。试过几款之后发现这类工具在跨平台场景下确实能解决大部分日常调试需求而且功能比我预想的要完整得多。这篇文章把我实际测试过的几款在线串口调试工具、完整的连接流程、以及踩过的坑都整理出来。如果你经常在三套系统之间切换调试或者刚入行不想装一堆桌面软件这份经验应该能直接帮你省下不少时间。1. 串口调试的跨平台困境为何总在换工具1.1 从SSCOM到screen碎片化的工具生态先说说我为什么对这事这么执着。做嵌入式开发的人都知道串口调试工具几乎可以说是每天都要摸的家伙。但是我翻了一下自己电脑里装过的工具列表Windows上有过SSCOM、XCOM、友善串口助手macOS上试过CoolTerm、串口猎人Linux下折腾过minicom、CuteCom、picocom。每换一个平台都要重新熟悉一遍界面布局、快捷键、配置方式更别提那些老旧的工具在Win10/Win11上动不动就崩溃、乱码、丢数据的问题。举一个很具体的例子在Windows上用惯了SSCOM的按十六进制发送和自动加校验位的功能到了macOS上的CoolTerm这些功能虽然也有但位置完全不同CKD、流控的配置方式也不一样。而用Linux的minicom时连退出都要先按CtrlA再按X第一次用的时候我卡了半天没退出去直接关了终端结果串口还被进程占着第二次打开直接报Device or resource busy。这些工具本身都没问题问题在于每个平台、每个工具都有自己的脾气。如果只是偶尔跨平台还好但如果你像我一样上午用Windows连STM32烧录调试下午切到Mac写Python脚本读传感器数据晚上又要在Linux服务器上跑一段串口通信的测试程序那这套工具切换的成本就非常可观了。1.2 在线方案的价值一次部署三平台通用在线串口调试工具的核心思路是串口通信的逻辑全部跑在浏览器里通过Web Serial API直接访问系统串口你在任何能装Chrome或Edge的平台上打开同一个网址就能看到一模一样的界面、用一模一样的配置方式、一模一样的快捷键。这意味着什么意味着可以彻底告别换平台就换工具的循环。在Windows上调试好的波特率、数据位、校验位配置到Mac上打开同一个页面重新选一下串口号就能直接干活。我没有专门去重新学习一套新工具的界面逻辑因为用的是同一个工具。更重要的是在线工具天然具备跨设备的可移植性。我有一台安装了Linux的开发服务器平时放在机房里跑数据采集程序需要临时看一眼串口输出的时候不用再SSH进去找minicom配半天直接在本地浏览器打开在线工具选一下远程机器上映射过来的串口设备就行。这一条在实际工作中省下的时间比我预想的要多得多。2. Web Serial API在线串口调试的技术底座2.1 浏览器直连串口的原理与限制在线串口调试工具能跑起来靠的是Chrome和Edge浏览器内置的Web Serial API。这个API本质上允许网页通过系统串口驱动直接读写数据不需要在浏览器外安装任何插件或客户端。它做的事情很简单网页调用navigator.serial.requestPort()弹出设备选择框用户选中目标串口后网页拿到端口对象并调用open()方法配置波特率之后就可以通过readable和writable两个数据流进行收发。这里最关键的一个点是浏览器本身不包含任何串口驱动它依赖的是操作系统已经安装好的、可被常规桌面软件调用的串口驱动。也就是说系统里插上USB转串口模块CP2102、CH340、FT232等后只要能出现在设备管理器或系统信息里Web Serial API通常就能访问到。它并不是绕过驱动而是站在驱动之上做了一层标准化的访问接口。限制也同样明显首先是浏览器兼容性Web Serial API目前只在Chrome和Edge都是Chromium内核中可用Firefox和Safari都不支持这就意味着如果你只有Safari在线方案就走不通。其次出于安全性考虑API要求页面必须运行在HTTPS协议或localhost环境下普通HTTP页面无法调用串口。最后是权限模型浏览器每次连接串口都需要用户手动点击授权这既是安全机制也意味着脚本完全自动化操作串口的路径被切断了。2.2 为什么是Chrome/Edge而不是Firefox我测试的时候专门对比过Firefox和Chrome。Firefox对Web Serial API的支持一直是正在实现状态直到我写完这篇文章的时点普通用户版的Firefox依然无法直接调用串口。Safari更是完全没有这个计划。所以在实际部署的时候我会直接告诉同事用Chrome或者Edge其他浏览器别折腾了。Win10和Win11自带的Edge其实就是Chromium内核所以Windows用户基本不用额外装任何东西macOS用户需要装一个ChromeLinux用户如果装的是Chrome需要注意Google官方源在你的发行版上是否可用如果不行可以用Chromium开源版内核一样Web Serial功能没差别。还有一个容易被忽略的细节Chrome浏览器本身如果开启了安全浏览增强模式某些在线串口工具的域名如果没有备案或证书不完整会被直接拦截。我遇到过一次serialterminal.com在Chrome里面正常打开但同事的Chrome因为开了严格安全模式页面被警告恶意软件的情况。这个不一定是工具本身有问题但确实值得留意。3. 实测推荐三款可用在线串口调试工具3.1 Serial Terminal Online功能最完整的在线方案我主力使用的在线串口调试工具是Serial Terminal Online网址是serialterminal.com。这款工具的功能完整度可以说超出了我对在线工具的预期。界面分区非常清晰左侧是串口配置区可以选择端口、设置波特率、数据位、停止位、校验位、流控右侧是数据显示区支持ASCII和Hex两种显示模式底部是发送区支持文本发送和Hex发送还可以设置定时发送。我重点测试了它的Hex收发能力。做单片机开发时经常需要直接和寄存器打交道发送0x01 0x03 0x00 0x00 0x00 0x0A 0xC5 0xCD这种Modbus指令在Serial Terminal Online里直接把Hex输入框填好点发送返回的数据会自动按Hex和ASCII两种形式同时显示出来。这个功能在调试传感器协议时帮了大忙能直观地看到字节与ASCII字符的对应关系。它还支持日志导出。调试过程中数据刷得很快肉眼根本看不过来Serial Terminal Online可以把接收区的所有内容一键导出为TXT文件保存后可以慢慢翻也可以用脚本处理。实测导出一个小时连续接收的数据大约几万行文件生成速度和完整性都很好。不过它也有缺点界面是全英文的对部分新手可能不太友好免费版对发送频率有一点限制连续高频发送时偶尔会感觉到卡顿另外它依赖浏览器进程如果标签页被关了正在进行的串口连接会直接断开不像桌面工具关掉窗口还可能最小化到托盘。3.2 Web Serial Terminal轻量快速的开源选择第二款值得推荐的开源项目叫Web Serial Terminal它在GitHub上有完整源码部署特别简单。相比Serial Terminal Online它的界面更朴素但胜在轻量——页面体积小、加载快在低配的Linux工控机上也能流畅运行。这款工具的核心功能没有Serial Terminal Online那么多但基本收发、Hex模式、波特率选择、时间戳显示都有。它的特点是比较克制界面零广告、零冗余打开就是干活的页面。适合那些只是想快速看一眼串口输出、或者跑一个简单环路测试的场景。我一般在Linux服务器上临时调试时会用这个。因为页面很简洁连配置项都少不容易出错。比如我要快速确认某个USB转串口模块的收发是否正常打开页面、选端口、设波特率、发一个AT命令看返回结果整个过程不超过30秒。相比之下如果打开Serial Terminal Online还要面对一堆配置项反而有点杀鸡用牛刀的感觉。需要提醒的是这款开源工具如果在本地部署需要注意用HTTPS或localhost访问否则Web Serial API无法启用。如果直接使用别人搭建的在线版本要确认它的证书是否有效。3.3 备选方案与各自适用场景除了上面两款主力工具我还测试过一些其他方案各有各的适用场景browser-serial-terminal一个基于Node.js的开源项目特点是支持快捷键操作和分组管理比较弱但可以嵌入到其他Web应用中。如果你的工作流是内部系统集成串口调试功能可以参考这个项目做二次开发。Chrome的原生实验工具在Chrome的chrome://flags里开启相关实验项后可以通过开发者工具访问串口。这个方案极其简陋只适合做技术验证不适合日常使用。Wokwi的串口监控器主要在Wokwi仿真环境中使用。如果你在Wokwi里跑ESP32仿真直接在串口监控器里看输出很方便但它是绑定仿真环境的不支持直接访问本机物理串口。这几款工具体验下来日常开发和硬件调试我会优先选Serial Terminal Online极简场景选Web Serial Terminal其他方向更多是特定场景的补充。4. 连接ESP32的完整实测流程4.1 硬件准备与浏览器配置我拿ESP32开发板作为实测对象它板载的USB转串口芯片通常是CP2102或CH340这类芯片在Windows、macOS、Linux下都有成熟的驱动。把开发板用USB线连到电脑上系统会自动识别出一个串口设备。这里有一个很重要的前置步骤确认驱动装好。Windows下打开设备管理器如果看到端口(COM和LPT)里面出现了一个USB Serial Port就说明驱动OKmacOS下打开终端执行ls /dev/tty.*能看到类似/dev/tty.usbserial-0001的设备名Linux下执行ls /dev/ttyUSB*或/dev/ttyACM*能看到对应设备节点。浏览器这边我建议提前做两件事。第一用最新版的Chrome或Edge老版本浏览器对Web Serial API的支持不完整可能出现奇怪的报错。第二如果是Linux系统普通用户访问串口经常遇到权限不足的问题。此时需要把当前用户加入dialout组sudo usermod -a -G dialout $USER然后重新登录一次。如果没做这一步打开在线工具后串口列表里可能根本看不到设备或者选择设备后报Failed to open之类的错误。4.2 波特率、换行符与流控制的设置技巧打开Serial Terminal Online后第一步是点Connect按钮浏览器会弹出设备选择框。选择框里列出的设备是系统当前可访问的所有串口ESP32开发板通常会以设备名称或VID/PID编号的形式出现建议通过试连一个已知设备来确认或者拔插USB线观察列表变化来锁定目标设备。选中设备后进入配置界面波特率选择115200数据位8停止位1校验位None流控关闭。这个组合是ESP32默认的也是最常见的串口参数。如果你的设备用的是9600或者57600改一下波特率就行其他参数基本不用动。在发送区需要重点关注换行符的设置。很多在线工具默认发送时是不附加换行符的而ESP32上的AT固件或命令行交互程序往往要求每条命令以回车换行结尾。如果发现发送命令后设备毫无反应先别怀疑硬件检查一下发送区旁边是不是有个Newline或Line Ending的下拉框把它设成CRLF或LF再试一次。我测试时用ESP32刷了一个简单的回环程序收到什么就返回什么并且在前面加上ECHO前缀。在在线工具里发送hello收到的返回是ECHO: hello收发正常数据没有乱码和丢字节。这就是一个非常标准的最小通信验证。4.3 收发数据验证与日志导出数据验证通过后我再测试一下连续传输的稳定性。给ESP32写了一段每秒打印一次系统运行时间的固件通过在线工具持续接收了大概10分钟输出的时间戳序列没有中断和乱行。期间我试着把发送区定时发送功能打开设置每2秒发送一次状态查询指令status设备的返回也都及时显示在接收区。日志导出的操作很简单在接收区上方找到Download Log或Export按钮点击后浏览器会自动下载一个TXT文件。我导出后看了一下文件里每条记录都保留了时间戳方便后续分析数据与操作之间的对应关系。如果接收到的数据量很大屏幕滚动速度太快导致看不清Serial Terminal Online有一个Pause Display的功能可以暂停刷新显示但后台数据仍在累积。这个功能在处理高速串口数据时非常实用等数据收集得差不多暂停显示后仔细看日志即可不用怕错过任何一条。5. 在线工具的高级玩法脚本、协议调试与浏览器自动化5.1 定时发送与协议序列很多做硬件调试的人忽略了一个事实在线串口工具的界面虽然简单但它的定时发送功能其实可以用来跑简单的协议序列测试。比如我在调试一个温湿度传感器模块时需要按固定顺序发送一组初始化命令再等待设备返回结果。在Serial Terminal Online里我可以把定时发送间隔设为1000ms把初始化命令作为发送内容就能实现每秒发送一次状态查询的效果。更复杂一点有些工具支持通过JavaScript或浏览器控制台直接操作Web Serial API的接口这给了我很大的自动化灵活度。举个例子在浏览器开发者工具的Console里我可以直接执行代码来批量发送指令、读取返回数据甚至实现简单的自动化逻辑。当然这需要一定的前端JavaScript基础但这对做硬件开发的人来说门槛不高。实际上我在调试一段自定义二进制协议时就是靠自己在Console里写了一段循环发送脚本一次跑完了一整轮协议握手测试。5.2 结合浏览器开发者工具做自动化这里展开说一下浏览器自动化调试串口的具体做法。Web Serial API暴露的接口并不复杂核心是navigator.serial对象。我通常在Console里做这样一个流程先通过navigator.serial.requestPort()选择一个端口用port.open({ baudRate: 115200 })建立连接通过port.readable.getReader()读取数据通过port.writable.getWriter()发送数据。在Console里执行完第一步后浏览器会弹出和点击Connect按钮时一样的设备选择框。选择后后续就可以在Console中反复读写了。这种方式让自动化测试变得非常简单比如连续发送100条AT指令并统计返回内容写一个for循环就够了。这段代码的效果是发送一次读取一次把上行的数据和下行的返回都打印出来。它的价值在于不用修改任何固件代码就能对设备进行压力测试和功能验证。// 在Console中选择串口并打开 const port await navigator.serial.requestPort(); await port.open({ baudRate: 115200 }); const reader port.readable.getReader(); const writer port.writable.getWriter(); const encoder new TextEncoder(); await writer.write(encoder.encode(AT\r\n)); const { value } await reader.read(); console.log(new TextDecoder().decode(value));这种做法和在线工具界面操作可以无缝衔接。先用界面手动连接再用Console获取到页面持有的端口对象做二次操作相当于给在线工具加了一个脚本扩展能力。虽然在线工具本身没有提供宏定义、脚本录制这类专业功能但凭借浏览器的开发者工具这些需求都能自己实现。5.3 多人协作远程调试的思路还有一个有趣的使用场景是远程协作调试。传统桌面串口工具只能绑定在本地电脑上如果设备在实验室里而你在办公室或家里就得靠远程桌面或者SSH转发来实现远程调试。在线串口工具的另外一个潜在优势是只要串口连接的设备能被某台电脑访问其他电脑就可以通过浏览器远程连接到这台电脑进行协作。当然这需要配合串口服务器或远程USB设备共享工具并不是在线工具原生支持的。不过当设备物理连接在一台机器上而你在另一台机器上用浏览器打开同一个在线工具时可以把远程机器上的串口映射为本地设备再通过在线工具进行操作。这种方案比远程桌面方案更轻量通信数据都在本地浏览器和本地串口之间流动远程传输的只是系统层的数据包延迟和卡顿感比远程桌面低很多。6. 踩坑记录兼容性、权限与驱动那些事6.1 驱动安装与权限细节在线工具虽然免去了装桌面软件的麻烦但操作系统的串口驱动这一步省不掉。我遇到过最典型的坑是在macOS上插上CH340芯片的开发板系统完全不识别。原因很简单新版macOS对非苹果官方芯片的USB转串口驱动有严格的签名要求CH340的驱动如果没有正确安装且通过系统安全验证就会直接无法使用。解决办法并不复杂去芯片厂商官网下载对应平台的最新驱动安装后在系统设置 - 隐私与安全性里允许加载该驱动然后重启电脑。这里有一个细节不是插上设备就一定要重启但macOS安全策略会拦截未签名的驱动扩展首次加载确实需要重启才能生效。Linux下的权限问题也值得多说一句。很多初学者在Linux下打开在线串口工具发现选不到设备或者选了之后无法打开。除了前面提到的dialout组权限问题还有一个隐蔽的小坑部分Linux发行版做了动态设备权限管理即使当前用户在dialout组里也需要重新插拔一次USB设备让udev重新分配设备节点权限变更才会生效。6.2 断开重连与系统休眠的坑在线工具在断线重连方面有一个体验上的显著差异桌面工具在串口设备被拔掉又插回后通常会保留原来的会话并尝试自动重连而在线工具在设备断开后浏览器端的Web Serial连接会直接进入异常状态往往需要手动点击断开再重新连接。实测中我发现一个最小的复现路径ESP32开发板通过USB连着电脑在线工具已经正常通信然后我把USB线拔下来再插回去。此时在Serial Terminal Online里点击发送没有任何响应接收区也没有数据。必须先在界面上点一下断开再点Connect重新选择设备才能恢复通信。这个体验在频繁插拔USB设备的外观测试场景中确实有点烦人。我的应对策略是如果需要频繁断电重连尽量减少在在线工具里的操作次数直接把USB线和开发板的电源控制结合起来避免每次重插都手动重连。系统休眠的问题也类似。笔记本合盖休眠后浏览器和串口之间的连接大概率会失效。有一次我让在线工具跑着接收数据中途合上笔记本盖子过了一小时再打开发现接收区的时间戳直接从合盖前跳到了唤醒后中间的数据一条都没收到。这不是在线工具本身的问题而是系统休眠时USB端口供电和数据通信都被暂停了连桌面工具也逃不掉。6.3 数据丢帧与缓冲区的处理在线工具还有一个容易被忽视的问题数据量大时可能出现丢帧。虽然浏览器内部的数据缓冲区会尽量接收串口数据但如果网页主线程被大量DOM更新阻塞例如接收区每秒要渲染几千条数据就可能在数据读取和渲染之间形成瓶颈。我自己实测过一组数据ESP32以921600波特率持续输出数据大约是每秒9万多字节。Serial Terminal Online在接收这个数据量时界面明显出现卡顿接收区的刷新速度跟不上数据到达速度导出日志后发现确实有少量的数据缺口。处理办法是分层次地降低压力。一个是把波特率降到115200或更低的水平这是嵌入式调试中最常用的速率在线工具应对起来非常轻松另一个是利用工具的暂停显示功能让浏览器只收数据但暂时不渲染到界面这样缓冲区的压力会小很多。如果确实需要高速率采集完整的数据那在线工具就不是最佳选择了我会建议回到桌面工具配合串口硬件缓冲来做无损抓包。7. 在线与桌面工具如何取舍7.1 什么时候该用CuteCom/MobaXterm在线工具虽然方便但它并不能完全替代桌面工具的全部功能。如果你的工作场景涉及以下几种情况桌面工具依然有不可替代的优势需要长时间、高可靠性、大批量地记录串口数据并且对数据完整性有硬性要求需要同时监控多个串口设备并且各个串口的通信配置差异很大希望集成更复杂的脚本逻辑比如python的pyserial库直接操作串口跑自动化测试用例在网络受限的内网环境浏览器无法加载在线工具的页面或者组织禁止将开发工具相关的访问指向外部域名。举一个具体例子我在Linux服务器上跑一个数据采集程序程序通过串口读取多个传感器数据存到数据库里。这种场景下我会直接写一个Python脚本来处理而不是把在线工具挂在服务器上。因为脚本可以重连、可以落盘、可以错误重试这些能力是在线工具的页面交互模型给不了的。MobaXterm这类集成了串口连接能力的终端工具在Windows上也值得保留。它除了串口调试还能管理SSH会话、SFTP传输算是一个多合一的工作台。如果你日常就需要SSH到远程服务器做运维同时还带一块串口设备做调试MobaXterm一个窗口就能搞定比在浏览器和SSH客户端之间来回切换要顺手。7.2 我的个人选择建议我现在的工作流是这样分配的日常快速调试、临时查看设备输出、跨平台场景首选在线串口调试工具涉及大批量数据采集、固定长周期测试、需要脚本自动化的任务直接切到Python脚本在Windows上处理多任务的时候保留一个MobaXterm作为备用防止在线工具因为浏览器标签页误关闭而导致连接中断。用在线工具前我总结了几条个人建议第一把常用的在线工具网址加入浏览器书签最好固定标签页。因为它们吃的是浏览器进程资源如果被误关恢复连接的成本还是比较高的。第二如果经常在Linux下使用提前把用户的dialout权限配好不然每次调试都要加sudo既麻烦又容易带来权限风险。第三留意在线工具是否已经适配了Web Serial API的最新变化。Chromium内核升级后偶尔会调整串口配置项的默认行为比如流控默认值的改变这可能导致原本正常的连接突然出错。遇到这种情况先检查工具的更新说明或者GitHub仓库的Issue区通常能找到答案。第四也是最重要的一点不要盲目相信工具始终保留一种不依赖图形界面的串口访问方式。在嵌入式调试的时候万一浏览器崩溃或者系统资源耗尽你还能用echo AT /dev/ttyUSB0或者screen /dev/ttyUSB0 115200这类命令快速应急确保现场调试进度不受影响。这几条建议都是我实际踩过坑之后总结出来的。比如有一次调试的关键时刻浏览器标签页被误关在线工具的连接直接断掉幸好我还会用Linux命令快速顶上去才没有耽误现场客户那边的联调。工具是辅助真正可靠的是你对串口协议本身的理解以及面对各种意外时能快速切换方案的能力。
