企业官网建设流程全解析

如果你跟我一样，经常在深夜写完一段串口收发代码，却发现手头既没有USB转TTL模块，开发板上唯一的串口又被别的传感器占着，只能把数据一条条打进调试器的Watch窗口里核对，那这篇文章就是写给你的。我在Keil MDK里折腾虚拟串口调试串口这套流程，前后试过VSPD、Com0Com、SSCOM、Commix这些工具，也踩过驱动签名、printf卡死一类的坑，最后的结论是：在MDK里把串口调试搬进纯软件环境，完全可行，而且对验证协议、缓冲区逻辑和上位机交互特别有用。

这篇文章不是教你背命令，而是把"为什么要用虚拟串口、虚拟串口到底是什么、没有硬件时怎么搭一条完整的串口调试链路"讲透。适合三类人看：刚接触STM32和Keil MDK的新手，手头缺硬件的学生党，以及需要在PC端联调串口协议但又不想频繁拔插USB转TTL的工程师。后面所有步骤我都在Windows 10/11 + Keil MDK 5.36/5.37 + STM32F103的环境下实际跑过，你照着操作基本能复现。

1. 没有USB转TTL时，串口调试为什么卡在"写代码容易验证难"

先说一个很现实的问题：串口调试这个动作，本质上是在验证两件事——数据格式对不对和时序逻辑对不对。但大多数时候我们手边没有完整的硬件链路，尤其是写上位机、做通信协议、验证环形缓冲区时，缺一个USB转TTL模块就卡住了。

1.1 典型场景：硬件不在手边，但协议必须调

我遇到最多的情况是这三类：

• 写了一个STM32程序，要通过USART向上位机上报传感器数据，但开发板还在路上，手边只有一台装了Keil MDK的Windows电脑。
• 项目里有两个MCU需要通过串口通信，A板发帧、B板解析，但手里只有一块板子，另一块还没打样。
• 正在写一个Qt/C#/Python的串口上位机程序，需要连续接收数据帧并解析，但下位机的固件还没写完，没有真实设备可连。

这些场景的共同点是：**代码逻辑有一半在MCU里，另一半在PC端，而中间的物理连接不存在。**如果非要等硬件到位再调，项目进度至少要往后拖一两天。虚拟串口的作用，就是把中间那条物理串口线先从软件层面"画"出来，让两侧的程序先跑起来。

1.2 虚拟串口解决的是逻辑验证，不是电气特性

这里必须先泼一盆冷水：虚拟串口模拟不了电平翻转、模拟不了线路噪声、模拟不了波特率失配时那种偶发乱码，也模拟不了RS485的方向切换时序。它只能在数据链路层上给你一个足够真实的串口编程接口。

打个比方：真实串口调试是"两个人隔着一条马路喊话"，你要验证的是声带、距离、环境噪音这些物理因素；虚拟串口相当于"两个人用对讲机在一个房间里通话"，你验证的只是"我说的话你能不能听懂"。协议格式、帧头帧尾、校验和、超时重发这些逻辑，用虚拟串口完全能调明白；但你要是担心实际线缆过长导致波形畸变，那还得靠真机测试。

所以我的建议是：**虚拟串口负责把逻辑问题清零，真实硬件负责验证电气边界。**二者是先后关系，不是替代关系。

2. 虚拟串口的模拟原理：为什么它总是一对一对地出现

很多人第一次打开VSPD这类软件时，会有一个困惑：为什么创建串口不能只建一个COM3，非要同时创建COM3和COM4？回答这个问题，就理解了虚拟串口的全部原理。

2.1 VSPD这类软件到底做了什么

VSPD（Virtual Serial Port Driver）这类软件，本质上是在Windows系统里安装了一个虚拟串口驱动。它向操作系统注册出若干标准的COM口设备，这些COM口在设备管理器里看起来和真实串口一模一样，任何调用CreateFile、ReadFile、WriteFile这些Windows串口API的程序都能正常打开它们。

注意这个细节很重要：驱动层面提供的是一套完全兼容标准串口的接口。所以串口调试助手、自己写的Python脚本、LabVIEW程序，都不需要做任何修改，当成普通串口打开就行。

