RS485 通信实验是 STM32 系列教程中绕不开的一课。很多初学者在单片机上点个灯、跑个串口都挺顺利，但一旦接上 RS485 总线，就开始出现乱码、丢包、只能收不能发、多机通信互相干扰等问题。这些问题的根源往往不在代码，而在总线架构和硬件电路上。
这次我们直接把 RS485 总线搭建和优化讲透。文章会覆盖 RS485 总线架构、STM32 485 通信实验、自动收发电路设计、组网布线、终端电阻匹配、工业现场避坑指南，最后给出完整的 HAL 库代码示例和一套从回环测试到多机通信的验证流程。无论你是做毕业设计、准备电赛，还是在工业现场调试设备，这篇文章都值得先收藏再慢慢看。
1. RS485 核心能力速览
| 能力项 | 说明 |
|---|---|
| 总线标准 | RS-485，TIA/EIA-485 差分串行总线 |
| 通信方式 | 半双工差分传输，一主多从轮询 |
| 常用速率 | 9600bps、19200bps、115200bps 等，实际速率取决于线缆和距离 |
| 最大节点数 | 标准 32 个单元负载，采用高输入阻抗收发器可扩展至 128 或 256 个 |
| 最大通信距离 | 约 1200m（低速时），实际受线缆质量、速率和现场干扰影响 |
| 接口信号 | A、B 差分对，部分设备还有 GND 参考地 |
| 抗干扰能力 | 共模抑制能力强，适合工业现场长距离传输 |
| 典型硬件 | MAX485、SP3485、ISL83485 等 RS485 收发器 |
| 典型协议 | Modbus RTU、自定义帧协议 |
RS485 最核心的优势是：一条双绞线就能把几十个设备串起来，距离远、抗干扰强、成本低。它的缺点是半双工，同一时刻只能有一个设备发送数据，所以必须靠主从轮询或令牌机制来避免冲突。
2. RS485 总线架构与工作原理
2.1 为什么工业现场还在用 RS485
RS485 出现几十年了，到现在依然是工业现场最常见的串行总线之一。对比 RS232，RS485 用差分信号传输，A、B 两线之间的电压差表示逻辑 0 和 1，抗共模干扰能力强，传输距离远。对比 CAN 总线，RS485 不需要控制器局域网络控制器，普通单片机自带的 USART 加上一颗收发器就能用，开发门槛低很多。
从架构上看，RS485 总线是典型的半双工多点总线。总线上挂多个节点，每个节点都有唯一地址，主机轮流询问各个从机，从机收到自己的地址帧后再回复数据。这种一问一答的方式虽然效率不算高，但非常可靠，特别适合传感器采集、仪表读数、变频器控制这类小数据量场景。
2.2 差分信号与 A/B 电平定义
标准 RS-485 规定：A 相对 B 的电压差在 +1.5V 到 +5V 时，表示逻辑 1，也叫空闲态；电压差在 -1.5V 到 -5V 时，表示逻辑 0，也叫发送态。
注意这里有个容易踩坑的地方：不同厂家的设备对 A、B 的定义并不总是一致。有的设备把 A 接到收发器的同相端，有的则反过来。所以在做总线接线时，不能只认颜色，必须用万用表量一下 A、B 对 GND 的电压，或者直接看收发器芯片手册的引脚定义，否则会出现整条总线通信异常、个别设备收发不正常的现象。
2.3 主从架构与轮询机制
RS485 总线上一般只有一个主机，多个从机。主机发送的帧中带有从机地址，从机解析到自己的地址后才响应。这种机制决定了两个工程要点：
- 任何时刻只能有一个设备占用总线发送数据。
- 每个从机的地址必须唯一。
如果多个从机同时往总线上发数据，就会产生总线冲突，A/B 电平被拉成不确定状态，主机收到的就是一帧乱码。所以 RS485 不适合做多主并发通信，除非在协议层做复杂的仲裁。
从代码层面看，主机发送完一帧数据后，必须等从机回复，或者等超时，才能发送下一帧。这个时间窗口如果设计不好，就容易把整个总线的通信节奏打乱。
3. RS485 硬件电路设计要点
3.1 最小系统：MCU 加收发器
STM32 的 USART 输出的是 TTL 电平，不能直接驱动 RS485 总线。必须在 MCU 和总线之间加一颗 RS485 收发器，常见的有 MAX485、SP3485、ISL83485。以最常见的 MAX485 为例，典型引脚功能如下：
| 引脚 | 名称 | 功能 |
|---|---|---|
| 1 | RO | 接收输出，接 MCU 的 RX |
| 2 | RE | 接收使能，低电平有效 |
| 3 | DE | 发送使能，高电平有效 |
| 4 | DI | 发送输入，接 MCU 的 TX |
| 5 | GND | 电源地 |
| 6 | A | 差分正端 |
| 7 | B | 差分负端 |
| 8 | VCC | 电源正极 |
RE 和 DE 两根脚通常接在一起，用一个 GPIO 控制：发送数据时拉高，接收数据时拉低。这就是 RS485 半双工通信最常见的方向控制方式。
3.2 方向控制的三种实现方式
方式一：GPIO 直接控制
MCU 的任意一个 GPIO 连接到 RE/DE 引脚，发送前拉高，发送完成后拉低。这种方式最灵活，缺点是每次发送都要手动切换方向，代码里容易漏掉拉低的动作。
void RS485_SendData(uint8_t *buf, uint16_t len) { RS485_DE_HIGH(); // 切换到发送模式 HAL_UART_Transmit(&huart2, buf, len, 100); RS485_DE_LOW(); // 回到接收模式 }方式二：硬件自动收发电路
用一个三极管或 MOS 管把 TXD 信号反相后接到 RE/DE 上。当 TXD 为低电平时，DE 被拉低，进入接收模式；当 TXD 输出高电平或空闲时，DE 被拉高，进入发送模式。这种方式软件上不需要关心方向切换，很多集成模块都内置了这种电路。
但自动收发电路有一个隐患：RS485 收发器的 DE 使能需要建立时间，如果波特率很高，比如超过 115200bps，DE 切换跟不上数据位，就可能在起始位阶段出错。所以高速率场景下，推荐用 GPIO 控制方向。
方式三：DE 固定拉高，只发不收
如果这个节点只做单向发送，可以把 DE 直接接 VCC，RE 悬空或接高电平。这种方式常用于单向数据上报，但不推荐作为通用方案。
3.3 保护电路：TVS 和气体放电管怎么选
工业现场最常见的 RS485 损坏原因是浪涌和静电。当雷击、电机启停、大功率设备切换时，会在总线上感应出很高的瞬态电压，直接打坏收发器。
最基础的防护是在 A、B 两根线上分别对地并联 TVS 二极管，把瞬态电压钳位在收发器能承受的范围。更完整的方案是三级保护：
- 第一级：气体放电管，泄放大的浪涌电流。
- 第二级：PTC 自恢复保险丝，限制过流。
- 第三级：TVS 二极管，把剩余能量钳位到安全电压。
关于 TVS+TSS 还是 TVS+气体放电管，行业内比较通用的思路是：TVS 响应速度快，但通流能力有限，适合处理静电和快速瞬变；气体放电管通流能力强，但响应速度慢，适合处理雷击浪涌。如果现场浪涌风险高，用 TVS 加气体放电管的组合更稳妥；如果只是普通工业环境，TVS 加 PTC 通常就够用。无论哪种方案，保护电路都要尽量靠近总线连接器放置，缩短引线长度。
3.4 隔离与共地问题
RS485 的 A、B 是差分信号，但收发器本身还需要参考地。长距离通信时，两个设备之间的地电位可能相差很大，导致共模电压超过收发器的允许范围。
常规做法是每个节点用 DC-DC 隔离电源加数字隔离器，把 RS485 收发器与 MCU 的地完全隔开。缺点是成本和体积增加。低成本方案是确保总线两端共地，在布线时把 GND 线一起拉过去，但这样在强干扰现场还是有风险。更稳妥的判断是：如果总线跨接不同配电箱、不同楼层或不同厂房，隔离是必须的。
4. RS485 组网与工业布线避坑指南
4.1 拓扑结构：菊花链，不要星形
RS485 总线标准推荐的拓扑是手拉手的菊花链结构，也就是从主机出发，依次接到从机 1、从机 2、从机 3，最后在末端终止。千万不要接成星形结构，也就是主机引出多根线分别去接各个从机。星形拓扑会产生信号反射，导致通信不稳定，尤其是在高速率长距离场景下。
如果现场布线必须分叉，可以在分叉点加 RS485 中继器或集线器，把一路总线分成多路，每路单独做终端匹配。
4.2 终端电阻与偏置电阻
终端电阻的作用是消除信号在总线末端产生的反射。一根 120Ω 特征阻抗的双绞线，需要在总线两端各并联一个 120Ω 电阻。注意是两端各一个，不是一个。之前见过有人只加了一个终端电阻，问题依旧，就是位置不对。
终端电阻加在总线的物理最远端。主机这边用一个 120Ω 跳线电阻，最远的从机那边再放一个。中间节点不需要加，加了反而会降低总线驱动能力。
偏置电阻解决的是总线空闲时的电平问题。RS485 收发器在总线上没有设备发送时，A 和 B 之间的电压差是不确定的。如果总线空闲时 A 比 B 低，收发器就会误判为收到数据，产生乱码。解决办法是在总线的某些节点上，给 A 线上拉、B 线下拉，让总线空闲时 A-B 维持一个稳定的正电压。常用阻值在 560Ω 到 1kΩ 之间，具体值需要根据总线上的节点数量和收发器输入阻抗来算，以保证每个节点的 A-B 电压都大于 200mV。
4.3 线缆选型与屏蔽层处理
推荐使用 120Ω 特征阻抗的屏蔽双绞线。屏蔽层的作用是防止外部电磁干扰耦合到信号线上。屏蔽层一般建议单点接地，也就是只在主机端接地，避免地环路电流。如果现场干扰特别强，也可以两端都通过电容接地，但这不是通用做法。
线缆走线要注意：
- 远离动力线、变频器输出线，至少保持 20cm 以上距离，实在避不开就穿金属管。
- 不要与动力线在同一线槽内平行长距离走线。
- A、B 两根线必须在一个双绞线线对内，不要用两根独立的线代替。
- 接线端子要选可插拔的螺丝端子，方便调试替换。
4.4 工业现场接线的几个习惯建议
第一，先断电接线，确认无误后再上电。RS485 不推荐热插拔，带电插拔容易产生尖峰电压打坏收发器。
第二，建议统一线色规范。比如 A 用黄色或白色，B 用绿色或黑色，GND 用蓝线。现场设备多的时候，统一的线色能救你一命。
第三，预留调试接口。在每个节点的 A、B、GND 上预留测试点或接线端子，排查问题时可以直接量波形。
5. STM32 RS485 通信实验：环境准备与工程配置
5.1 硬件准备
做这次实验，最低配置如下：
- STM32 开发板一块，常见的是 STM32F103C8T6 核心板。
- RS485 收发器模块一个，或者自己用 MAX485 搭最小电路。
- USB 转 RS485 模块一个，用于和电脑调试。
- 双绞线或者杜邦线若干。
- 万用表，用来量 A/B 电压和终端电阻。
如果手上只有 USB 转 TTL，也可以先把 STM32 和 RS485 模块之间连好，然后让两个 STM32 开发板对发测试，不需要先连电脑。
5.2 CubeMX 配置
用 STM32CubeMX 生成工程时，需要配置 USART 和 GPIO 两部分，下面是一个通用配置流程。
进入 Pinout 视图，选择 USART2，Mode 设为 Asynchronous。参数区设置波特率 9600、数据位 8、无校验、1 停止位。注意 RS485 本身不规定波特率，但 Modbus RTU 最常用的是 9600 和 19200，建议先用 9600 做验证。
然后把任意一个 GPIO 配置为输出模式，用于控制 RS485 的 DE/RE。比如用 PA1，Initial Level 设为 Low，保证上电默认处于接收模式。
如果使用的是带自动收发电路的模块，GPIO 方向控制脚可以不接，只用 TX、RX 两根线。但为了实验可控，还是推荐用 GPIO 控制方向，出错时排查更直观。
5.3 环境检查清单
| 检查项 | 说明 |
|---|---|
| STM32CubeMX 版本 | 使用较新版本，生成代码兼容当前 HAL 库 |
| 编译工具链 | Keil MDK 或 STM32CubeIDE 均可 |
| 串口驱动 | 如果板载 USB 转串口，先确认设备管理器里有没有虚拟 COM 口 |
| 调试器 | ST-Link 或 J-Link，确认电脑能识别 |
| 接线 | MCU_TX 接收发器 DI，MCU_RX 接收发器 RO，A/B 接总线 |
6. STM32 RS485 收发代码实现
6.1 查询方式发送
先给一个最简单的查询发送函数。发送前拉高 DE，发送完成后拉低 DE。
void RS485_SendData(uint8_t *buffer, uint16_t length) { HAL_GPIO_WritePin(DE_GPIO_Port, DE_Pin, GPIO_PIN_SET); // 拉高 DE，进入发送模式 HAL_UART_Transmit(&huart2, buffer, length, 100); // 阻塞发送 HAL_GPIO_WritePin(DE_GPIO_Port, DE_Pin, GPIO_PIN_RESET); // 拉低 DE，回到接收模式 }注意一个问题：HAL_UART_Transmit 返回后，发送移位寄存器里的数据并不一定完全输出完毕。对于长帧或高速率，可以加一个极短延时，或者调用清空标志函数。更严谨的做法是查询硬件发送完成的标志位，但 HAL 库已经封装了，大多数情况下阻塞发送后直接切回接收，下一帧数据间隔足够，问题不大。
6.2 中断方式接收
接收端建议使用中断方式，配合一个接收缓冲区。下面是一个固定长度接收的示例。
uint8_t rs485_rx_buffer[64]; uint8_t rs485_rx_len = 0; void RS485_StartReceive(void) { HAL_UART_Receive_IT(&huart2, &rs485_rx_buffer[rs485_rx_len], 1); } void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart->Instance == USART2) { rs485_rx_len++; if (rs485_rx_len >= sizeof(rs485_rx_buffer)) { // 缓冲区满，停止接收，统一处理 rs485_rx_len = 0; } HAL_UART_Receive_IT(&huart2, &rs485_rx_buffer[rs485_rx_len], 1); } }这个代码每次接收一个字节，回调里重新开启下一次接收。实际工程项目中，最好定义一个帧结束判断条件，比如固定帧尾、空闲中断或者 DMA 加空闲中断，这样才不会出现半包问题。但作为入门实验，逐字节接收已经足够验证通信链路。
6.3 发送测试主循环
主循环里定时发送一帧数据，同时把接收到的数据原样回发。这个逻辑可以当成回环测试来用。
uint8_t test_frame[] = "STM32 RS485 Test\r\n"; while (1) { RS485_SendData(test_frame, sizeof(test_frame) - 1); HAL_Delay(1000); if (rs485_rx_len > 0) { RS485_SendData(rs485_rx_buffer, rs485_rx_len); rs485_rx_len = 0; } }如果手边有 USB 转 RS485 模块，用串口助手连接到总线，就能看到 STM32 每隔一秒发来一帧测试字符串。往总线上发什么，STM32 收到后也会原样回发。
7. RS485 通信实验：功能测试与效果验证
7.1 回环测试：先验证硬件通路
回环测试是整个实验的第一步，也是最容易排除问题的一步。方法很简单：把 A 和 B 短接，或者把收发模块的 A、B 直接连到自己发送的数据线上，在软件里让 STM32 自发自收。
如果使用 USB 转 RS485 模块，直接把模块的 A 接 B、B 接 A，形成一个回环。然后打开串口助手发送数据，能收到同样的数据，说明 USB 转 RS485 本身的收发链路是通的。
7.2 STM32 与 USB 转 RS485 通信测试
接线方式：
| USB 转 RS485 | STM32 RS485 模块 |
|---|---|
| A | A |
| B | B |
| GND | GND |
注意：RS485 是差分信号，A 接 A、B 接 B。如果通信不上，尝试把 A、B 对调。这是 RS485 调试中最常见的低级错误，但也是最容易忽略的。
测试步骤：
- 打开串口助手，选择正确的 COM 口，波特率设为与代码一致。
- 先用 STM32 定时发送，看串口助手能否收到数据。
- 再在串口助手手动发送一帧数据，看 STM32 是否回发相同内容。
判断成功的标准：收发数据完全一致，没有乱码和丢字节。
7.3 双 STM32 通信测试
如果没有 USB 转 RS485，可以用两块 STM32 开发板做双机通信测试。两块板的 RS485 模块 A 接 A、B 接 B，GND 共地，然后在两块板之间互相发送帧。
建议在程序里加一个简单的帧格式，比如前两个字节是帧头 0xAA 0x55，接着是设备地址、命令、数据长度和数据内容。这样测试时，可以验证数据帧的完整性和地址过滤逻辑，也为后续接 Modbus 协议热身。
7.4 多机组网测试
多机测试时，主机逐个轮询从机地址。每台从机终端电阻通过跳线接入总线，中间节点不接。把波特率降到 9600，先用 5 台以内的设备验证轮询逻辑。
遇到的现象大概率是两种：从机地址冲突导致两台上位机同时回复；或者总线没有终端电阻导致长线反射，接收数据时对时错。这两种问题分别对应协议层和物理层，排查时要分清楚。
8. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 完全收不到数据 | A/B 接反 | 对调 A/B 测试 | 重新接线 |
| 只能收不能发 | DE 没有拉高，或 DE 控制 GPIO 配置错误 | 用逻辑分析仪或万用表量 DE 电平 | 检查 GPIO 初始化和发送时序 |
| 只能发不能收 | DE 一直拉高，没有回到接收模式 | 检查发送函数是否在结束后拉低 DE | 修正方向控制逻辑 |
| 通信偶尔乱码 | 波特率误差、干扰、缺少共地 | 示波器抓波形，量 A-B 差分电压 | 检查晶振、降低波特率、补共地线 |
| 总线空闲时收到 0xFF 或乱码 | 缺少偏置电阻，总线空闲电平不确定 | 量空闲状态 A-B 电压 | 加偏置电阻或使能收发器内部偏置 |
| 波特率设置为 115200bps 时不稳定 | 线缆过长或 DE 切换时间不足 | 检查线长和自动收发电路 | 降低波特率或改 GPIO 控制方向 |
| 连接调试器报 error: no STM32 target found | SWD 接线错误、板子供电不足或调试口被复用 | 检查 SWD 四根线、断电重新上电 | 按住复位再烧录，或缩短 SWD 线 |
| USB 转串口设备管理器出现感叹号 | 驱动未安装或驱动异常 | 设备管理器查看错误码 | 重新安装驱动或更换 USB 口 |
| 串口助手提示传输格式不正确 | 串口参数不匹配：波特率、数据位、校验位等 | 核对计算机与实际配置 | 将串口参数改为 9600/8/N/1 或与代码一致 |
| 多机同时回复 | 从机地址重复或从机没有正确判断地址 | 检查每个从机地址配置 | 确保地址唯一，协议帧带校验 |
| 延时函数卡死 | SysTick 中断意外被关闭或中断优先级配置异常 | 检查中断优先级分组和 SysTick 配置 | 恢复 HAL_Delay 所需的中断，或改用定时器延时 |
其中 error: no STM32 target found 这个问题在刚入门时出现频率很高，多数情况下不是芯片坏了，而是 SWD 线接触不良、下载器供电不足或者板子处于复位状态。遇到这种弹窗，先把板子断电再上电，按住复位键再点下载，多半能解决。
另外一个容易被忽略的问题是：如果 GPIO 初始化的方向控制脚和 USART 引脚复用了，会导致收发异常。检查 CubeMX 里引脚有没有冲突，初始化代码里有没有先配置 GPIO 再初始化串口。
9. 性能观察与资源占用
RS485 属于工业低速总线，性能观察重点不在吞吐量，而在以下三个维度。
9.1 波特率与通信距离的关系
RS485 的速率和距离是相互制约的。标准规定最大距离约 1200m，但这是低速率下的数据。经验值如下：
| 波特率 | 可靠距离（约） |
|---|---|
| 9600bps | 可达 1000m 以上（视线缆质量） |
| 19200bps | 数百米 |
| 115200bps | 几十米到百米左右 |
如果你的项目距离远，优先用 9600。如果距离只有几米，比如板间通信，直接用 115200 也稳定。
9.2 内存与 CPU 占用
逐字节中断接收会频繁进入串口中断。以 9600bps 计算，每字节约 1ms，中断频率不算高，对 STM32F103 来说压力很小。但如果是 115200bps，每字节约 87us，中断频率明显提高，如果主循环还在做大运算，就可能丢字节。
更稳妥的做法是使用 DMA 加串口空闲中断，配合环形缓冲区。这样 CPU 只在数据接收完成后做一次搬移，中断占用率大幅降低，代码复杂度也更容易控制。
9.3 多机通信的轮询周期估算
假设总线上有 10 个从机，每个从机回复 8 字节，波特率 9600，那么一帧回复大约 8.3ms，加上帧间隔和主机处理时间，单轮询周期大约在 150ms 到 200ms 之间。这个数据对实时性要求高的场合很重要，比如伺服电机控制、运动控制，轮询周期过长会导致响应变慢。此时要考虑提高波特率、改用 CAN 总线，或者让从机主动上报。
10. 最佳实践与工程建议
10.1 协议层：从裸收发走向 Modbus RTU
裸收发代码只能用来验证物理链路，工程项目里至少要加上帧校验和超时重发。RS485 上最成熟的协议是 Modbus RTU，它规定了数据帧格式：地址码、功能码、数据、CRC 校验。如果项目不需要特殊定制，直接移植 FreeModbus 是最省力的方案。FreeModbus 在 STM32 上移植有大量现成代码，只改串口底层就行。
10.2 帧格式设计建议
如果自己设计协议，建议至少包含以下字段：
- 帧头，固定字节，用于同步。
- 地址，用于多机寻址。
- 功能码或命令字。
- 数据长度。
- 数据内容。
- CRC16 校验。
发送时注意：CRC 校验范围要包含地址、功能码、数据长度和数据内容，接收端校验不过就丢弃该帧，等待超时重发。
10.3 代码与工程管理
- 主循环不要用 HAL_Delay 做长时间阻塞，会影响串口接收。
- 接收缓冲区和发送缓冲区分开定义。
- 发送函数加上超时保护，避免总线异常导致死等。
- 为每个从机建立统一的地址宏定义，方便修改。
- 报文日志要带时间戳，排查现场问题时能快速定位是哪一帧卡住。
10.4 工业现场合规提醒
RS485 接线和调试涉及工业控制设备。在实施前一定要明确现场设备的断电状态，不能在设备运行中随意插拔总线，避免造成误动作。涉及电机、变频器、伺服驱动器时，改动通信线缆或升级程序前需要和生产负责人确认安全边界。总线涉及多个厂家的设备时，需要确认各设备的 A/B 定义、终端电阻配置和数据帧格式，避免因协议不匹配导致设备异常。所有调试操作应在测试环境或已断电环境中先行验证，再部署到生产链路中。
10.5 RS485 与 CAN 怎么选
选 RS485 还是 CAN，从场景来判断。如果只是传感器采集、仪表读数、多台设备低速轮询，RS485 加 Modbus 足够，成本低、资料多、调试方便。如果现场设备数量多、数据量大、实时性要求高，或者对总线仲裁有刚需，CAN 更合适。RS485 本身没有硬件仲裁机制，多从机同时上发数据就冲突；CAN 的仲裁机制是硬件实现的，天然适合多节点并发上报。
选型时可以围绕这三个问题简单判断：
- 节点数是否超过 32 个？
- 是否需要高速大量数据交互？
- 是否有多节点主动上报的需求？
如果答案都是否，RS485 是性价比最高的选择。
11. 总结与下一步
RS485 总线通信实验的真正难点不在 STM32 的串口代码，而在物理层。A/B 接线、终端电阻、偏置电阻、共地、屏蔽层处理，任何一个环节没做好，代码写得再正确，总线照样通信不稳定。这是最开始做 485 实验时容易忽略、后面在现场才会付出代价的坑。
建议先做回环测试确认硬件通路，再用一块 STM32 接 USB 转 RS485 模块做收发验证，最后扩展到双机和多机组网。过程中逐步加入终端电阻、偏置电阻和真实线缆，感受它们在长距离通信中的影响，比单纯跑通一个例程更有价值。
后续可以继续扩展的方向：一是移植 FreeModbus 协议栈，把 RS485 通信标准化；二是用 DMA 加空闲中断重构收发逻辑，提高高波特率下的稳定性；三是把 RS485 收敛为一个通用驱动模块，方便在不同 STM32 型号之间复用。
这篇文章建议收藏备用，等实际做毕业设计、电赛或者工装设备时，再翻开排查清单对照一遍，能少走很多弯路。
