轻量级Qt6上位机调试工具：JSON-RPC协议高效调试实践-育师

1. 项目概述：为什么一个“轻量易扩展”的上位机调试助手值得重写一遍

我做上位机开发快八年了，从最早的串口助手加Excel手动解析，到用LabVIEW搭界面、C#写通信逻辑，再到后来用Qt5写BMS通用调试工具——踩过的坑比走过的线都多。去年给一家光伏逆变器厂做现场支持，发现他们工程师还在用三个窗口并排：一个串口调试助手发指令，一个Notepad++粘贴JSON响应，再开个浏览器JSON格式化插件看结构。一问才知道，不是不想用现成工具，而是“太重”——动辄200MB安装包，启动要等8秒，改个字段就得重启，加个新协议得重编整个工程。那一刻我就想：与其在别人写的框架里缝缝补补，不如从头造一个真正为嵌入式现场服务的调试助手。

Solar Debugger就是这个念头落地的结果。它不是一个“功能堆砌型”上位机，而是一个以协议调试效率为第一目标的轻量级终端。核心关键词很直白：Qt6 + C++ + JSON + 上位机，但每个词背后都有明确取舍。比如选Qt6不是因为“新”，而是它的QML+C++混合架构让UI热重载成为可能；用C++不是为了炫技，而是要直接操作串口句柄、控制USB CDC设备、对接自定义HID协议；JSON也不是随便选的，而是因为90%以上的新型光伏设备（逆变器、储能PCS、汇流箱）都已弃用传统Modbus ASCII，转向基于HTTP/HTTPS或WebSocket的JSON-RPC交互。你打开Solar Debugger，主界面只有三块区域：左侧设备连接栏（支持串口/USB/CAN/网络四类物理层）、中间JSON编辑区（带语法高亮、自动缩进、实时校验）、右侧结构化视图（自动展开JSON树，点击字段可一键复制路径或值）。没有菜单栏、没有工具栏、没有状态栏——所有操作通过右键上下文菜单和快捷键完成。启动时间实测1.3秒（i5-8250U），内存占用峰值42MB，静态链接后单文件发布体积仅18.7MB。它解决的不是“能不能连”，而是“连上之后，改一个参数、发一次请求、看一眼响应，总共耗时能不能压到3秒内”。

适合谁用？不是给刚学C++的学生练手的玩具，而是给一线嵌入式工程师、FAE现场支持、BMS算法验证人员准备的“数字万用表”。如果你常遇到这些场景：调试新固件时要反复修改JSON payload里的voltage_threshold字段；需要对比两台设备返回的JSON结构差异；或者在客户现场，客户电脑只有Win10基础环境，连.NET Framework都没装——那Solar Debugger就是为你设计的。它不替代VS Code或Qt Creator，而是作为它们的“外设”存在：你在IDE里写完固件，用Solar Debugger立刻验证通信逻辑是否正确。这种定位，决定了它从第一天起就拒绝“大而全”，只死磕“快、准、稳、可延展”。

2. 架构设计与技术选型：为什么是Qt6+C++，而不是Electron或Python

2.1 拒绝Electron：性能与部署的硬伤

很多人第一反应是“做个Web前端+Node.js后端不更简单？”——我试过。用Electron搭了个原型，功能差不多，但现场测试结果让人绝望：在一台工控机（Intel Celeron J1900）上，启动时间12.6秒，首次JSON解析卡顿明显，切换串口设备时UI冻结3秒以上。根本原因在于Electron的架构本质是“把Chrome浏览器打包进去”，而我们的用户场景是：设备可能连在USB转串口芯片（CH340）上，波特率设为921600，每秒收发上百帧JSON数据。Electron的JS主线程根本扛不住高频IO事件循环，必须额外开Worker线程，但Worker又无法直接访问串口API，还得通过IPC中转，延迟叠加。更致命的是部署：客户现场电脑往往禁用管理员权限，Electron要求安装Visual C++ Redistributable，而很多产线电脑连Windows Update都被禁用，装个VC++2015运行库都得找IT部门批一周。Solar Debugger用Qt6静态链接，一个.exe拖过去就能跑，连注册表都不碰——这是工业现场的生命线。

2.2 摒弃Python：跨平台与实时性的妥协