关键区别在于数据通路。真实串口的数据流是：

MCU的USART外设 → 电平转换芯片（MAX3232等） → USB转TTL芯片 → Windows串口驱动 → 应用程序

而虚拟串口对的数据流是：

应用程序A → Windows串口API → VSPD驱动 → 内存管道 → VSPD驱动 → Windows串口API → 应用程序B

中间没有电平转换，也没有USB包传输，就是驱动在内存里做数据搬运。

2.2 为什么必须成对创建：串口是双向管道

串口通信永远是双向的。一个应用程序往COM3写数据，这些数据最终要能被另一个应用程序从某个地方读到。如果虚拟串口不成对存在，数据写了就丢了，收发链路是断的。

VSPD的做法是创建一个"串口对"：COM3和COM4被当作一条管道两端。往COM3里写的数据，会从COM4里被读出来；反过来往COM4里写，COM3能读到。

这个设计很像一根真实的串口线：一头插在设备A上，一头插在设备B上。你愿意把哪个口分配给串口助手，把哪个口分配给自己的程序，完全取决于你想让谁收、谁发。

2.3 波特率在虚拟串口里的真实意义

虚拟串口并不是完全无视波特率。VSPD在创建串口对时，允许你设置初始波特率，驱动也会记录每次程序打开的波特率参数。但由于数据本身走内存管道，实际传输速率不取决于波特率，而取决于驱动内部管道写得多快。

这意味着什么？你可以用9600波特率打开虚拟串口，程序收发数据照样飞快，不会像真实串口那样每秒只传9600个位。但有一个坑必须提醒：如果你在程序里做了基于波特率的超时计算，比如"每字节传输时间=10bit/波特率"，在虚拟串口上这个计算结果会严重偏离实际，导致超时逻辑误判。我在调Modbus协议时就被这个坑过：真实设备上1.5字符超时是几百微秒，虚拟串口上却几乎瞬时完成，一开始怎么调都对不上。

结论是：虚拟串口上的波特率只具有"形式意义"，你最好把波特率设成和目标设备一致，方便后续无缝切换到真机，但不要依赖它做时序计算。

3. 工具选型与安装：VSPD、Com0Com与串口调试助手的搭配

这个领域工具不少，但真正稳定好用的其实就那么几个。我从实用角度做个对比，然后说清楚安装时最容易出问题的地方。

3.1 主流的虚拟串口软件横向对比

我自己实际用过VSPD、Com0Com和Windows自带的串口映射功能，列个表方便你选：

我的主力工具是VSPD，原因有三个：一是创建串口对时可以自定义串口号，避免和已有的蓝牙串口冲突；二是它支持把一个物理串口扩展成多个虚拟串口，这样两个程序可以同时打开同一个物理串口，一个负责收数据，一个负责记录日志，这在真机联调时非常有用；三是卸载干净，不会像某些驱动软件一样卸完系统还残留一堆无效COM口。

如果你预算有限，Com0Com完全够用。它不需要安装GUI，在命令行里执行install.bat就能创建出默认的COM3/COM4对，也能通过修改参数创建多对串口。但要注意，Com0Com在Windows 10/11上需要驱动签名，步骤比VSPD多一些。

3.2 串口调试助手的选择：SSCOM、Commix、XCOM

有了虚拟串口，还得有个"对面的人"来收发数据。串口调试助手我前后换过很多，现在固定用的组合是：

• 接收MCU主动上报的数据：用SSCOM。它收数据时不会抢CPU，支持hex和ascii混合显示，保存日志也方便。
• 模拟上位机发送数据帧：用Commix或者直接写Python脚本。Commix支持定时发送、支持按帧间隔发送，适合模拟周期上报。
• 临时看个数据：XCOM也行，界面干净，但功能相对简单。

这里有个容易被忽略的点：虚拟串口调试时，数据收发速度可能非常快，如果调试助手显示性能不行，几千条数据刷过去界面直接卡死。所以工具尽量选SSCOM或Commix这类老牌稳定的，别用那种界面花哨的小众助手。

3.3 安装与驱动签名的坑

VSPD安装本身不复杂，一路Next就行。但有两个坑我踩过：

