企业官网建设流程全解析

1. 为什么嵌入式开发者需要一个"假的"串口

搞嵌入式开发的人，电脑上插着三四个USB转串口模块是常态。STM32核心板一个、ESP32模组一个、还有个老设备调试口占着一个，USB Hub插满了不说，设备管理器里那一堆COM口号还经常打架。更头疼的是，很多调试场景压根不需要真实硬件——比如上位机协议解析逻辑的验证、串口通信状态机的单元测试、或者单纯想模拟两个设备之间的数据对发。这时候如果还靠插拔硬件来切换，效率低得让人抓狂。

VSPD（Virtual Serial Port Driver）就是解决这个问题的。它能在Windows系统里凭空创建出一对或多对虚拟串口，这些串口在设备管理器里看起来和真实的物理串口没有任何区别，应用程序打开COM口、设置波特率、收发数据，所有操作都跟操作真实串口一模一样。但数据实际上是在内存里从一个虚拟口流向另一个虚拟口，完全不经过物理线路。

这个工具在嵌入式开发中的价值，我总结下来主要是三个场景。第一是协议栈开发阶段，你写了一个Modbus RTU的主站程序，但手头没有从站设备，用VSPD建一对虚拟口，一个口给主站程序，另一个口用串口调试助手模拟从站响应，整个通信链路就能跑通。第二是多设备联调，比如你的系统里有一个主控通过串口连接一个4G模组和一个传感器，真实硬件还没到齐，用VSPD建两对虚拟口，把三个程序分别绑定到对应的COM口上，逻辑层面的联调可以提前完成。第三是自动化测试，CI流水线里不可能挂一堆真实串口设备，虚拟串口对配合脚本就能实现串口通信的自动化回归测试。

这篇文章面向的是有一定Windows操作基础、正在做嵌入式开发或串口通信相关工作的工程师。不管你是刚接触STM32串口调试的新手，还是已经在做嵌入式Linux应用开发的老手，只要你的工作涉及Windows环境下的串口通信验证，VSPD都能帮你省下大量插拔硬件和等待设备的时间。下面我会从安装、配置、调试技巧到常见问题排查，把整个流程拆开讲清楚。

2. VSPD 7.2的安装与授权：从下载到可用状态

2.1 安装包获取与版本选择

VSPD的版本迭代不算快，7.2版是目前在Windows 10和Windows 11上兼容性最稳定的一个版本。网上流传的版本很多，有7.0、7.1、8.0甚至9.0的，但我实测下来，7.2在驱动签名和系统兼容性之间平衡得最好。8.0之后的版本对Windows 11的驱动强制签名要求更严格，安装过程中容易卡在驱动安装环节。

下载渠道方面，建议从官方渠道获取安装包。安装包本身不大，大概5MB左右，安装后的驱动文件也就几百KB。需要注意的是，网上有些所谓的"绿色版"或"便携版"，这类版本通常缺少数字签名的驱动程序，在Windows 10 1903之后的版本上安装会直接失败，系统会拦截未签名的驱动加载。所以如果你看到安装过程中弹出"Windows无法验证此驱动程序软件的发布者"的警告，说明你拿到的安装包驱动签名有问题，换一个来源重新下载。

安装前有一个准备工作容易被忽略：关闭所有正在使用串口的程序。包括串口调试助手、Putty、SecureCRT、Arduino IDE的串口监视器等等。因为安装过程需要替换系统的串口驱动文件，如果有程序正在占用串口资源，安装程序会提示文件被占用，导致安装不完整。我遇到过好几次装完之后虚拟串口创建失败，排查半天发现是后台还挂着一个串口监视器没关。

2.2 安装过程中的关键选项

双击安装包后，安装向导的步骤不多，但有两个地方需要留意。

第一个是驱动安装确认。安装程序会提示即将安装虚拟串口驱动，这个驱动是VSPD的核心组件，它向Windows系统注册一个虚拟的串口设备类。在Windows 10上，可能会弹出两次驱动安装确认窗口，一次是安装VSPD的主驱动，一次是安装串口枚举器驱动。两次都要选择"安装"或"仍然安装"。如果只点了一次，后面创建虚拟串口时会出现"无法创建端口"的错误。

第二个是安装路径选择。默认路径是C:\Program Files (x86)\Virtual Serial Port Driver\，建议保持默认。有些朋友喜欢把工具都装到D盘，但VSPD的驱动文件路径是写在注册表里的，如果安装后手动移动了文件夹，驱动会找不到对应的可执行文件，导致虚拟串口创建后无法正常收发数据。

