简介：面向Qt上位机与三菱FX3U PLC编程口通信学习的示例工程，适合工业自动化方向的上位机开发者、PLC初学者及需要理解串行通信流程的工程人员参考。压缩包共7个文件，约12KB，以cpp、h源码为主，另有ui界面与pro工程配置，便于导入Qt Creator查看工程组织。已有1004人学习下载，说明其在PLC编程口通信入门场景中具有一定参考价值。源码围绕QSerialPort串口参数配置、数据收发及readyRead信号处理展开，并涉及FX系列FINS指令解析、通信失败重试与数据包格式设计等环节。读者可借此梳理Qt与FX3U PLC建立连接、发送读写请求、处理返回数据的完整思路，理解串口通信协议分层与异常处理方式，为开发远程监控、程序下载或数据采集类上位机应用打下基础。
1. 现场只有一只编程口：这台 FX 到底在跑什么数
电柜里那台 FX 系列 PLC，编程口被触摸屏占着，想插上去看一眼 D100 到底存了什么、M20 有没有置位，得先把屏的线拔了。手里只有通用串口助手，它不会替你拼软元件地址，不会算累加和校验，回上来一串十六进制还得自己一位一位数——这种时候最想要的是一个“知道 FX 编程口长什么样”的工具。FX_serial_asst 就是干这个的：Qt 写的编程口调试助手，选好串口，填软元件地址，读 D/M/X/Y/T/C、写单点、连续地址批量轮询、原始报文十六进制上屏。适合三类人：现场维护要临时查值的、上位机刚入门想搞懂这套帧格式的、准备自己写采集网关拿它当参照系的。后面按“它由什么组成 → 一帧怎么拼 → 收发怎么跑 → 哪里会翻车 → 怎么改成自己的东西”的顺序拆，边看边能对着代码改。
2. 技术选型与目录结构：Qt + QSerialPort 撑起的调试器骨架
2.1 目录结构与模块分层
这类小工具最容易写成一个大 MainWindow 文件几千行，改一处牵全身。这个项目的目录分得比较克制，四层：界面、协议、传输、数据模型，互不越界。传输层不知道 FX 协议长什么样，只负责“把一串字节发出去、把回来的字节攒齐”；协议层只管拼帧解帧，碰不到 QSerialPort；界面层连字节都不碰，只认结构体。
FX_serial_asst/ ├── FX_serial_asst.pro # qmake 工程，也能用 CMakeLists 等价替换 ├── main.cpp # 组装：UI 线程 + 串口线程 ├── ui/ │ ├── mainwindow.h/.cpp # 主窗口，串口配置、寄存器表、日志区 │ └── mainwindow.ui ├── protocol/ │ ├── fxprotocol.h/.cpp # 组帧、校验、解帧、软元件地址换算 │ └── fxdevice.h # 软元件描述表（位/字、进制） ├── transport/ │ ├── serialworker.h/.cpp # 住在子线程，负责 open/write/read/超时 │ └── requestqueue.h # 请求排队，一帧一发 ├── model/ │ └── registertable.h/.cpp # 地址-值-类型，供 QTableWidget 取数 └── log/ └── framelog.h/.cpp # 报文日志，带时间戳和方向标记值得说的是model这一层单独抽出来的理由。寄存器表既被轮询模块写、又被表格控件读，还可能是将来导出 CSV 的数据源，放在窗口类里以后想做后台采集就得复制一遍。抽出来之后，改成无界面的采集进程，只要把ui/整个删掉，protocol + transport + model照样编译。这个切分是我在类似项目里被返工逼出来的习惯——先想清楚“哪部分将来要脱离界面活着”，再决定文件怎么放。
2.2 Qt 侧技术栈与线程模型
选 Qt 不是为了跨平台，主要是三件事：QSerialPort 把 Windows 和 Linux 的串口差异抹平了；QTableWidget 拿来就是寄存器监视表，省掉自己画；windeployqt 打包完拷到现场电脑上双击就能跑，不用装运行时。这对设备调试场景很重要，你不能要求产线那台 Win7 一体机装一堆东西。
| 层面 | 选型 | 说明 |
|---|---|---|
| 语言/标准 | C++11 | 够用，现场老编译器也能过 |
| 框架 | Qt 5.15 / Qt 6.x | QSerialPort 在 Qt6 里是独立模块，.pro 要加 serialport |
| 串口 | QSerialPort + QSerialPortInfo | 枚举端口、事件驱动收数 |
| 并发 | QThread + moveToThread | 串口对象只在子线程里创建和销毁 |
| 定时 | QTimer（子线程内） | 轮询周期、超时重发 |
| 配置 | QSettings | 串口参数、上次的地址列表 |
线程模型是最容易做错的地方。新手常见写法是把QSerialPort在主线程 new 出来，然后waitForReadyRead()死等，界面直接白掉。这里的做法是 worker 对象moveToThread，串口所有操作都在子线程的槽函数里发生，主线程只发信号。
// main.cpp：串口对象在子线程里生、在子线程里死 QThread *serialThread = new QThread(this); SerialWorker *worker = new SerialWorker; // 构造函数里不 new QSerialPort worker->moveToThread(serialThread); // 跨线程传自定义结构体必须先注册，否则信号槽排队时会静默丢包 qRegisterMetaType<Request>("Request"); qRegisterMetaType<QByteArray>("QByteArray"); connect(serialThread, &QThread::finished, worker, &QObject::deleteLater); connect(this, &MainWindow::openPortRequested, worker, &SerialWorker::openPort); connect(worker, &SerialWorker::frameReady, this, &MainWindow::onFrameReady); serialThread->start();要点在moveToThread之前不能给 worker 传任何带父对象的指针，QSerialPort必须在openPort()这个槽里才new，父子关系挂在 worker 上。qRegisterMetaType那两行如果漏了，编译期毫无提示，运行期信号发出去对方收不到，查起来能耗掉一下午——这是 Qt 跨线程最经典的隐蔽问题。另外deleteLater要接在QThread::finished上，窗口关闭时先quit()再wait()，顺序反了会崩在退出那一刻。
2.3 串口参数为什么是 9600-7-E-1
编程口这套协议帧里全是 ASCII 字符（STX、命令字、地址、数值、校验都是可打印字符加两个控制字符），最高位永远是 0，所以 7 位数据位足够，多出来那一位拿去做偶校验，抗现场干扰。常见配置就是 9600 波特、7 数据位、偶校验、1 停止位。有些 USB 转 422 的转换器芯片根本不支持 7 位数据位，设了也按 8 位发，这时候退成 9600-8-E-1 通常也能通，因为第 8 位是 0；但反过来，如果 PLC 侧配的是 8 位、你按 7 位发，收到的字符最高位会被截掉，症状是偶发校验错而不是全错，很难判断。
bool SerialWorker::openPort(const QString &name, int baud, int dataBits, int parity) { if (m_port) { m_port->close(); delete m_port; m_port = nullptr; } m_port = new QSerialPort(this); m_port->setPortName(name); m_port->setBaudRate(baud); // 9600 m_port->setDataBits(static_cast<QSerialPort::DataBits>(dataBits)); // 7 或 8 m_port->setParity(static_cast<QSerialPort::Parity>(parity)); // Even m_port->setStopBits(QSerialPort::OneStop); m_port->setFlowControl(QSerialPort::NoFlowControl); // 422 不需要软硬流控 m_port->setReadBufferSize(4096); if (!m_port->open(QIODevice::ReadWrite)) { emit portError(m_port->errorString()); // 被占用、驱动没装都走这里 return false; } connect(m_port, &QSerialPort::readyRead, this, &SerialWorker::onReadyRead); return true; }setFlowControl(NoFlowControl)这一行别省，某些转换器默认协商 RTS/CTS，PLC 侧不接这两根线，结果就是发得出去收不回来。open()失败最常见的原因不是参数错，而是端口被别的软件占着（触摸屏组态软件、另一个串口助手），errorString()里会写 PermissionError 或“设备忙”，看到这个先查占用，别急着重装驱动。至于物理层，编程口是 MD8 圆头、4 线差分（RXD+/RXD-/TXD+/TXD-/SG），普通 USB-TTL 的 232 电平接上去是收不到的，必须用 422 转换器，这一点在买线之前就得确认清楚。
3. 协议层拆解：一帧 FX 编程口报文从拼装到校验的完整链路
3.1 帧结构：六个字段决定成败
把一帧拆开看，无非是帧头、命令字、软元件地址、点数、帧尾、校验六段。真正的难点不在结构，在每段的表示方式：地址是 ASCII 字符串不是二进制，点数是两位字符，校验是“算出来的一个字节再转成两位十六进制字符”。新手最容易在这上面犯迷糊，明明算出 0x66，却把 0x66 这一个字节塞进帧里，PLC 那边等的是字符'6' '6'两个字节，长度对不上直接被丢。
| 字段 | 长度 | 内容 | 说明 |
|---|---|---|---|
| STX | 1 字节 | 0x02 | 帧起始 |
| 命令字 | 1 字符 | '0' 读 / '1' 写 | ASCII |
| 软元件地址 | 4 字符 | 如D100、X010 | 字母 + 数字，X/Y 用八进制 |
| 点数 | 2 字符 | 如01、08 | 十进制字符，一帧别超 8 点 |
| 数据区 | 写命令才有 | 每点 4 字符 | 16 位值的十六进制 ASCII |
| ETX | 1 字节 | 0x03 | 帧结束 |
| 校验 | 2 字符 | 累加和低 8 位 | 命令字到 ETX 之前逐字节累加 |
举个能对上号的例子：读 D100 起 1 点，帧体是0D10001，逐字节 ASCII 相加 48+68+49+48+48+48+49 = 358，取低字节 0x66，转成字符66。整帧发出去就是02 30 44 31 30 30 30 31 03 36 36。各家实现里命令字后面有时还跟一位固定字符或站号，字段顺序也会有小出入，所以改协议层的时候，对着抓包改常量比对着文档猜快得多——文档版本和固件版本经常对不上。
3.2 组帧与校验：两个函数撑起协议层
协议层的接口设计成“进去是结构体，出来是 QByteArray”，这样界面层完全不用知道字符编码的事。读和写走同一个入口，靠Request::isWrite分流，减少调用方判断。
// 累加和：对 body（命令字到 ETX 之前）逐字节相加，取低 8 位，转两位大写十六进制 ASCII QByteArray FxProtocol::calcSum(const QByteArray &body) { quint8 sum = 0; for (char c : body) sum += static_cast<quint8>(c); return QByteArray::number(sum, 16).rightJustified(2, '0').toUpper().toLatin1(); } QByteArray FxProtocol::buildFrame(const Request &req) { QByteArray body; body.append(req.isWrite ? '1' : '0'); // 命令字 body.append(deviceAddress(req.device, req.addr)); // 软元件地址，X/Y 走八进制 body.append(QByteArray::number(req.count).rightJustified(2, '0')); // 点数 if (req.isWrite) { for (quint16 v : req.values) // 每点 4 字符，不足补 0 body.append(QByteArray::number(v, 16).rightJustified(4, '0').toUpper()); } QByteArray frame; frame.append(char(0x02)); frame.append(body); frame.append(char(0x03)); frame.append(calcSum(body)); // 校验不含 STX 和 ETX return frame; }rightJustified(4, '0')这两个参数都是有讲究的：不补零，值 5 会变成5一个字符，PLC 按 4 字符切数据区，后面的全错位；用toUpper()是因为有的固件只认大写十六进制。calcSum里QByteArray::number(sum, 16)返回的是小写，同样要转大写，否则偶发校验失败——我第一次写这段时就漏了，现象是十个字节里错一两个，特别像干扰，其实是自己算的校验和 PLC 算的不一样。
3.3 解帧与响应判定
响应帧的骨架跟请求帧一样，STX 开头、ETX 结尾、两位校验。区别在帧体：读命令回来的是数据区，写命令回来的是确认字符。正常响应首字符是'0'，非'0'就是错误码，需要查表翻译成人话（地址越界、命令不支持、PLC 忙之类）。位软元件和字软元件的解析分支必须分开：字软元件每点 4 个字符组成一个 16 位值，位软元件按点回 1 个字符。如果抓包发现位数据是打包成字节返回的，就说明这批固件的约定不一样，把parseBits分支改掉即可，别去动组帧逻辑。
bool FxProtocol::parseResponse(const QByteArray &body, QVector<quint16> &out, QString &err) { if (body.isEmpty()) { err = "空响应"; return false; } if (body.at(0) != '0') { // '0' 正常，其余是错误码 err = QString("PLC 返回错误码: %1").arg(body.at(0)); return false; } const QByteArray data = body.mid(1); // 去掉状态字符 if (m_isBitDevice) { for (char c : data) out.append(c == '1' ? 1 : 0); } else { for (int i = 0; i + 4 <= data.size(); i += 4) out.append(data.mid(i, 4).toUShort(nullptr, 16)); } return out.size() == m_expectCount; // 数量对不上也算失败，交给上层重试 }最后那个数量校验是我后来加的。早期只判return true，结果某次线接触不良，回来半帧数据，表格里后面几行显示 0，现场以为寄存器真被清零了，白排查两小时。数量对不上就当失败丢给重试逻辑，比展示一个假值安全得多。
3.4 软元件地址换算：X/Y 是八进制
这一条必须单独拎出来说。D、M、T、C、S 的编号都是十进制，你怎么填就怎么发；但 X 和 Y 是八进制编号，PLC 面板上写着 X10，指的是第 8 个输入点，不是第 10 个。地址换算写错，读回来的值就整体错位，而错位后的值往往还是个合法数值，肉眼根本看不出来。
// X/Y 输入输出继电器按八进制编号，其余按十进制 QByteArray FxProtocol::deviceAddress(const QString &dev, quint16 logicalAddr) { const bool octal = (dev == "X" || dev == "Y"); const int radix = octal ? 8 : 10; return (dev + QString::number(logicalAddr, radix).rightJustified(3, '0')).toLatin1(); }界面上用户填的是“第几个点”这种逻辑序号（比如第 9 个输入点填 9），协议层负责转成X011。这样填表和换算分开，改起来不容易乱。反过来，如果界面直接让用户填X011这种物理地址，那就别再做一次换算，两种约定只能选一种，混用是错位问题的根源。
4. 核心模块实战：收发线程、请求队列与批量轮询怎么配合
4.1 收数：缓冲区切帧而不是一次读完
串口是流式的，一次readyRead可能给你半帧，也可能给你一帧半加一堆噪声。所以收数必须用缓冲区 + 循环切帧的方式，不能假设“读一次就是一帧”。切帧的锚点就是 STX 和 ETX，中间那段是帧体，ETX 后面两个字符是校验。
void SerialWorker::onReadyRead() { m_buf.append(m_port->readAll()); while (true) { const int stx = m_buf.indexOf(char(0x02)); if (stx < 0) { m_buf.clear(); return; } // 没有帧头，全是噪声 if (stx > 0) m_buf.remove(0, stx); // 丢掉帧头之前的脏数据 const int etx = m_buf.indexOf(char(0x03)); if (etx < 0) return; // 帧体没完，等下次 readyRead if (m_buf.size() < etx + 3) return; // 校验两字符还没到齐 const QByteArray body = m_buf.mid(1, etx - 1); const QByteArray sum = m_buf.mid(etx + 1, 2); m_buf.remove(0, etx + 3); // 出队，处理下一帧 if (FxProtocol::calcSum(body) != sum) { emit frameError(body, sum); continue; } emit frameReady(body); } }mid(1, etx - 1)这个参数：从索引 1（跳过 STX）开始，长度是etx - 1，正好是 STX 到 ETX 之间的字节数。m_buf.size() < etx + 3判断的是校验两位是否到齐，少一位就去解析会拿到半个校验值，然后误报校验错。缓冲区要设上限（比如 8KB），超了就清空重来，否则现场干扰大时会一直涨。
4.2 请求队列：一次只发一帧
编程口是串行应答的，你连发两帧，回来的数据黏在一起，切帧时第二帧的 STX 可能被当成数据的一部分。稳妥做法是请求排队，发一帧、等响应或超时、再发下一帧。写操作和读操作进同一个队列，保证写不会被轮询插队打断。
void SerialWorker::execNext() { if (m_busy || m_queue.isEmpty()) return; const Request req = m_queue.dequeue(); m_pending = req; m_busy = true; m_retry = 0; m_port->write(FxProtocol::buildFrame(req)); m_timeout->start(req.timeoutMs); // 常见 300~500ms，点位多适当放宽 } void SerialWorker::onTimeout() { if (++m_retry > kMaxRetry) { // 3 次不过就放弃，别死磕 m_busy = false; emit requestFailed(m_pending, "响应超时"); execNext(); return; } m_port->write(FxProtocol::buildFrame(m_pending)); // 重发同一帧 m_timeout->start(m_pending.timeoutMs); }超时值不是拍脑袋定的：一帧 8 个点的读，9600 波特下大约 20~30ms，加上 PLC 扫描周期，300ms 已经非常宽松。给太短会误判超时，给太长会让界面点一下要等一秒才有反应。重试三次是我的习惯值，因为连续三次不通基本就是线或者参数问题，再重试只是拖时间。
4.3 批量合并：把 8 次通信压成 1 次
轮询一张 32 个 D 寄存器的表，如果每个地址单独发一帧，一轮就是 32 次往返，按每次 30ms 算接近 1 秒，界面刷新肉眼可见地卡。做法是把地址排序后合并成连续区间，一帧读一段。连续区间内多读几个点比多跑几次通信划算得多。
// 输入乱序地址集合，输出合并后的 [起始, 点数] 区间，单帧点数上限 kMaxPerFrame QVector<QPair<quint16, quint16>> mergeRanges(QVector<quint16> addrs, int maxPerFrame = 8) { std::sort(addrs.begin(), addrs.end()); QVector<QPair<quint16, quint16>> out; int i = 0; while (i < addrs.size()) { int j = i; while (j + 1 < addrs.size() && addrs[j + 1] == addrs[j] + 1 && (j + 1 - i + 1) <= maxPerFrame) ++j; out.append({addrs[i], static_cast<quint16>(j - i + 1)}); i = j + 1; } return out; }maxPerFrame取 8 是个折中：帧越长，单帧出错重发的代价越大，而且部分型号对单帧点数有上限。合并之后要注意回填顺序——返回的数据是按起始地址顺序排的，得按原来的地址映射写回寄存器表，不能按用户填表顺序。QTimer 的轮询周期一般设 300~500ms，别低于 200ms，否则队列会堆积，界面上看到的是“越刷越慢”。
5. 联调避坑：编程口通信里最容易翻车的五个现场问题
5.1 串口打开成功，一个字节都收不到
现象：open()返回 true，write()也没报错，但readyRead永远不触发，日志区干干净净。
原因：物理链路问题占了九成。编程口是 4 线差分，很多人拿 USB-TTL 或者 232 转换器直接怼上去，电平不匹配根本收不到；也有人只接了 RXD 两根线，指望两线半双工能通，实际这套是全双工差分，接不全就是单向哑巴。还有一种是 MD8 圆头压线的时候引脚顺序记反了，TXD+ 接到 RXD+，看着整齐，实际收发对不上。
解决：先用回环自测转换器本身——把转换器的 TXD+ 和 RXD+ 短接、TXD- 和 RXD- 短接，发什么应该原样回什么，这一步过不了就别怀疑 PLC。回环通了再查线序，用万用表量通断比肉眼数针脚可靠。接好之后第一件事是发一帧最简单的读命令，把原始报文打到日志里，看到 0x02 0x03 才能谈后面的解析。
5.2 能收到数据但校验一直错
现象：缓冲区里有东西，切出来的帧体看着也像模像样，就是calcSum对不上，十次里错七八次。
原因：串口参数不匹配。7 位数据位配成 8 位、偶校验配成无校验、波特率偏差，都会让字符在传输中被改掉某一位。另外还有一个隐蔽的：某些转换器不支持 7 位数据位，你设 7 位它按 8 位发，帧头帧尾都对，中间的数字字符偶尔错——这种情况最像“干扰”，其实是参数问题。
解决：按 9600-8-E-1、9600-7-E-1、9600-8-N-1 的顺序挨个试，每次试完看重发的成功率，别只看一帧。全都不行再怀疑线长和接地，差分线超过几十米又没屏蔽，误码率会明显上去。校验错的时候一定要把原始字节和算出来的校验都打到日志里，只打印“校验失败”四个字等于什么都没说。
5.3 X/Y 读出来的位置整体错位
现象：读 X0 到 X17 这一段，值能读到，但跟实际输入指示灯对不上，感觉整体平移了几位。
原因：X 和 Y 按八进制编号，逻辑序号第 9 个点对应的是 X11，不是 X9。如果代码里直接用十进制转换，第 8 个点之后全部错位。更麻烦的是错位后读到的仍然是合法的 0/1，界面上完全看不出异常。
解决：地址换算在协议层统一做，界面只填逻辑序号，转换函数里对 X/Y 用radix = 8。验证方法是找一个确定的输入点——手动按下接在 X10 上的按钮，看表格里第 8 行（逻辑序号 8）有没有变 1，变了说明换算对了。
5.4 连续写多个寄存器，只有第一个生效
现象：一次写 8 个 D 寄存器，PLC 里只有起始那个变了，其余保持原值，也不报错。
原因：写命令的数据区长度和点数不匹配。每点固定 4 个字符，8 点就是 32 个字符，少写一个字符整帧就废了，PLC 会按自己的解析规则截断。另一种可能是单帧点数超过了型号允许的上限，超出的部分被静默丢弃。
解决：组帧时用循环拼数据区，不要手写；发之前把帧长度打出来，跟“6 + 4×点数 + 3”算一遍对一下。点数超过 8 就拆成多帧，帧之间留 20ms 间隔，别连着灌。写操作做完一定要回读一次确认，只信写命令的应答是不够的。
5.5 界面点几下就卡住，像死机
现象：开始轮询后界面失去响应，鼠标变成转圈，过几秒又活过来，反复发作。
原因：串口读写跑在主线程，waitForReadyRead或者同步等待响应把事件循环堵死了。另一种是轮询周期设得太短，队列越堆越长，主线程一直在处理回来的信号，画表格都排不上队。
解决：串口对象整体搬到子线程，主线程只接信号更新表格；轮询周期不低于 300ms；队列长度设个上限，超了丢最旧的请求而不是无限增长。表格更新也别每帧刷一次，攒 200ms 批量刷一次，肉眼完全看不出差别，CPU 占用能降一大截。
6. 二次开发：把寄存器表改成你自己的采集器
想把它从“调试助手”变成“采集器”，改动其实集中在三个点：软元件描述表、数据出口、运行方式。
软元件描述表现在是写死在fxdevice.h里的几个分支，改成配置驱动会好用很多，加新软元件不用改代码。我一般这么写：
struct DeviceDesc { QString code; bool isBit; int radix; QString alias; }; // 配置里读出来，或者直接写死也行，关键是集中在一处 static const QVector<DeviceDesc> kDevices = { {"D", false, 10, "数据寄存器"}, {"M", true, 10, "内部继电器"}, {"X", true, 8, "输入继电器"}, // 注意八进制 {"Y", true, 8, "输出继电器"}, {"T", false, 10, "定时器当前值"}, {"C", false, 10, "计数器当前值"}, };有了这张表，isBit决定解析分支，radix决定地址换算，界面上的下拉框也能直接由它生成，加一个软元件只改一行。加完之后记得拿一个已知值的点位验证，别一次加五六个再一起试。
数据出口是最容易加的部分。registertable里加个只读快照接口，采集侧起一个QTimer每秒取一次，写进 SQLite 或者拼成 JSON 发出去，界面完全不用动。我习惯把快照做成值拷贝，而不是把内部容器指针往外给，省得后面多线程访问出问题。输出侧再加一层节流，值没变就不发，长时间跑下来数据量能小一个数量级。
| 改造点 | 涉及文件 | 大致工作量 |
|---|---|---|
| 增加软元件类型 | protocol/fxdevice.h | 十几行，配置化后更少 |
| 数据落库或上报 | model/registertable + 新建输出模块 | 半天，取决于目标格式 |
| 去掉界面做后台服务 | 删 ui/，改 main.cpp 组装方式 | 半天到一天 |
| 支持多站号轮询 | transport/requestqueue + 协议层 | 一天以上，要看现场拓扑 |
有个技巧值得单独说：调协议的时候别拿真 PLC 反复试，用虚拟串口对（一个写一个读的那种）做一个假的 PLC 应答端，行为固定、可注入错误（故意错一个校验位、故意延迟 5 秒、故意只回半帧），比在现场反复插拔线高效得多。这个假端我一般就写两百行，收到帧按配置回，跑通之后再接真设备，出问题能立刻分清是协议写错了还是现场环境的问题。
最后一句经验：早些年我调这类通信，总喜欢先做界面再调协议，结果界面改一次协议就得跟着调一次，来回折腾。从那以后我每次接新的现场总线，都先把原始报文打到日志里、用最小可运行代码把一帧跑通，再往上堆界面和功能。现在这个习惯让我省下的时间，比任何调试技巧都多。希望帮到你。
本文还有配套的精品资源，点击获取