第一，某些版本在Windows 11上安装完创建串口时会提示"驱动未签名"。解决方法是进入Windows的"高级启动"，选择禁用驱动程序强制签名，再重新安装一次驱动。注意这个选项只对当前启动生效，重启后会失效，所以最好一次装完再创建串口对。

第二，创建虚拟串口对时，如果提示串口号被占用，别急着把那个口删掉。先在设备管理器里看清楚是哪个程序占用的，有些蓝牙模块会预占COM3到COM6，你把VSPD的串口对改成COM7/COM8就好，不要去动蓝牙设备。

4. STM32工程侧的准备工作：USART初始化、printf重定向与收发方式取舍

虚拟串口只是一个桥梁，真正要调试的代码还是得在Keil MDK里跑。这一节我把STM32这边需要做好的准备工作讲清楚，顺序是：USART初始化、printf重定向、收发方式选择。这些是一切调试的基础。

4.1 STM32F103的USART1初始化示例

我用标准外设库和HAL库都可以，不过考虑到网上资料最多、新手最容易上手的还是标准外设库加F103。下面是一段我常用的USART1初始化代码，波特率115200、8位数据、无校验、1位停止位：

void USART1_Config(void) { GPIO_InitTypeDef GPIO_InitStructure; USART_InitTypeDef USART_InitStructure; NVIC_InitTypeDef NVIC_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1 | RCC_APB2Periph_GPIOA, ENABLE); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_9; // TX GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOA, &GPIO_InitStructure); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_10; // RX GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING; GPIO_Init(GPIOA, &GPIO_InitStructure); USART_InitStructure.USART_BaudRate = 115200; USART_InitStructure.USART_WordLength = USART_WordLength_8b; USART_InitStructure.USART_StopBits = USART_StopBits_1; USART_InitStructure.USART_Parity = USART_Parity_No; USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None; USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx; USART_Init(USART1, &USART_InitStructure); NVIC_InitStructure.NVIC_IRQChannel = USART1_IRQn; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0; NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0; NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE; NVIC_Init(&NVIC_InitStructure); USART_ITConfig(USART1, USART_IT_RXNE, ENABLE); USART_Cmd(USART1, ENABLE); }

这段代码没什么特殊的地方，值得注意的就是中断优先级。如果你后面在FreeRTOS或者复杂中断系统里调试串口，优先级要仔细规划，否则数据收发时可能出现不可预期的丢字节。

4.2 printf重定向：不勾选MicroLIB就会卡死

在Keil MDK里用printf输出串口日志，是最常用的调试手段。标准做法是重定向fputc：

int fputc(int ch, FILE *f) { USART_SendData(USART1, (uint8_t)ch); while (USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET); return ch; }

但这里有一个非常关键的设置：需要在Keil MDK的Options for Target → Target标签页里勾选Use MicroLIB。如果不勾选，程序编译没问题，运行时会卡在printf的第一条语句上，因为标准C库默认把printf输出到半主机模式的调试通道，不死等在哪才怪。

我当时第一次遇到这个问题，排查了很久。程序跑在MDK的仿真器里，点全速运行，代码就停在printf内部，Watch窗口怎么查都查不出问题。最后才想起来是半主机模式没有用MicroLIB关掉。这个坑几乎每个用MDK的人都会踩一次，先写在这里，后面章节还会讲排查链路。

4.3 收发方式取舍：调试阶段别一上来就DMA

串口收发有轮询、中断、DMA+空闲中断三种经典方式。很多新手一上来就照搬例程用DMA，结果虚拟串口调试时数据时序不对，反而不知道问题出在哪。

我的建议是分场景选择：

• 调试阶段验证逻辑：轮询发送+中断接收足够。简单、容易定位问题，printf也不受影响。
• 验证协议帧解析：中断接收，配合一个简单的状态机，能看出每一字节到达的时机是否正确。
• 压测大数据吞吐：DMA+空闲中断。但前提是前面的逻辑已经用中断方式调通了，不然DMA的缓冲区指针和中断回调叠加在一起，排查难度会翻倍。

下面是一段中断接收的示例，我把收到的字节放进环形缓冲区，避免在主循环里频繁关中断：