安装完成后需要重启系统。这一步不能跳过，因为驱动加载需要在系统启动时完成初始化。我试过不重启直接打开VSPD，界面能打开，但创建虚拟串口时一直转圈然后报错。重启之后一切正常。

2.3 授权状态确认与功能限制

VSPD 7.2安装后默认是试用版，试用版可以创建虚拟串口对，但有一些限制：创建的虚拟串口对数量有限制（通常是2对），而且每次重启系统后可能需要重新创建。对于临时调试来说，试用版其实够用，但如果你需要长期稳定的多对虚拟串口，就需要进行授权。

授权的方式是在软件界面里输入序列号。这里要提醒一句：网上搜到的很多"注册码"或"激活码"要么已经失效，要么对应的版本不匹配。7.2版的授权机制和7.1、8.0都不通用。如果你输入了一个格式看起来正确但提示无效的序列号，大概率是版本不对应。

授权成功后，软件界面上方的状态栏会显示"Licensed to"加上授权信息，同时创建虚拟串口的数量限制会解除。我个人的建议是，如果只是短期项目调试，试用版完全够用；如果是团队长期使用，走正规渠道获取授权，省去后面反复折腾的时间。

3. 虚拟串口对的创建与管理：核心操作详解

3.1 创建第一对虚拟串口

打开VSPD的主界面，布局很简洁：左侧是"Serial ports"列表，显示当前系统已有的物理串口和虚拟串口；右侧是"Virtual serial port pairs"区域，用来创建和管理虚拟串口对。

创建一对虚拟串口的操作很直接：在右侧的"Pair"下拉框里选择一对尚未被占用的COM口号，比如COM10和COM11，然后点击"Add pair"按钮。软件会立即在系统里注册这两个虚拟串口设备，左侧列表里会同时出现COM10和COM11，并且标注为"Virtual"。

这里有一个细节值得展开说：为什么是"一对"而不是"一个"。VSPD创建的虚拟串口是成对出现的，两个口之间有一条虚拟的"零调制解调器"线连接。你往COM10写数据，COM11就能读到；往COM11写，COM10就能读到。这模拟的是两个设备通过串口线直连的场景。如果你只需要一个虚拟串口来"假装"有一个设备，那创建一对之后只用其中一个口就行，另一个口留着不用也不影响。

COM口的选择上，建议避开系统已经占用的低编号端口。Windows系统本身可能会保留COM1到COM4给一些传统设备，虽然现在很多电脑没有物理串口了，但系统保留的端口号仍然存在。我一般从COM10开始往上选，这样不容易和物理串口冲突。如果你不确定哪些端口被占用了，可以在创建前打开设备管理器，展开"端口(COM和LPT)"，看看已有的端口号分布。

3.2 批量创建与命名管理

实际项目中经常需要模拟多个设备同时通信。比如你要模拟一个主控连接三个从站设备的场景，那就需要创建三对虚拟串口。VSPD支持批量创建，在右侧区域连续添加多对即可。但这里有个经验：不要一次性创建太多。

我试过一次性创建8对虚拟串口，结果系统里突然多出16个COM口，设备管理器刷新了好几次才全部识别出来，而且有些串口调试助手在枚举端口列表时直接卡死了。后来我改成每次创建2到3对，创建完等几秒钟让系统完成设备枚举，再继续创建，就稳定多了。

创建好的虚拟串口对可以在右侧列表里看到，每一对显示为"COMx <-> COMy"的形式。如果你觉得COM10、COM11这样的编号不好记，VSPD本身不提供重命名功能，但你可以通过Windows设备管理器来修改端口的友好名称。在设备管理器里右键虚拟串口，选择"属性"，在"端口设置"选项卡里点击"高级"，底部的"COM端口号"可以修改，但注意不要改成已经被占用的端口号。

3.3 删除与重新配置

删除虚拟串口对的操作同样简单：在右侧列表里选中要删除的端口对，点击"Delete pair"按钮。但这里有一个容易踩的坑：如果虚拟串口正在被程序占用（比如串口调试助手还开着这个COM口），删除操作会失败，但VSPD可能不会给出明确的错误提示，只是端口对从列表里消失了，实际上驱动层面的虚拟串口还在。

这种情况下，正确的做法是：先关闭所有打开该串口的程序，然后在VSPD里删除端口对，最后重启一次系统。重启后打开设备管理器确认虚拟串口已经消失。如果重启后还在，说明驱动层面的注册信息没有清理干净，需要手动在设备管理器里卸载对应的虚拟串口设备，然后重新安装VSPD驱动。

