做串口屏项目最烦的事情是什么我投给“改UI”。文字、布局、颜色动一下就要用VisualTFT重新下载到实体屏上烧录一次、插拔一次、拍照确认一次到了调协议阶段更折磨MCU发一帧数据屏到底收没收、控件ID有没有写错全靠肉眼盯屏幕。后来我把大彩串口屏的开发流程改成“KEIL与虚拟串口屏联调”之后大部分烦恼没了单片机代码照常在KEIL里编译、下载、单步调试界面则在电脑上的虚拟串口屏里实时运行两者通过串口交互相当于把一个真实屏搬到了电脑上。这篇教程就围绕这套联调环境讲清楚怎么搭、怎么写代码、怎么排查问题给正在用大彩屏或者准备上串口屏的朋友一个可直接照做的参考。1. 虚拟串口屏联调到底解决了什么问题1.1 一套串口屏项目的完整开发链路大彩串口屏这类产品本质上是把“显示触摸”做成一个独立模块MCU通过串口协议去控制它。开发链路通常分两条线并行一条是界面线在VisualTFT里画页面、摆控件、设置属性生成工程另一条是逻辑线在KEIL里写主控代码通过串口发送指令让屏显示内容、接收屏上报的触摸事件。两条线最终的汇合点就在屏幕硬件上。传统的做法是两条线都做完后把界面工程下载到真实屏再把MCU程序下载到板子最后连接测试。一旦发现问题就要回到两条线里反复改、反复烧录。这个循环非常耗时间尤其当UI版本频繁调整、界面需要同时验证多套方案、或者手上根本没有对应型号实体屏的时候整个项目节奏都会被拖住。虚拟串口屏联调改变了这个汇合点界面工程不下载到硬件而是在VisualTFT的模拟运行窗口里直接跑MCU程序依然在KEIL里编译下载到开发板只要在物理层面把MCU的串口连到电脑虚拟屏就能像真实屏一样收到指令、显示画面、上报触摸事件。开发链路从“改界面→烧屏→烧MCU→联调”缩短为“改界面→虚拟屏继续跑→重编MCU→看效果”省掉的恰恰是联调阶段最频繁的烧录和插拔动作。1.2 虚拟屏和真实屏在联调阶段的对比对比维度真实屏联调虚拟串口屏联调硬件依赖需要对应型号的屏幕只需要一台PC和USB转TTLUI改版反馈速度重新生成工程、烧录、上电重新生成工程虚拟屏窗口刷新协议调试需要外部抓包工具或观察画面虚拟屏窗口自带收发日志多套界面方案对比需要多块屏或反复烧录可同时打开多个虚拟屏实例触摸事件模拟手指或触摸笔鼠标点击即可与KEIL Debug配合需要在屏和KEIL之间来回看两个窗口并排单步执行时同步观察从上手体验来看虚拟屏的最大价值不是替代真实屏的量产验证而是在联调阶段把“反馈回路”缩短到极致。真实屏的最终显示效果、亮度、触摸灵敏度、抗干扰能力虚拟屏永远替代不了这部分必须回归硬件测试但UI逻辑、协议字段、控件ID、页面切换、帧解析这些代码层面的问题虚拟屏完全可以兜住。1.3 适合谁来用这套联调方法最适合三类人一是做产品的嵌入式工程师UI和主控往往并行开发用虚拟屏可以提前联调不等屏幕到货二是做项目外包的开发者客户经常提出“先看看效果”的需求虚拟屏截图和录屏比口头描述直观太多三是刚入门串口屏的学生或新手手头没有屏也能把协议、控件、页面切换这套流程跑熟再上手真实屏几乎零成本。我自己的体会是虚拟屏联调不是“没有屏时的妥协方案”而是一个应该主动采用的开发习惯。即使在屏和板子都齐全的情况下日常小改动优先走虚拟屏只有涉及触摸手感、背光、开机时序、抗干扰这些必须真机验证的内容才动用实体屏整个项目节奏会舒服很多。2. 联调前需要准备的软件、硬件与串口通道2.1 软件清单与选型说明联调需要的软件总共四样VisualTFT、KEIL MDK、USB转TTL驱动、串口调试助手。如果选纯软件通道再额外准备一个虚拟串口对工具。VisualTFT是大彩官方组态软件界面设计、虚拟屏运行、工程下载全部在这里完成。选版本时尽量用较新的版本因为虚拟屏功能和协议库会跟随版本更新旧版本在部分新屏型上模拟行为可能和真实屏不一致。KEIL MDK方面大彩官方例程以STM32为主用MDK 5.x搭配对应芯片的Pack包即可如果你的MCU是8051内核那需要KEIL C51版本流程完全一样只是例程库不同。USB转TTL模块是连接MCU和PC的桥梁。CH340、CP2102、FT232这些常见方案都行其中CH340价格最低、驱动最普遍CP2102稳定性更好一些。驱动安装完成后在Windows设备管理器里确认串口号COM编号记住这个编号后面虚拟屏要直接选它。串口调试助手不是必须的但强烈建议装一个。联调遇到问题时先用串口助手确认MCU的TX有数据出来再排查虚拟屏段这一步能帮你把问题快速分成“MCU没发数据”和“屏没处理数据”两段排查效率翻倍。2.2 硬件清单与接线硬件部分只需要一块MCU开发板、一个USB转TTL模块、几根杜邦线。开发板推荐STM32F103C8T6这类常用型号大彩官方例程基本都有对应移植省去自己从零写初始化的工作。接线只有三根线需要注意MCU_TX接USB转TTL的RXMCU_RX接USB转TTL的TXGND接GND。很多人第一次联调没反应十有八九是TX和RX接反或者忘接共地。串口通信的参考电平是相对的不共地的话电压参考点不同数据必然乱码。如果你用的是带板载USB转串口的开发板比如常见的STM32F103C8T6蓝色Pill板板载串口已经连到了USB口那就直接插USB线不需要额外接CH340模块电脑上会出现一个COM口接线问题自动消解。2.3 串口通道的两种架构联调链路的核心问题是MCU的串口数据怎么到达运行在PC上的虚拟屏两种常见架构。第一种是物理串口直连也是最推荐的方式。MCU串口通过USB转TTL接到电脑的物理串口COM口VisualTFT虚拟屏直接打开这个COM口。链路是MCU UART → USB转TTL → PC COM口 → 虚拟屏。这个方案少一层转发延迟低、稳定、好排查。我日常联调基本都是这个架构。第二种是虚拟串口对。用VSPD或Configure Virtual Serial Port Driver在PC里创建一对虚拟串口比如COM3和COM4虚拟屏打开COM4。另一边可以让Proteus这类仿真软件的串口模型连接COM3实现在没有任何硬件的条件下做全链路仿真也可以用桥接工具把物理串口和COM3做转发让真实MCU接进来。第二种架构的灵活性更高但多了一层转发数据延迟和排查复杂度都增加没到必要程度不建议作为日常首选。2.4 串口通道搭建的三个关键注意点第一虚拟屏启动后会独占选中的COM口。如果你同时开着串口助手也去点开同一个COM口Windows会大概率报“端口被占用”或“打开失败”。因此确认某一段数据时用串口助手确认完就关掉再启动虚拟屏。第二VSPD创建的虚拟串口对只是软件层面的通道不会自动和物理串口互通。如果你创建了COM3-COM4虚拟对想用真实MCU接进来必须要有桥接程序把物理串口数据搬到COM3而不是直接在KEIL里指定一个虚拟COM号就能和虚拟屏通上。这点我在早期联调时误解了好久一度以为自己代码有问题其实链路根本没搭通。第三所有串口参数在搭建通道时就要统一口径波特率、数据位、停止位、校验位、流控这五个参数在MCU初始化、虚拟屏设置、串口助手三个地方必须完全一致。最常见的组合是115200、8、1、无校验、无流控。后续如果换波特率三个地方要一起改。3. 用VisualTFT做一个能被代码控制的界面工程3.1 新建工程与型号选择在VisualTFT中新建工程第一步是选择屏幕型号。型号和分辨率、横竖屏、触摸方式强相关联调阶段尽量选择你最终项目将使用的型号因为不同分辨率下控件坐标和色深会影响协议帧内容。比如5寸800x480和7寸1024x600的屏同样一个文本控件坐标范围不一样虚拟屏呈现的视觉效果和控件ID对应的协议行为都会有差异。选好型号后VisualTFT会生成一个默认工程通常包含一个页面0。页面和控件都有编号页面从0开始控件ID可在属性里设置。这部分是整个界面工程的基础后续KEIL代码要操作的就是这些页面ID和控件ID。3.2 页面和控件的规划控件ID就是你的协议接口很多人上手串口屏喜欢先摆满控件再考虑代码。我的建议是反过来先想清楚MCU要控制哪些内容再在VisualTFT里按需添加控件并把控件ID的规划写在工程注释里。举个例子一个温控面板界面MCU需要显示当前温度、设置目标温度、显示加热进度、接收用户点击“启动/停止”按钮。那界面工程就规划四个核心控件文本控件显示温度ID1、文本控件显示目标温度ID2、进度条控件显示加热进度ID3、按钮控件“启动/停止”ID4。页面保持默认页面0。这个规划的意义在于控件ID是MCU和屏之间协议交互的地址。MCU发一帧指令刷新文本指令里必然携带页面ID和控件ID虚拟屏收到后知道该把这个数据填到哪个控件上。如果ID不统一最常见的结果就是代码、界面都在跑但数据显示在另一个控件上或者界面纹丝不动。3.3 启动虚拟屏并设定串口参数界面工程设计完成后在VisualTFT工具栏点击“模拟运行”或“虚拟屏运行”按钮弹出虚拟屏运行窗口。在启动前要先设置串口参数。窗口里一般会提供串口选择、波特率、数据位、停止位、校验位的配置入口。选择物理串口直连的架构时串口就选USB转TTL在设备管理器里对应的COM号波特率选115200其他参数保持8、1、无校验、无流控。设置完成后点击启动虚拟屏窗口开始运行当前工程界面显示在窗口里下方往往还有一个日志区实时打印收到的协议帧数据。这个日志区非常重要它是你判断联调问题的第一手工具。当MCU向虚拟屏发送一帧数据日志区会立刻显示这帧数据的含义或者原始十六进制内容。利用它我们可以很直观地判断“MCU确实发了帧但帧解析失败”和“MCU根本没发数据”这两种截然不同的情况。3.4 虚拟屏日志区的妙用虚拟屏日志区等效于一个内置的协议嗅探器。真实屏联调时想看MCU到底给屏发了什么指令你得额外接一个逻辑分析仪或者串口抓包工具虚拟屏直接把这段内容展示在窗口里省了外接设备。我常用的一个操作是在KEIL代码的串口发送函数里加一个断点单步执行一次发送然后立刻切到虚拟屏日志看是否有对应帧。如果日志区有记录说明链路通、协议帧有效如果连记录都没有说明链路根本没通问题在串口物理连接或者参数配置上不需要继续纠结协议内容。这个“单步发一帧、日志确认一帧”的调试节奏是KEIL和虚拟屏联调最大的爽点。4. KEIL端串口通信代码从裸机串口到协议栈4.1 拿大彩官方例程还是自己从零写大彩官方提供了丰富的MCU例程VisualTFT安装目录下可以找到针对STM32、STC、51等不同平台的完整工程。初次联调强烈建议直接基于STM32官方例程改不要自己从零写协议解析。原因有两个。第一大彩串口屏的协议帧涉及帧头、长度、指令、数据、校验其中CRC16计算和多种指令类型自己从零写很容易埋雷官方例程已经把这些细节封装好直接调用API即可。第二官方例程里通常包含了协议解析框架比如一个逐字节喂数据的函数你只需要把串口中断收到的每个字节喂进去剩下的组帧、校验、回调都由例程处理。当然直接用例程不意味着无脑复制。你仍然需要把工程里的芯片型号、晶振频率、串口引脚和你的硬件核对一遍。很多联调失败案例最后查出来的原因不是协议代码而是晶振配置和实际板子不一致导致串口波特率偏差超过容错范围。4.2 串口初始化要点波特率是第一个坑串口初始化代码的核心是USART参数配置。以STM32标准外设库为例USART_InitTypeDef USART_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);这段配置要和虚拟屏的串口设置完全一致115200、8位数据、1位停止位、无校验、无流控。任何一项不一致虚拟屏收到的都是乱码或者干脆认为没有合法帧。需要注意STM32的串口波特率由APB时钟分频得到如果你的板子是外部25MHz晶振而代码里默认8MHz实际波特率会偏差巨大用串口助手看数据就是一片乱码。初始化时务必确认RCC时钟树配置正确。这是联调中极容易忽略但后果直接的一环。4.3 协议接收解析与控件刷新的代码思路大彩标准协议帧通常以固定的帧头开始包含长度字段、指令码、数据域和校验字段。官方例程会提供一个解析函数典型模型是在串口接收中断里逐字节送入void USART1_IRQHandler(void) { uint8_t data; if (USART_GetITStatus(USART1, USART_IT_RXNE) ! RESET) { data USART_ReceiveData(USART1); Protocol_Analysis(data); // 逐字节喂给协议解析器 } }Protocol_Analysis内部维护一个接收状态机按帧头、长度、数据、校验的顺序组帧完整帧校验通过后再根据指令码分发到对应的处理函数。触摸上报、页面加载完成通知等都是通过这套回调机制触发的。控件刷新方面例程通常封装了类似SetTextValue、SetProgressValue、ChangePage这样的API使用方式接近// 切换页面 ChangePage(PAGE_MAIN); // 设置文本控件内容 SetTextValue(PAGE_MAIN, TEXT_CUR_TEMP, (uint8_t*)26.5); // 设置进度条数值 SetProgressValue(PAGE_MAIN, PROGRESS_HEAT, progress_value, 100);不同系列屏幕、不同版本的例程函数名和参数顺序可能有差异。第一次使用前务必在VisualTFT的协议文档里确认当前型号的指令格式再对照例程函数体理解。直接抄网上的旧代码遇到固件指令格式升级的型号会出现“发送成功但屏无反应”的情况。4.4 FreeRTOS工程下的协议处理进阶如果你的工程跑了FreeRTOS串口中断里逐字节调用Protocol_Analysis仍然没问题但不要在中断里处理耗时逻辑比如刷新多个控件、执行复杂计算。更好的做法是协议解析到一条完整指令后用一个二进制信号量通知协议处理任务任务里再执行控件刷新和业务逻辑。void Protocol_OnFrameReceived(uint8_t *frame, uint16_t len) { BaseType_t xHigherPriorityTaskWoken pdFALSE; // 把帧数据存入待处理缓冲区实际项目建议用队列 memcpy(proto_rx_buf, frame, len); proto_rx_len len; xSemaphoreGiveFromISR(proto_semaphore, xHigherPriorityTaskWoken); portYIELD_FROM_ISR(xHigherPriorityTaskWoken); }这样串口中断只负责接收和组帧耗时的界面更新放在协议任务里避免中断处理时间过长影响系统的实时性。大彩不少行业应用都是跑FreeRTOS的多任务场景这个思路可以直接复用。4.5 KEIL Debug模式下观察协议变量的技巧联调时经常需要确认协议帧解析后有没有丢字节、校验有没有通过。最直接的办法是在KEIL Debug模式里观察结构体变量。KEIL的Watch窗口可以直接添加结构体变量并展开成员查看。比如定义一个协议帧结构体typedef struct { uint8_t header[2]; uint8_t len; uint8_t cmd; uint8_t data[64]; uint16_t crc16; } ProtocolFrame_t;在Watch 1窗口添加rx_frame展开就能看到每一帧解析后各字段的实际值和虚拟屏日志对照很容易定位是协议组帧问题还是控件ID问题。如果某个结构体成员比较多用Memory窗口按变量地址查看原始字节更直观。这一招在真实屏联调时同样好用但虚拟屏联调时因为双窗口同屏效率提升最明显。5. 联调全流程从KEIL运行到虚拟屏刷新的每一步5.1 上电联调的标准顺序联调不能上来就点KEIL的Download建议按这个顺序走每一步都确认无误再进下一步。第一步确认虚拟屏已经启动串口参数设置正确COM口未被其他软件占用。第二步打开串口助手打开同一个COM口把MCU程序下载进去后复位观察串口助手是否收到MCU发来的数据。这里收到的数据可能是乱码没关系只要能看到数据流就说明MCU的TX到PC的RX是通的。第三步关闭串口助手重新打开虚拟屏或者虚拟屏已启动则跳过复位MCU观察虚拟屏画面是否有变化。这个顺序的精髓在于先用串口助手把“MCU→PC”这一段打通再切换到虚拟屏去验证“MCU→屏”的完整链路。很多人跳过第二步直接上虚拟屏一旦没反应就不得不回过头来一步步拆链路反而更慢。5.2 双向链路验证不只是MCU到屏串口屏联调是双向的MCU给屏发指令只是其中一半屏上报触摸事件给MCU是另一半。验证反向链路时在虚拟屏窗口用鼠标点击之前放置的按钮控件如果该按钮配置了触摸上报虚拟屏会向串口发送一帧包含页面ID、控件ID的指令。MCU收到后在协议解析回调里设置一个全局变量或者调用printf输出日志if (cmd CMD_TOUCH_NOTIFY) { touch_flag 1; printf(Touch: page%d control%d\n, frame.page_id, frame.control_id); }在KEIL的UART打印窗口如果是软件仿真或者串口助手里看到这条日志就证明反向链路通了。注意虚拟屏的鼠标点击模拟的是触摸屏触摸事件如果你点击的是一个“切换页面”类型的按钮而且这个切换操作是屏内逻辑直接完成的屏幕可能在本地就切换页面了并不一定会通过串口上报只有按钮配置为需要上报触摸事件给MCU时才会产生串口帧。这也是很多人测试按钮反馈时发现“没反应”的常见原因。5.3 KEIL Debug模式与虚拟屏组合调试联调进入比较深入的阶段后推荐把KEIL和虚拟屏两个窗口并排放在一个屏幕上。在KEIL里对串口发送函数或协议解析函数设置断点单步执行一步就切到虚拟屏窗口看画面或日志变化调试节奏非常接近真人机交互。举例来说假设程序在SetTextValue发送文本指令后虚拟屏上对应的文本控件应该立刻变成新内容。你在KEIL里单步执行到SetTextValue内部可以看到组帧缓冲区的内容再执行完发送语句看虚拟屏文本是否变化。如果缓冲区内容正确但屏没变化问题多半在协议格式如果缓冲区内容本身就是错的那就先查控件的ID或者文本内容参数。另外KEIL的Logic Analyzer窗口也可以用来观察UART的TX引脚电平但说实话到这一步已经有些多余。虚拟屏日志已经把协议层的证据摆出来了硬件波形的问题用逻辑分析仪去测更容易判断。5.4 一个完整的进度条刷新实例用一个最简单但完整的实例把整个流程串起来MCU每500ms把进度条控件的值加1加到100后归零同时在文本控件里显示当前百分比。界面工程侧页面0放置一个进度条控件ID3、一个文本控件ID1。int main(void) { uint8_t progress 0; char display_buf[8]; SystemInit(); USART1_Init(); Protocol_Init(); while (1) { if (progress 100) progress 0; else progress; sprintf(display_buf, %d%%, progress); SetTextValue(0, 1, (uint8_t*)display_buf); SetProgressValue(0, 3, progress, 100); delay_ms(500); } }虚拟屏运行后下载程序并复位MCU能看到进度条从0缓慢增长到100文本同步更新百分比。如果某一帧进度条跳变、文本显示乱码对照上一章的排查链路逐项检查。这个例子虽然简单但已经覆盖了页面ID、控件ID、文本刷新、进度条刷新、周期发送这五个串口屏开发最核心的操作。实际项目的逻辑再复杂本质上都是这些基础操作的组合。6. 联调中最容易翻车的细节和排查链路6.1 虚拟屏“一动不动”时按这个顺序排查虚拟屏完全没响应时不要慌按下面的顺序从头查每一步都有明确结论。第一检查物理连接TX接RX没有GND共地没有USB转TTL在设备管理器里有没有正常识别并出现COM号。第二检查端口占用关闭串口助手确认虚拟屏设置里的COM号和设备管理器一致虚拟屏有没有点启动。第三检查MCU是否发数据用串口助手打开COM口复位MCU看是否收到任何数据。完全没数据问题在MCU串口配置或程序没跑起来有乱码多半是波特率或晶振配置问题有正常十六进制但虚拟屏无响应问题在协议帧格式继续走下一步。第四检查协议格式看虚拟屏日志区有没有“帧头错误”“CRC错误”之类的提示如果有说明数据到了屏但格式不符回KEIL里核对组帧代码和控件ID。这一条排查链路是我反复使用后总结出的最优顺序。它最大的好处是每次只处理一个变量先保证物理层通再保证数据层通最后才处理协议层问题。6.2 有数据但界面不刷新的隐性原因串口助手和虚拟屏日志都显示收到了帧但界面就是不刷新这时候别急着怀疑协议解析先查四个容易翻车的地方。一是页面ID和控件ID是否和VisualTFT工程一致。很多人改过界面后VisualTFT里控件ID变了KEIL代码还是旧ID帧发过来对应不上控件自然不显示。二是帧中的坐标或长度字段是否超出控件范围比如文本控件宽度只有50像素发送很长字符串超出部分按屏的处理策略可能被丢弃。三是文本编码不匹配。大彩部分屏型支持GBK、UTF-8等编码方式MCU发送的字符串编码和控件属性不一致屏幕上会显示乱码或者空白。四是虚拟屏型号和工程实际目标型号不一致导致控件配置加载异常。这四类问题都不会产生错误日志只能靠核对工程属性来排除。6.3 串口参数三件套和其他常见误区串口联调时最容易翻车的串口参数是波特率、校验位、流控这三项。波特率不一致接收端会得到码元错误虚拟屏日志通常直接报错或者根本解析不出帧头校验位不一致同样会产生帧错误流控如果误开了硬件流控而实际没有接线RTS/CTS数据可能一直发不出去。另一个常见误区是“KEIL工程里改了波特率虚拟屏就自动同步”。虚拟屏的波特率是在启动参数里手动设置的它不会自动跟随MCU。任何一次代码里改了串口初始化参数都要记得同步修改虚拟屏的串口设置或者干脆在代码里固定不要频繁改动。还有一点如果MCU和虚拟屏已经能正常通信但偶尔出现一帧丢数据优先怀疑两个原因一是MCU发送时没有等待发送寄存器为空就连续写入多字节导致数据覆盖二是中断处理耗时太长接收端的RXNE溢出。这种偶发问题在联调阶段最折磨人但只要把发送函数改成逐字节等待发送完成接收中断处理保持精简基本都能解决。6.4 触摸按钮不上报的坑虚拟屏上的按钮点击后MCU收不到事件这个问题几乎每个使用大彩屏联调的人都会遇到一次。原因前面提过按钮控件有两种工作模式一种是在屏端直接完成页面切换类操作另一种是把触摸事件上报给MCU由MCU决定响应逻辑。后者需要在VisualTFT的控件属性里明确开启触摸上报或配置为“按钮触发指令回传”。如果你的界面里按钮本来就是为了给MCU发指令务必检查这个属性有没有勾上。虚拟屏用鼠标点击时如果设置了上报日志区会立刻出现一帧触摸通知。日志区没有这帧就说明控件属性没配对有这帧而MCU没反应再回KEIL查协议解析回调。6.5 纯软件仿真联调ProteusKEILVSPD值得试吗有些朋友电脑前没有开发板想完全靠软件把KEIL、Proteus、虚拟屏串起来。思路是Proteus里的单片机仿真通过COMPIM串口模型连接到VSPD创建的虚拟串口对一端大彩虚拟屏连另一端。这套方案理论上可行我也试过。实测下来Proteus仿真串口的时序和真实USART外设有差异尤其在高波特率下容易丢字节虚拟屏日志偶尔会看到断帧。另外KEIL配合Proteus做Debug时需要额外安装Proteus VSM仿真驱动并分别在KEIL和Proteus侧配置整体步骤比真实开发板联调多出不少。我的建议是如果没有硬件这套纯软件方案可以作为了解串口屏协议的学习工具如果手头有几十块钱的开发板和USB转TTL还是优先用物理串口直连方案稳定性和调试效率都好太多。联调本身是为了减少开发阻力如果环境搭建比真实联调还复杂那就本末倒置了。最后再分享一个我实际工作中的小习惯每次联调前把要验证的协议帧、控件ID、波特率列在一个便签里贴在屏幕上。调试遇到问题先对照便签看有没有改漏再动手查代码。这个小习惯让我少走了很多弯路也推荐给你。