企业官网建设流程全解析

上位机开发日记 · 第 2 篇 · 架构先行：六层分层与边界

阅读时长：约 5 分钟 ·难度：入门 ·前置知识：第 1 篇（定位与三问选型）
本篇回答一个问题：代码该怎么分家。

1. 一个两个月后才会发作的病

项目启动时，你想着"就几个按钮，一个文件够了"：

# main_window.py —— 两周后 3000 行classMainWindow(QMainWindow):defon_start_clicked(self):self.ser=serial.Serial("COM3",115200)# 开串口frame=b"\xAA\x55"+cmd+crc# 拼帧self.ser.write(frame)# 发指令data=self.ser.read(1024)# 读数据values=struct.unpack("<10h",data[4:24])# 解包fori,vinenumerate(values):# 洗数据self.table.setItem(0,i,QTableWidgetItem(str(v*0.5)))self.curve.setData(ts,values)# 画图open("log.csv","a").write(",".join(...))# 存盘

一个月后，需求来了三个：换成网口、加个 CRC 校验、数据要存成二进制。你打开这个文件，发现任何一处修改都可能踩到别的功能——改通讯要动界面代码，改界面要重看协议细节。

这不是代码量的问题，是没有分层：一次点击，从物理层干到了表现层。

2. 六层结构

上位机的标准分工是这样的：

【判断】中间三层（协议、设备、数据）是"看不见的承重墙"。新手容易把注意力全花在最上面那层，但这三层才是决定项目能不能活到第二年的关键。

3. 每一层该做什么、不该做什么

关键理解："不该做什么"比"该做什么"更重要

以协议层为例。它解出一帧数据后，只知道"第 3 到第 5 字节是一个 16 位小端整数，物理量纲是 mV"，它不该知道这个值代表"驻波比"还是"增益"，更不该知道"超过 2.0 就要变红"。

因为一旦协议层知道了业务含义，换一个仪器型号时，你就要同时改协议层和业务层——耦合就是这样长出来的。

同理，设备抽象层的存在意义是：上层代码写的是dev.read()，不管是串口、TCP 还是 VISA 后端，上层一行都不用改。这是第 4、5 篇要重点打的底子。

4. 一条硬检验标准

分层做得好不好，不需要凭感觉。用这一条检验：

把 UI 层整个删掉，其他层能否照常跑通并跑出数据？

• 能→ 分层是对的。业务逻辑在正确的位置，界面只是"显示器"。
• 不能→ 说明业务逻辑漏进了界面层。这是最难还的债，趁早拆。

【判断】实操建议：写一个main_cli.py，不用任何图形界面，纯命令行跑通"连接 → 采集 → 存盘"全流程。它既是分层检验器，也是第 1 篇那个"设备模拟器"的雏形。

5. 三种常见的分层反模式

【判断】第三种最隐蔽。正确方向永远是单向的：数据从下往上流，指令从上往下流，绝不允许下层回头调用上层。

6. 分层带来的实际收益

第 5 篇那套解帧器代码，之所以能直接拿来用，就是因为它是纯函数式的协议层代码——喂字节进去，吐帧出来，不依赖任何界面和设备。

7. 本篇小结

8. 动手练习

给你的项目画一张分层草图，然后回答：

1. 你现在写的代码，分别落在哪一层？（如果有代码落不进任何一层，说明边界还没划清）
2. 你现在有没有"UI 层直接开串口"的地方？有的话标记出来，那是第一批要重构的目标。
3. 如果明天要把串口换成网口，你需要改几个文件？理想答案是一个都不改。

上一篇：[第 1 篇 · 上位机到底在解决什么问题]
下一篇：[第 3 篇 · 开发流程：六个阶段与验收标准]
——从"分层"到"分步"：先做什么、后做什么，每步怎么算做完。