另外，VSPD的配置是持久化的。你创建了一对COM10和COM11，重启系统后这对虚拟串口仍然存在，不需要每次开机重新创建。这个特性对于需要长期保持调试环境的场景很友好。但如果你临时创建了很多对，项目结束后记得清理掉，不然系统里会积累一堆无用的虚拟串口，影响后续的端口管理。

4. 串口调试实战：从回环测试到协议模拟

4.1 用串口调试助手做回环验证

虚拟串口创建好之后，第一件事应该是验证这对串口是否真的能正常收发数据。最直接的方法就是用两个串口调试助手分别打开这对虚拟串口，一个发一个收。

具体操作：打开两个串口调试助手实例（比如sscom或xcom），第一个打开COM10，第二个打开COM11，波特率都设为115200，数据位8，停止位1，无校验。然后在第一个助手的发送区输入"Hello"，点击发送。如果第二个助手的接收区出现了"Hello"，说明虚拟串口对工作正常。

这个测试看起来简单，但有几个细节会影响结果。波特率必须一致，虽然虚拟串口不涉及实际的时钟分频，但VSPD会模拟波特率匹配的逻辑，如果两边设置不同，数据可能无法正确传输。流控设置要一致，默认是无流控，如果你在一端开了硬件流控而另一端没开，数据流会被阻塞。串口调试助手的"自动断帧"功能可能会影响接收显示，如果发送的数据没有换行符，有些助手会把多帧数据合并显示，看起来像是丢包了，实际上是显示逻辑的问题。

我个人的习惯是，回环测试时发送一串包含数字、字母和特殊字符的测试数据，比如"ABC123!@#"，这样能同时验证数据完整性和字符编码处理。如果接收端显示的内容和发送端完全一致，说明虚拟串口的基本通信功能没有问题。

4.2 模拟设备响应：协议调试的核心技巧

回环测试通过后，就可以进入真正的调试场景了。假设你在开发一个STM32的Modbus RTU主站程序，需要验证主站发送的请求帧是否正确，以及主站能否正确解析从站的响应帧。

用VSPD建一对COM10和COM11。STM32主站程序（运行在PC上的模拟程序或通过USB转串口连接的真实STM32）绑定到COM10。串口调试助手打开COM11，用来模拟从站设备。

调试的第一步是验证请求帧格式。主站程序发送一帧Modbus请求，比如读取保持寄存器的功能码03，从站地址01，起始地址0000，寄存器数量000A。串口调试助手在COM11端应该收到这样的十六进制数据：01 03 00 00 00 0A C5 CD。如果收到的数据不对，比如地址错了、功能码错了、或者CRC校验不对，那就说明主站程序的帧组装逻辑有问题。

第二步是模拟从站响应。在串口调试助手里手动构造一帧响应数据，比如01 03 14 00 01 00 02 00 03 00 04 00 05 00 06 00 07 00 08 00 09 00 0A XX XX，其中14是字节数（10个寄存器共20字节），后面是10个寄存器的值，最后是两个字节的CRC。把这帧数据通过COM11发送出去，观察主站程序能否正确解析出10个寄存器的值。

这个过程中有一个非常实用的技巧：在串口调试助手里开启"定时发送"功能，让从站响应帧每隔100ms自动发送一次。这样主站程序可以连续收到多帧响应，方便测试程序的稳定性和异常处理逻辑。我调试Modbus主站时经常这么干，比手动一帧一帧点发送效率高得多。

4.3 多对虚拟串口协同：复杂系统联调

当系统里有多个串口设备需要同时模拟时，VSPD的多对虚拟串口就派上用场了。举个例子：一个嵌入式网关设备，通过串口1连接4G模组（AT指令），通过串口2连接温湿度传感器（Modbus RTU），通过串口3输出调试日志。

用VSPD创建三对虚拟串口：COM10<->COM11、COM12<->COM13、COM14<->COM15。网关程序分别打开COM10、COM12、COM14。然后开三个串口调试助手，分别打开COM11、COM13、COM15，对应模拟4G模组、传感器和日志接收端。

这种场景下的调试要点是数据隔离。三对虚拟串口之间的数据是完全独立的，COM10发出去的数据只会出现在COM11，不会串到COM12或COM14。这一点VSPD做得很好，底层是独立的内存缓冲区，不存在数据交叉的问题。