#define RX_BUF_SIZE 256 volatile uint8_t rx_buf[RX_BUF_SIZE]; volatile uint16_t rx_head = 0; volatile uint16_t rx_tail = 0; void USART1_IRQHandler(void) { if (USART_GetITStatus(USART1, USART_IT_RXNE) != RESET) { uint8_t data = USART_ReceiveData(USART1); uint16_t next = (rx_head + 1) % RX_BUF_SIZE; if (next != rx_tail) { rx_buf[rx_head] = data; rx_head = next; } USART_ClearITPendingBit(USART1, USART_IT_RXNE); } }

有了这个环形缓冲区，你就可以把"收串口数据"和"解析数据帧"解耦：中断只管往缓冲区里塞字节，主循环里做轮询解析。这个结构在真实硬件和虚拟串口调试时行为完全一致，可以无缝切换。

5. 实战链路：MDK里最常见的三种虚拟串口调试连接方式

铺垫了这么多，终于到正题了。我在实际开发中总结出三种在Keil MDK环境下用虚拟串口调试串口的连接方式，从零依赖到全仿真，按需选择。

5.1 链路A：零外部依赖——MDK Simulator自带的串口窗口

如果你的需求只是看看printf输出、验证某个函数的执行顺序，那连虚拟串口软件都不用装。Keil MDK内置的Simulator模式可以模拟STM32的外设，包括USART。

操作步骤：

1. 在Keil MDK中打开工程，点击Options for Target → Debug标签页。
2. 选择"Use Simulator"，点击OK。
3. 编译工程，点击Start/Stop Debug Session进入仿真。
4. 在仿真界面中，点击View → Serial Windows → UART #1，打开串口窗口。
5. 全速运行程序，printf输出的内容会直接显示在这个串口窗口里。

这个方式的优点是完全免费、零配置、一个人就能玩。缺点是它只能在MDK的窗口里看，外部程序读不到这些数据，没法做上位机联调。适合刚移植完代码、想快速确认基本逻辑的新手。

5.2 链路B：VSPD虚拟串口对 + 串口助手 + 模拟MCU程序，完整体验闭环

这个链路是这篇文章的核心，也是我建议所有要做串口协议开发的人掌握的。它的思路是：在PC上创建一对虚拟串口COM3/COM4，COM4接串口助手（模拟接收端），COM3接你自己的串口测试程序（模拟MCU发送端），从而在没有真实硬件的情况下，做一次端到端联调。

具体操作：

1. 安装VSPD，打开主界面，点击"Add pair"，创建COM3和COM4。
2. 打开SSCOM，选择COM4，波特率115200，8N1，打开串口。
3. 用Python、C#或者C++写一个小程序，打开COM3，按协议定时发送数据帧。以Python为例：

import serial import time ser = serial.Serial('COM3', 115200, timeout=1) while True: # 模拟MCU周期上报：帧头(0xAA) + 长度(0x02) + 数据(0x01 0x02) + 校验(0x03) frame = bytes([0xAA, 0x02, 0x01, 0x02, 0x03]) ser.write(frame) time.sleep(1)

4. 回到SSCOM窗口，会看到每一秒收到一帧完整数据。如果SSCOM支持hex显示，数据看起来会非常直观。

有人会问：这个流程和Keil MDK有什么关系？关系在于，你在MDK里写的上位机联调代码或者辅助测试代码，可以复用这套链路。比如你在工程里写了一段"模拟另一端设备"的代码，在Simulator里跑或者临时抽出来在PC上编译跑，都能直接往虚拟串口上灌数据。

更进一步，如果你正在做的是两个MCU之间的串口协议联调，可以在MDK里把设备A的程序编译好刷到真实板子上，然后把板子的USART TX/RX接到USB转TTL模块，模块插到电脑上形成物理COM口。接着用VSPD把这个物理COM口扩展成两个虚拟串口，一个给串口助手监控数据，一个给设备B的上位机解析程序。这就是链路B的进阶用法，也是"虚拟串口"在真实开发中最有价值的使用场景。

5.3 链路C：MDK调试器 + 真机串口 + VSPD扩展，多个软件同时监视同一路串口