Python生态里有PySerial+PyQt5，开发速度确实快。但我做过对比测试：用Python写的同类工具，在接收连续JSON流（每帧200字节，100Hz）时，CPU占用率飙升至65%，且出现丢帧（实测丢帧率0.8%）。问题出在CPython的GIL（全局解释器锁）上——当串口线程收到数据，触发JSON解析时，UI渲染线程被阻塞，导致界面卡顿。而C++的std::thread可以完全绕过GIL，用QThread+moveToThread实现真正的并行：串口读取、JSON解析、UI更新三者互不干扰。更重要的是，Python打包成exe后体积动辄150MB（含完整解释器），而Solar Debugger静态链接Qt6后仅18.7MB，对U盘拷贝、邮件发送、远程桌面传输都极其友好。另外，客户常提的一个需求：“能不能在无网络环境下解析JSON Schema？”——Python需要pip install jsonschema，而C++用nlohmann::json自带Schema验证模块，编译时直接集成，零依赖。

2.3 Qt6的不可替代性：QML与C++的黄金组合

选Qt6而非Qt5，关键在QML的成熟度。Qt5的QML对复杂列表渲染（如JSON树形结构）性能一般，而Qt6的QML引擎重构后，ListView的滚动帧率稳定在60FPS。Solar Debugger的JSON结构化视图，底层用QAbstractItemModel封装nlohmann::json对象，上层用QML的TreeView组件渲染。这样做的好处是：UI逻辑和数据逻辑彻底分离。当我需要新增一种设备协议（比如支持CAN FD的JSON over CAN），只需继承基类ProtocolHandler，重写parse()和serialize()两个纯虚函数，QML层完全不用动——因为模型接口是统一的。QML还提供了强大的状态机（State Machine）能力，比如“连接中”状态会自动禁用发送按钮、显示旋转图标，“断开”状态则恢复按钮并清空历史记录——这些状态流转逻辑，用QML的SignalTransition几行代码就能搞定，比C++写一堆if-else清晰得多。至于为什么不用纯QWidget？因为QWidget做动态树形结构太重，每次expand/collapse都要重建整个widget树，而QML的Delegates机制让节点按需渲染，千级JSON字段也能流畅展开。

2.4 JSON作为核心协议：不只是格式，更是契约

标题里强调JSON，不是跟风，而是工程现实倒逼的选择。翻看近3年光伏行业新发布的设备SDK文档，92%明确要求“通信协议采用JSON-RPC 2.0标准”，剩下8%也提供JSON兼容模式。为什么？因为JSON天然支持嵌套结构，能精准描述BMS的电池簇（pack）、模组（module）、单体（cell）三级拓扑；它的字符串键名让字段语义一目了然（"soc"比"0x01"直观得多）；而且现代MCU（如STM32H7系列）跑轻量级JSON库（cJSON、parson）毫无压力，Flash占用<10KB。Solar Debugger的JSON处理引擎，底层用nlohmann::json，但做了三层加固：第一层是输入过滤——自动剥离BOM头、替换\r\n为\n、检测UTF-8非法字节；第二层是结构校验——对JSON-RPC响应，强制检查"jsonrpc":"2.0"、"id"字段是否存在；第三层是类型安全——当用户双击某个字段（如"temperature"）编辑时，会根据Schema定义（如果存在）限制输入类型（数字/字符串/布尔），避免发错格式导致设备复位。这比单纯“能格式化JSON”深得多——它是把JSON当作设备与上位机之间的契约文本来对待。

3. 核心模块详解：从串口驱动到JSON Schema验证的全链路拆解

3.1 物理层抽象：统一设备接入模型

Solar Debugger支持四种物理连接方式：串口（RS232/RS485）、USB CDC（虚拟串口）、CAN总线（通过SocketCAN或Peak USB卡）、TCP/IP网络（HTTP/WebSocket）。表面看是四个模块，实则共用一套抽象层——DeviceInterface基类。它的设计哲学是：“设备只是数据管道，协议才是灵魂”。比如串口和USB CDC，在Linux下都是/dev/ttyACM0，在Windows下都是COM3，底层驱动调用完全一致；而CAN设备，无论用SocketCAN还是PCAN，最终都映射为can0或PCAN_USBBUS1这样的逻辑名。Solar Debugger的设备管理器，不关心你接的是什么硬件，只关心你选的是哪种传输协议（Transport Protocol）：UART、CAN、TCP、WebSocket。当你在连接面板选择“CAN”时，程序会自动加载CanTransportPlugin，该插件负责初始化CAN控制器、设置波特率（500k/1M）、配置过滤器（只收ID为0x123的帧）。所有设备插件都遵循同一接口：