但要注意程序端的串口打开顺序。有些嵌入式程序在启动时会按固定顺序打开串口，如果某个串口打开失败，程序可能直接退出。用虚拟串口调试时，要确保所有需要的虚拟串口都已经在VSPD里创建好，并且没有被其他程序占用。我遇到过一种情况：网关程序启动时先打开COM10，再打开COM12，但COM12被之前没关掉的串口调试助手占用了，导致程序打开COM12失败后直接崩溃。排查了半天才发现是调试助手没关。

4.4 串口调试助手的选择与配置要点

说到串口调试助手，市面上选择很多：sscom、xcom、友善串口调试助手、AccessPort等等。我平时用得最多的是sscom和xcom，两个各有特点。

sscom的优势是十六进制显示和发送做得很顺手，支持自动添加CRC校验、支持多条发送指令的预设、支持定时发送。调试Modbus协议时，sscom的"多条字符串发送"功能特别实用，可以把常用的请求帧和响应帧都预设好，调试时直接点对应的按钮就行。

xcom的优势是界面简洁、资源占用低，而且支持串口数据的实时波形显示。如果你调试的是传感器数据，想把收到的数值直接画成曲线，xcom的波形显示功能比sscom更方便。

配置上，有几个参数需要特别注意。接收缓冲区大小：默认通常是4096字节，如果你调试的场景数据量比较大（比如高速数据采集），建议调到8192或更大，避免数据溢出丢失。接收超时：这个参数决定了串口助手多久没有收到新数据就认为一帧结束。对于变长协议，超时设置很关键，设得太短会把一帧数据拆成多帧，设得太长会把多帧数据合并成一帧。我一般设20ms到50ms之间，具体看协议的帧间隔。

还有一个容易忽略的配置：串口调试助手的"打开串口"操作会独占该COM口。如果你先用sscom打开了COM11，再用xcom去打开COM11，xcom会提示打开失败。这时候需要先关闭sscom的串口连接。虚拟串口和物理串口在这方面的行为是一致的，都是独占访问。

5. 常见问题排查与避坑指南

5.1 虚拟串口创建失败或不可见

这是最常见的问题，表现是VSPD界面里显示创建成功，但设备管理器里看不到对应的COM口，或者串口调试助手的端口列表里没有出现新建的虚拟串口。

排查思路按优先级来：第一，检查驱动状态。打开设备管理器，展开"端口(COM和LPT)"，看看有没有带黄色感叹号的设备。如果有，说明驱动没有正确加载。右键选择"更新驱动程序"，手动指向VSPD安装目录下的驱动文件夹。第二，检查系统重启。安装VSPD后如果没有重启，驱动可能没有完成初始化。重启一次再试。第三，检查端口号冲突。如果你选的COM口号已经被系统保留或占用，虚拟串口创建会静默失败。换一个高编号的端口，比如COM20以上，再试。

还有一种情况是Windows 11的驱动签名强制导致的。Windows 11对未签名驱动的拦截比Windows 10更严格。如果安装过程中驱动签名验证失败，需要临时禁用驱动签名强制，安装完VSPD后再重新启用。具体操作是：按住Shift键点击重启，进入高级启动选项，选择"禁用驱动程序强制签名"，然后正常启动系统安装VSPD。

5.2 数据收发异常：丢包、乱码、阻塞

虚拟串口能创建，但数据收发不正常，这个问题比创建失败更让人头疼，因为现象多样，原因也各不相同。

丢包的典型表现是发送端发了100个字节，接收端只收到80个。虚拟串口的缓冲区大小是有限的，如果发送速度远大于接收端的读取速度，缓冲区满了之后新数据就会覆盖旧数据。解决办法是降低发送速率，或者在接收端提高读取频率。串口调试助手的"接收保存到文件"功能会降低接收效率，如果开了这个功能，更容易出现丢包。

乱码通常和波特率、数据位、停止位、校验位的设置有关。虚拟串口虽然不涉及物理时钟，但VSPD会模拟波特率匹配的逻辑。如果一端设了115200，另一端设了9600，数据就会乱。另外，如果发送的是中文或特殊字符，要注意字符编码。串口调试助手默认可能是GBK编码，而你的程序发送的是UTF-8，接收端显示就会乱码。统一用十六进制模式收发可以避免编码问题。