第三种链路是工程上最常见的需求：程序在STM32真机上跑，串口输出的日志只有一根USB转TTL线，但你想同时用SSCOM看数据、用自己写的Python脚本做关键字告警、用串口监视器抓协议帧。这三个程序都想打开同一个COM口，Windows默认只允许一个程序独占。

VSPD的"Split"功能可以解决这个问题。它能把物理COM5"复制"成COM6、COM7等多个虚拟串口，每个虚拟串口都能独立打开，数据流在所有串口之间广播。于是你可以在SSCOM里看着数据滚动，Python脚本同时在后台做协议统计，两边互不干扰。

这个用法有个好处：不会影响原程序的调试体验。因为真正的物理串口只有一个程序在读写，VSPD只是做了一个分发操作，数据给多个监听者各复制一份。对正在跑的MCU来说，它完全感知不到后面有几个程序在监听。

6. 进阶：协议验证、模拟双MCU通信与DMA缓冲区调试

基础链路跑通之后，就可以开始做一些真正的调试工作了。这一节分享三个我在实际项目中反复用到的进阶玩法，全是基于虚拟串口实现的。

6.1 用虚拟串口验证自定义协议帧的边界条件

做通信协议调试，最怕的不是正常数据，而是异常数据。真实硬件调试时，想制造"缺字节""多字节""校验错误"这些异常比较麻烦，因为你没法精确控制串口线路上出现的每个字节。

但虚拟串口让这一切变得非常简单。你可以在COM4端用Commix的定时发送功能，手动输入一段只有帧头没有帧尾的数据，然后观察另一端设备程序是否能在超时后正确报错；也可以故意把校验位算错，看看协议栈的容错逻辑是否有效。

我在调一个自定义的二进制协议时，就是在虚拟串口上一次性构造了几十种异常帧，批量跑完才上真机。如果没有虚拟串口，这些测试全得靠按键和跳线去造，效率完全不是一个量级。

6.2 模拟双MCU通信：一个程序扮演两个角色

很多项目里是两个MCU通过串口协作，比如主控板向传感器板发查询指令，传感器板回传数据。在没有第二块开发板的情况下，虚拟串口对可以让你在同一台PC上模拟出两端行为。

操作方法是写两个Python/串口脚本，一个模拟主控端的查询逻辑，一个模拟传感器端的应答逻辑，分别打开COM3和COM4。然后在MDK的Simulator里跑你的解析代码，用串口窗口确认数据帧是否被正确解析。

我还试过更极致的方式：在Windows里用pySerial写一个虚拟传感器固件，专门按协议回传传感器数据，让MDK Simulator里的主控程序通过虚拟串口和外部的虚拟传感器完成一次完整的"握手-查询-应答-超时重试"流程。这样整条链路都不需要真实硬件，但逻辑层面和周整机联调几乎一致。

6.3 Debug模式下查看结构体变量与环形缓冲区

串口调着调着，难免要深入Debug模式看内存。很多人在MDK的Watch窗口里只能看到普通全局变量，看到数组和结构体就不知道怎么看。这里分享两个实用技巧。

第一个技巧是Watch窗口直接展开结构体。你在Watch窗口里添加结构体变量名，点开前面的加号，就能逐成员查看。如果结构体里有数组，还可以输入结构体名.数组名, 数组长度的形式，比如：

device_status.rx_buffer, 64

这样能将数组的前64个字节以列表形式展示。

第二个技巧是在仿真时观察环形缓冲区。你可以把示例代码里的rx_buf和rx_head、rx_tail都添加到Watch窗口。程序每收到一帧数据，刷新一下Watch，就能看到缓冲区的读数在变化。如果发现head和tail的距离越来越大，说明数据处理速度跟不上接收速度，这就是典型的丢数据前兆。

7. 实测中的坑与排查链路：虚拟串口不工作、HardFault、printf卡死

最后这部分，我把实际调试中踩过的坑和排查思路完整记录下来。每个坑都给出"现象→排查过程→结论→解决办法"的完整链路，希望能帮大家省下一些无谓的排查时间。

7.1 虚拟串口打不开，提示"串口被占用"

现象：VSPD创建了COM3/COM4，串口助手打开COM3报"端口被占用"。

排查过程：