class DeviceInterface { public: virtual bool open(const QString& config) = 0; // config是JSON字符串，含波特率/ID等 virtual void write(const QByteArray& data) = 0; virtual QByteArray read() = 0; // 非阻塞，返回已缓存数据 virtual void close() = 0; };

实操中最大的坑是串口权限。Linux下普通用户无法直接读写/dev/ttyUSB0，传统方案是sudo usermod -a -G dialout $USER，但这要求用户重启。Solar Debugger的做法是：在open()时尝试打开设备，若失败，则弹出提示框，内嵌一个bash脚本执行sudo chmod a+rw /dev/ttyUSB0（需用户输密码）。这个脚本由Qt的QProcess调用，执行完立即生效，无需重启。Windows下更简单，用Windows API的CreateFile直接打开COM端口，但要注意：某些USB转串口芯片（如FTDI）在快速插拔后，系统可能残留无效句柄，导致CreateFile返回INVALID_HANDLE_VALUE。解决方案是在open前先枚举所有COM端口，用QueryDosDevice确认端口真实存在，再尝试打开——这个细节，90%的开源串口工具都忽略了。

3.2 协议解析引擎：JSON-RPC与自定义协议的双模支持

Solar Debugger默认按JSON-RPC 2.0规范解析数据，但实际项目中，很多设备厂商的JSON是“伪标准”——比如把"result"字段写成"data"，或把错误码放在"errcode"而非"error.code"。为此，协议引擎设计为可插拔式。核心类JsonProtocolHandler提供两个钩子函数：

class JsonProtocolHandler { public: virtual QJsonObject parseResponse(const QByteArray& raw) override { // 默认实现：按JSON-RPC 2.0解析 auto doc = QJsonDocument::fromJson(raw); if (!doc.isObject()) return {}; auto obj = doc.object(); // 检查必要字段... return obj; } virtual QByteArray serializeRequest(const QJsonObject& req) override { // 默认实现：生成{"jsonrpc":"2.0","method":"get_info","params":[],"id":1} return QJsonDocument(req).toJson(); } };

当遇到非标设备时，只需新建一个类继承它，重写这两个函数。例如某储能PCS厂商的协议要求：请求必须是GET URL，参数拼在query string里，响应是纯JSON数组。那么serializeRequest()就变成：

QByteArray MyCustomHandler::serializeRequest(const QJsonObject& req) { QUrl url("http://192.168.1.100/api"); QUrlQuery query; query.addQueryItem("cmd", req["method"].toString()); query.addQueryItem("params", QJsonDocument(req["params"].toArray()).toJson(QJsonDocument::Compact)); url.setQuery(query); return url.toString().toUtf8(); // 返回URL字符串，由网络模块发起GET }

这种设计让Solar Debugger具备极强的适应性。我在帮一家逆变器厂调试时，他们用了三种不同协议：老产线用Modbus TCP（需转换为JSON），新产线用JSON-RPC，出口版用MQTT+JSON。只需写三个Handler插件，编译成.so/.dll，扔进plugins目录，重启即可识别——完全不用改主程序代码。

3.3 JSON编辑与结构化视图：所见即所得的调试体验

编辑区不是简单的QTextEdit，而是基于QPlainTextEdit定制的JsonEditor。它实现了三个关键能力：语法高亮、实时校验、智能补全。语法高亮用正则表达式匹配（"string"、[0-9]+、true|false|null），但难点在嵌套引号处理——比如{"name":"O'Reilly"}中的单引号不能打断字符串匹配。解决方案是：用状态机扫描，遇到"进入字符串态，遇到\"跳过，再次遇到"退出。实时校验更关键：用户每敲一个字符，后台线程立即用nlohmann::json::parse()尝试解析，若失败，将错误位置（行/列）标记在行号栏旁，鼠标悬停显示错误信息（如“expecting value at line 5 column 12”）。这比等用户点“发送”才报错，效率提升十倍。

结构化视图（JSON Tree）的难点是性能。一个BMS设备返回的JSON可能有2000+字段，全展开会卡死。Solar Debugger采用“懒加载”策略：初始只展开一级键（"system"、"battery"、"inverter"），点击>图标时，才递归解析该节点下的子对象。技术实现上，用QStandardItemModel，每个节点存储一个nlohmann::json引用（非拷贝），展开时调用json::dump(2)生成子节点文本，再解析为新item。为防用户误操作（如双击展开所有节点），添加了深度限制：默认最多展开5层，可在设置中调至10层。最实用的功能是“路径复制”：右键任意字段（如battery.cells[0].voltage），选择“Copy Path”，粘贴到代码里就是标准的JSON Pointer（/battery/cells/0/voltage），方便C++代码用json.at("/battery/cells/0/voltage").get<double>()直接取值。

3.4 Schema验证与自动生成：让JSON从“能用”到“可靠”

JSON Schema是保证通信健壮性的最后一道防线。Solar Debugger内置Schema编辑器，支持导入.schema.json文件，并在发送请求前自动验证。但更聪明的是“反向生成”功能：选中一段JSON响应，点击“Generate Schema”，程序会分析每个字段的类型、取值范围、是否必填，生成符合Draft-07标准的Schema。例如，对{"soc":85,"temperature":25.3,"status":"charging"}，生成的Schema片段为：

{ "soc": { "type": "integer", "minimum": 0, "maximum": 100 }, "temperature": { "type": "number", "multipleOf": 0.1 }, "status": { "type": "string", "enum": ["idle", "charging", "discharging"] } }

这个功能的价值在于：当设备固件升级，新增了"fault_code"字段，旧版Schema没定义，Solar Debugger会高亮提示“unknown field: fault_code”，提醒你更新Schema。而手动写Schema极易遗漏，尤其当JSON结构复杂时。实测表明，用反向生成+人工微调，Schema编写效率提升70%，且覆盖率接近100%。Schema验证不是摆设——当用户编辑JSON时，若输入"soc":150，编辑区会红色波浪线下划线，并在状态栏提示“soc must be <= 100”，阻止错误请求发出。这比设备返回{"error":"invalid soc"}后再排查，节省至少3分钟/次。

4. 实操全流程：从零开始调试一台光伏逆变器的完整记录

4.1 环境准备：Qt6安装与项目构建（避坑指南）

Qt6安装是第一个门槛。官网下载的在线安装器常因网络问题卡在“Installing Qt Creator”阶段。我的经验是：直接下载离线包（Qt6.5.3_for_Windows_64-bit_offline.exe），安装时取消勾选“Qt Creator”，只选“MinGW 11.2.0 64-bit”和“Qt6.5.3”组件。为什么选MinGW而非MSVC？因为MSVC要求VS2019，而客户现场电脑往往只有VS2015或根本没有VS——MinGW生成的exe自带运行库，零依赖。安装后，设置环境变量QTDIR指向C:\Qt\6.5.3\mingw_64，并在PATH中加入%QTDIR%\bin。

构建项目时，CMakeLists.txt的关键配置如下：

# 强制静态链接，避免DLL依赖 set(CMAKE_FIND_LIBRARY_SUFFIXES ".lib;.a" ${CMAKE_FIND_LIBRARY_SUFFIXES}) set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static-libgcc -static-libstdc++") find_package(Qt6 REQUIRED COMPONENTS Core Widgets Quick SerialPort) # 链接nlohmann::json（头文件-only库） add_subdirectory(third_party/nlohmann_json) target_link_libraries(solar_debugger PRIVATE Qt6::Core Qt6::Widgets Qt6::Quick Qt6::SerialPort nlohmann_json::nlohmann_json)

最大坑点：Qt6的SerialPort模块在MinGW下默认不启用。需在CMakeLists.txt中添加：

# 启用MinGW的SerialPort支持 if(WIN32 AND CMAKE_CXX_COMPILER_ID MATCHES "GNU") add_definitions(-DQT_NO_PRINTER) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DQT_NO_DEBUG_OUTPUT") endif()

否则编译会报错undefined reference to 'QSerialPort::QSerialPort(QObject*)'。这个错误网上搜不到答案，是Qt6.5.3 MinGW版本的已知bug，官方论坛里埋得很深。

4.2 连接逆变器：从物理接线到协议握手

以华为SUN2000-50KTL-C1逆变器为例，调试流程如下：

物理连接：用USB转RS485线（CH340芯片），DB9公头接逆变器的RS485端子（A/B），USB插电脑。注意：RS485需终端电阻，逆变器端子旁有拨码开关，将“TERMINATION”拨至ON。
软件配置：打开Solar Debugger，设备栏选“Serial Port”，点击“Scan”自动列出COM3（我的电脑上是COM3）。点击“Settings”，设波特率9600、数据位8、停止位1、无校验。关键一步：勾选“RTS/CTS Flow Control”——华为逆变器要求硬件流控，否则发指令后无响应。
协议选择：在协议下拉框选“Huawei Modbus JSON Bridge”。这是个自定义插件，作用是把JSON请求转换为Modbus RTU帧，再把Modbus响应解析为JSON。例如，发送{"method":"get_device_info","params":[]}，插件内部会生成Modbus帧01 03 00 00 00 0A CRC，发给逆变器；收到响应01 03 14 00 01 00 02 ...后，解析为{"device_id":"SUN2000-50KTL-C1","firmware":"V10.12.01"}。
首次握手：点击“Connect”，状态栏显示“Connected”。此时逆变器LED应由红变绿。若失败，检查：① COM端口号是否正确（设备管理器里确认）；② 流控是否开启；③ 终端电阻是否接好。曾有个案例，客户说“连不上”，最后发现RS485线A/B接反了——Solar Debugger的串口日志会显示“Received 0 bytes”，这是典型接反特征。

4.3 调试实战：修改MPPT电压阈值并验证效果

目标：将MPPT工作电压下限从600V改为550V，验证逆变器是否响应。

获取当前参数：在JSON编辑区输入：
```
{"method":"get_mppt_config","params":[]}
```
点击“Send”，右侧结构化视图展开，找到"voltage_min":600。
构造修改请求：右键voltage_min节点，选“Edit Value”，输入550。此时编辑区自动更新为：
```
{"method":"set_mppt_config","params":[{"voltage_min":550}]}
```
发送并观察：点击“Send”，状态栏显示“Sent 78 bytes, Received 42 bytes”。右侧视图刷新，voltage_min变为550，且新增"success":true字段。
验证效果：断开连接，用万用表测MPPT输入端电压，人为降至540V（模拟阴天低压），重新连接，发get_mppt_status请求，返回"state":"tracking"，证明新阈值生效。

整个过程耗时22秒。对比传统方式：用厂商专用软件，需安装300MB客户端，登录账号，找“高级设置”菜单，输入密码，修改后重启逆变器——至少5分钟。

4.4 故障排查：JSON解析失败的三大高频场景

在真实项目中，JSON解析失败占调试问题的65%。Solar Debugger的日志面板（Ctrl+L）会详细记录每帧原始数据，以下是三个最常见场景及对策：

场景	原始数据示例	Solar Debugger诊断	解决方案
BOM头干扰	`EF BB BF 7B 22 6A 73...`（UTF-8 BOM）	日志显示“Invalid UTF-8 start byte”	在`JsonProtocolHandler::parseResponse()`开头添加`raw.remove(0, 3)`移除BOM
分包粘连	`{"id":1,"result":123}{"id":2,"result":456}`（两帧粘在一起）	解析第一帧成功，第二帧报错“Unexpected character”	启用“Auto-split JSON frames”选项，用`QByteArray::split('}')`分割，每段末尾补`}`
非JSON响应	`OK\r\n`（AT指令返回）或`ERROR 0x12`（自定义错误码）	编辑区显示“Not a valid JSON object”	在协议插件中，先用正则`^OK$

特别提醒：某次现场调试，逆变器在固件升级后，返回的JSON多了个不可见字符（U+200B 零宽空格），肉眼无法识别，但导致nlohmann::json解析失败。Solar Debugger的日志面板用十六进制视图（右键切换）立刻暴露了E2 80 8B字节，删掉后恢复正常。这个功能，救了我三次。

5. 扩展性实践：如何为新设备快速添加协议支持

5.1 插件开发标准流程：30分钟完成一个CAN设备支持

假设要支持一款新CAN设备（某品牌汇流箱），其协议文档规定：发送CAN帧ID=0x100，数据域为JSON字符串（ASCII编码）；响应ID=0x200，数据域为JSON响应。开发步骤如下：

创建插件项目：在src/plugins/can_huiliu目录下，新建can_huiliu.h/cpp。继承DeviceInterface和JsonProtocolHandler。
实现设备连接：open()函数中，调用socket(PF_CAN, SOCK_RAW, CAN_RAW)创建CAN socket，bind()绑定can0，设置struct can_filter只收ID=0x200的帧。
重写协议解析：serializeRequest()将JSON对象转为QByteArray，用QString::toLatin1()编码（确保ASCII），填充到CAN帧can_frame.data，长度设为qMin(json.length(), 8)（CAN标准帧最多8字节）。

编译为动态库：CMakeLists.txt中添加：

add_library(can_huiliu SHARED can_huiliu.cpp) target_link_libraries(can_huiliu PRIVATE Qt6::Core Qt6::SerialPort) set_target_properties(can_huiliu PROPERTIES PREFIX "" SUFFIX ".dll") # Windows

部署：生成can_huiliu.dll，放入Solar Debugger同目录的plugins文件夹。重启软件，设备栏自动出现“CAN Huiliu Box”选项。

全程代码量约200行，核心逻辑集中在serializeRequest()和parseResponse()两个函数。我用此流程为5家客户设备开发了插件，平均耗时22分钟/个。关键心得：不要试图在插件里处理所有异常，而是让主程序捕获std::exception，统一弹窗提示“Plugin error: xxx”，避免插件崩溃导致主程序退出。

5.2 UI定制化：用QML覆盖默认界面

QML的灵活性体现在UI定制上。某客户要求界面必须符合公司VI：主色调蓝白，按钮圆角12px，禁用右键菜单。只需修改resources/qml/Main.qml：

ApplicationWindow { color: "#FFFFFF" header: Rectangle { color: "#0066CC" } // 顶部栏蓝色 Button { background: Rectangle { radius: 12 } // 圆角按钮 onClicked: { /* 原逻辑 */ } } // 禁用右键：在MouseArea中添加 MouseArea { anchors.fill: parent acceptedButtons: Qt.LeftButton onClicked: { /* 处理左键 */ } } }

保存后，Solar Debugger自动热重载（QML Live Reload），无需重启。这种即时反馈，让UI调整从“改代码-编译-运行”变成“改QML-保存-看效果”，迭代速度提升5倍。

5.3 性能优化实录：从100ms到8ms的JSON解析提速

初始版本用QJsonDocument::fromJson()解析JSON，实测1MB JSON耗时100ms。优化步骤：

换库：改用nlohmann::json，同样数据耗时45ms（因其SIMD加速）。
预分配：解析前，用json.reserve(100000)预估容量，避免内存频繁重分配。
零拷贝：QByteArray转std::string_view，传给nlohmann::json::parse()，避免toStdString()的拷贝开销。
线程绑定：将解析任务放到QThreadPool的专用线程（QRunnable），设置setPriority(QThread::HighPriority)。

最终耗时8ms，提升12.5倍。这个优化让Solar Debugger能实时处理10Mbps的JSON流（如视频分析设备的元数据），而不仅是调试工具。

6. 注意事项与实操心得：那些文档里不会写的细节

提示：以下全是血泪教训，不是理论推导。

Qt6的QSerialPort在Windows下有100ms隐式延迟：即使设setReadBufferSize(1)，readAll()仍可能返回空。解决方案：在readyRead()信号槽中，用QTimer::singleShot(0, this, &MyClass::doRead)延迟执行读取，或直接用waitForReadyRead(1)强制等待。
JSON数组索引越界不报错：nlohmann::json对array[100]返回null而非抛异常，导致后续.get<int>()返回0，掩盖真实错误。务必在取值前用array.size()>100检查。
QML ListView的内存泄漏：当JSON树节点过多（>1000），model->setData()可能引发内存暴涨。修复方法：在QStandardItemModel的setData()重写中，添加if (role == Qt::DisplayRole) { item->setText(value.toString()); }，避免无谓的QVariant拷贝。
USB设备热插拔识别：Windows下USB设备插拔，Qt的QSerialPortInfo::availablePorts()不会自动更新。需监听Windows消息WM_DEVICECHANGE，用QSystemTrayIcon的messageClicked()间接触发扫描。
Qt6静态链接的陷阱：-static-libgcc会导致std::regex失效（GCC bug）。若代码用正则，必须改用QRegularExpression，或放弃静态链接，改用windeployqt --no-translations --no-system-d3d-compiler --no-opengl-sw部署。

最后分享一个技巧：Solar Debugger的配置文件config.json是明文，你可以用任何文本编辑器修改。比如把"auto_connect": true改成false，下次启动就不会自动连设备；把"log_level": "info"改成"debug"，日志面板会显示每一帧的十六进制原始数据。这个设计让高级用户能绕过GUI，直接用脚本批量修改配置——这才是真正“可扩展”的底气。