阻塞的表现是发送端调用写串口的函数后一直不返回，或者接收端读不到数据。这通常和流控设置有关。如果一端开了硬件流控（RTS/CTS），而另一端没有对应的流控信号，数据流会被阻塞。虚拟串口默认不支持硬件流控信号，所以两端都应该设置为无流控。检查串口调试助手和你的程序里的流控设置，确保都是"None"。

5.3 程序无法打开虚拟串口

你的程序在打开虚拟串口时返回错误，提示"拒绝访问"或"端口不存在"。这种情况有几个可能的原因。

端口被占用是最常见的。检查是否有其他程序已经打开了这个COM口。串口调试助手、Putty、甚至一些后台服务都可能占用串口。用任务管理器看看有没有可疑的进程，或者直接重启系统再试。

端口号超出程序支持范围。有些老旧的串口程序只支持COM1到COM9，对于COM10及以上的端口号，需要用\\.\COM10这样的格式来打开。这是Windows API的历史遗留问题，COM1到COM9可以直接用"COM1"这样的名称打开，但COM10以上必须用\\.\COM10的格式。如果你用的是自己写的程序，检查一下打开串口的代码是否处理了这种情况。

权限问题。在某些系统上，普通用户可能没有权限打开串口设备。尝试以管理员身份运行你的程序。如果管理员权限下能打开，说明是权限配置的问题，需要调整用户组策略或串口设备的访问权限。

5.4 系统重启后虚拟串口消失或错乱

VSPD创建的虚拟串口默认是持久化的，重启后应该还在。但有时候会出现虚拟串口消失，或者端口号发生变化的情况。

消失的原因通常是驱动加载失败。检查VSPD的服务是否正常启动。在Windows服务管理器里找到"Virtual Serial Port Driver"服务，看看状态是否是"正在运行"。如果服务没有启动，虚拟串口就不会被创建。可以手动启动服务，或者设置服务为自动启动。

端口号错乱的情况比较少见，但确实发生过。比如你创建了COM10和COM11，重启后变成了COM12和COM13。这通常是因为系统在启动时重新枚举了所有串口设备，物理串口和虚拟串口的枚举顺序发生了变化。解决办法是尽量使用高编号的端口（COM20以上），减少和物理串口枚举冲突的概率。另外，在VSPD里创建虚拟串口时，可以勾选"Lock port names"选项（如果有的话），锁定端口号不变。

5.5 常见问题速查表

6. 进阶用法：虚拟串口在自动化测试中的角色

6.1 配合脚本实现串口自动化测试

虚拟串口最大的价值之一，是让串口通信的自动化测试成为可能。在CI流水线里，你不可能挂一堆真实的串口设备，但虚拟串口可以随用随建。

思路是这样的：用Python的pyserial库打开虚拟串口的一端，另一端用另一个Python脚本或串口调试助手来模拟设备响应。测试脚本发送请求帧，读取响应帧，然后断言响应内容是否符合预期。整个过程不需要任何硬件。

具体实现上，VSPD提供了命令行工具，可以在脚本里调用命令行来创建和删除虚拟串口对。比如在测试开始前执行创建命令，测试结束后执行删除命令。这样每次CI运行时环境都是干净的。

Python端的代码大概长这样：

import serial import time # 打开虚拟串口的一端 ser = serial.Serial('COM10', 115200, timeout=1) # 发送Modbus请求帧 request = bytes([0x01, 0x03, 0x00, 0x00, 0x00, 0x0A, 0xC5, 0xCD]) ser.write(request) # 读取响应 time.sleep(0.1) response = ser.read(25) # 预期响应长度 # 断言响应内容 assert response[0] == 0x01 # 从站地址 assert response[1] == 0x03 # 功能码 assert response[2] == 0x14 # 字节数 ser.close()

另一端可以用一个简单的Python脚本模拟从站，监听COM11，收到请求后回复预设的响应帧。这样整个测试链路就闭环了。

6.2 与嵌入式Linux开发的配合

虽然VSPD是Windows软件，但它在嵌入式Linux开发中也有用武之地。很多嵌入式Linux开发者的工作流是：在Windows上写代码、编译，然后通过串口把固件烧录到开发板，或者通过串口查看开发板的启动日志。

在开发早期，开发板可能还没到手，或者硬件有问题暂时无法启动。这时候可以用VSPD在Windows上创建一对虚拟串口，一端给Windows上的串口终端软件（比如Putty或SecureCRT），另一端给一个模拟开发板启动日志的脚本。这样你可以提前调试你的串口终端配置、日志解析脚本，等开发板到了直接切换过去就行。