1. 打开设备管理器，查看"端口（COM和LPT）"，确认COM3确实存在。
2. 打开任务管理器，看看是不是有残留的Python进程或其它串口程序在后台占用了COM3。
3. 在命令行执行mode命令，可以列出系统所有COM口状态。

结论：绝大多数情况是某一次运行的程序异常退出，没有正常释放串口句柄。Windows不会自动回收那个句柄，导致串口一直被占用。

解决办法：重启一次系统，或者在任务管理器里把所有可疑进程结束掉，再重新打开串口。如果经常遇到，建议在程序里加入异常退出时的关闭逻辑，比如Python的try...finally里调用ser.close()。

7.2 MDK仿真时printf卡死

现象：工程在仿真模式下全速运行，程序停在printf内部，单步也出不来。

排查过程：

1. 点击暂停按钮，程序停止的位置在fputc里的while循环中。
2. 查看USART的SR寄存器，发现TXE标志一直为0，说明USART外设状态不对。
3. 检查工程配置，发现Options for Target里没有勾选Use MicroLIB。

结论：MDK的标准C库printf默认走半主机模式，会触发软件中断等待调试器处理。工程没勾MicroLIB，printf自然就卡住了。

解决办法：勾选MicroLIB，重新编译下载。这个坑我在第4章提到过，但因为太典型，值得放在排查链路里再强调一次。

7.3 虚拟串口数据收不到，但程序运行正常

现象：设备程序往虚拟串口发送数据，串口助手那边收不到任何内容。

排查过程：

1. 先确认发送端程序打开的是哪个串口，接收端打开的是另一个串口。很多人里把COM3的写操作对应到COM3的读操作，那当然收不到——数据是从COM4出来的。
2. 检查串口助手的波特率，虽然虚拟串口对波特率不敏感，但不匹配时有些助手会拒绝显示。
3. 用VSPD自带的诊断工具看两个端口的连接状态，确认串口对没有被断开。

结论：这个坑其实是我自己粗心，把虚拟串口对都想当然地当作"一个口收发"，忽略了它本质上是一条管道两端。

解决办法：在调试初期就用串口助手同时打开两个口，先手动确保COM3发数据COM4能收到，再做上位机联调。快速验证虚拟串口对是否正常，这一步很重要。

7.4 真机调试时进入HardFault

现象：代码在Simulator里跑得好好的，刷到真机上运行一会儿就进入HardFault_Handler。

排查过程：

1. 在HardFault_Handler里打断点，查看SCB->HFSR、SCB->CFSR寄存器的值。
2. 发现是总线错误（BusFault），访问了非法地址。
3. 检查指针，发现是DMA接收缓冲区的地址没有正确对齐，或者缓冲区内存在中断里被意外修改。

结论：这个坑不能全怪虚拟串口，但在虚拟串口环境下写DMA代码时特别容易忽略地址对齐问题。因为Simulator对内存访问的严格度不如真实硬件，很多非法访问在仿真时不报错。

解决办法：DMA缓冲区的定义使用__attribute__((aligned(4)))，并确保缓冲区生命周期覆盖整个DMA传输过程，避免在栈上定义大块DMA缓冲区。

7.5 常用串口调试工具与应对场景速查

写在最后的个人体会

折腾了这么久，最大的体会是：虚拟串口调试串口只是一个工具，它不能代替你理解USART外设的中断标志位、DMA传输的优先级、协议帧的状态机设计，但它能把这些逻辑层面的问题从"看不见摸不着"变成"随时可以复现、随时可以制造异常"。

我现在的习惯是：先在MDK里用Simulator快速过一遍代码逻辑，再用VSPD和串口助手做一轮协议级联调，最后才接真实硬件处理电气和时序问题。这样三明治式的调试流程，让我省下了大量等待硬件、拆接线、抓波形的时间。尤其是做双机通信和上位机协议对接时，虚拟串口几乎是不可替代的效率工具。

最后分享一个小技巧：用VSPD创建串口对时，把两端的波特率都设成你项目最终的通信波特率，比如115200或460800。这样以后切到真机时，所有程序都不用改配置，只需要把串口号从虚拟的COM3改成真实设备的COM口就能无缝运行。我在几个项目里都是这么干的，省了不少来回改配置的功夫。