另外，如果你在Windows上用WSL（Windows Subsystem for Linux）做嵌入式Linux开发，WSL可以访问Windows的COM口。在WSL里用/dev/ttyS加上对应的编号来访问虚拟串口。不过WSL对串口的支持有一些限制，需要先在Windows端把虚拟串口创建好，然后在WSL里用stty命令配置串口参数。我实测下来，WSL2对虚拟串口的兼容性比WSL1好一些，但偶尔还是会有数据延迟的问题，调试时要注意。

6.3 虚拟串口与MQTT网关模拟

现在很多嵌入式项目需要把串口数据转发到MQTT服务器。比如一个STM32采集传感器数据，通过串口发给一个4G模组，模组再把数据以MQTT协议发到云端。在开发阶段，4G模组和云端可能都不具备，这时候可以用虚拟串口来模拟整个链路。

具体做法：STM32程序绑定COM10，一个Python脚本绑定COM11。Python脚本收到STM32发来的串口数据后，把数据打包成MQTT消息，发到本地的MQTT Broker（比如Mosquitto）。另一个Python脚本订阅MQTT主题，收到消息后打印出来。这样整条数据链路——从STM32串口输出到MQTT消息接收——就全部在本地模拟完成了。

这个方案的好处是，你可以单独测试每一段逻辑。比如只测试STM32的串口输出格式，或者只测试MQTT消息的组装和解析。等真实硬件和云端就绪后，只需要把Python脚本替换成真实的4G模组和云端服务，其他部分不用改动。

7. 一些踩过坑之后才明白的经验

VSPD这个工具本身不复杂，但实际用起来，细节上的坑不少。我把自己和团队里其他人踩过的坑整理了几条，都是文档里不会写的。

第一条：虚拟串口的波特率设置是"假"的，但必须一致。虚拟串口不涉及实际的时钟分频，理论上波特率设成多少都不影响数据传输。但VSPD在驱动层面会检查两端的波特率设置，如果不一致，数据可能被丢弃。所以不管是用串口调试助手还是自己写程序，两端的波特率、数据位、停止位、校验位都要设成一样的。我一般统一用115200-8-N-1，这是最通用的配置。

第二条：不要依赖虚拟串口的流控信号。VSPD的虚拟串口对不支持硬件流控（RTS/CTS）和软件流控（XON/XOFF）。如果你在程序里开了流控，虚拟串口的行为可能和真实串口不一致。调试阶段建议关闭所有流控，等切换到真实硬件时再根据实际需要开启。

第三条：虚拟串口的数量不是越多越好。每创建一对虚拟串口，系统里就多出两个COM口设备。Windows对COM口的总数是有上限的，虽然理论上可以到256个，但实际使用中，超过20个COM口之后，设备管理器的刷新和串口程序的端口枚举都会变慢。我建议按需创建，项目结束后及时清理。

第四条：串口调试助手的"自动断帧"功能要慎用。这个功能的本意是好的，根据帧间隔自动把数据流切分成一帧一帧显示。但如果你的协议帧间隔很短，或者数据量很大，自动断帧可能会把一帧完整的数据拆成好几段显示，看起来像是通信出了问题。调试变长协议时，我一般关掉自动断帧，直接看原始数据流。

第五条：虚拟串口不能完全替代真实串口调试。虚拟串口验证的是协议逻辑和程序流程，但真实串口还有电气特性、信号质量、电磁干扰等问题。虚拟串口调通了，不代表真实硬件上就没问题。我的习惯是，虚拟串口上先把协议逻辑跑通，然后尽早切换到真实硬件上做联调，把电气层面的问题暴露出来。

第六条：VSPD的配置信息存在注册表里，重装系统前记得备份。如果你创建了很多对虚拟串口，并且配置了固定的端口号，重装系统后这些配置会丢失。VSPD没有提供配置导出功能，但配置信息在注册表的HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vspd路径下。重装前导出这个注册表项，重装后导入，可以恢复虚拟串口的配置。不过驱动文件还是需要重新安装。

最后分享一个提高调试效率的小习惯：我会为常用的调试场景创建一套标准的虚拟串口配置，比如COM10<->COM11用于Modbus调试，COM12<->COM13用于AT指令调试，COM14<->COM15用于日志输出。每次开始新项目时，直接按这套配置创建虚拟串口，不用每次都重新想端口号怎么分配。串口调试助手里也把常用的波特率、数据位等参数保存成默认配置，打开就能用。这些准备工作花不了几分钟，但能省下大量重复配置的时间。