Modbus-RTU这个协议说实话在工业现场摸爬滚打这些年基本是绕不开的。别看它诞生于1979年年纪比不少看这篇文章的工程师都大但到今天依然是PLC、仪表、传感器、变频器之间通信的“通用语言”。很多新手一上来就啃协议文档被帧格式、CRC校验、功能码搞得一头雾水又在实际调试时被接线噪声、从站无响应、数据对不上等问题反复折磨。这篇文章我打算用图文拆解的方式把Modbus-RTU从原理到实战捋一遍把那些文档里写得晦涩、老工程师又懒得详细讲的东西一次说清楚。这篇文章适合谁看不管是刚入行的自动化工程师、做嵌入式开发的学生还是需要对接第三方设备的上位机开发者只要你的工作里需要和设备“对话”那Modbus-RTU就是一块绕不开的敲门砖。我会把帧结构逐字节拆开把CRC校验的算法讲透再用一个完整的实操例子带你走通主机Master和从机Slave之间的读写过程最后把那些年我踩过的坑、排查问题的套路一并整理出来。1. 核心概念先把Modbus-RTU的前世今生和家族关系捋清楚1.1 Modbus-RTU是什么和Modbus TCP、Modbus ASCII有什么不同先从最基础的讲起。Modbus协议从物理层到应用层其实分了好几个变种。日常碰得最多的就是Modbus-RTURemote Terminal Unit远程终端单元和Modbus TCP偶尔也会遇到Modbus ASCII。这三个用同一个应用层“语言”说事但传输方式和编码规则不同。Modbus-RTU走的是串行通信典型的是RS232或RS485总线数据以二进制方式直接发送一个字节就是8位效率高、报文紧凑。Modbus ASCII则是把每个字节拆成两个ASCII字符来传比如十六进制0x03传成字符0和3报文长度直接翻倍但好处是对时间间隔不那么敏感早期低速设备用得比较多。Modbus TCP则是把Modbus报文封装到TCP/IP里走以太网专门给现代工业网络用。选型的时候现场总线是RS485那基本就是RTU如果设备只有网口那就走TCP很少有纠结的空间。但从工程量的角度看Modbus-RTU依然是门槛最低、最容易上手的一种一根双绞线一个USB转485的转换器一台电脑就能在十分钟内搭起一套能用的通信链路。1.2 主从架构一主多从的“一问一答”机制Modbus-RTU的核心架构是主从模式也就是Master-Slave。总线上只能有一个主机Master从机Slave最多可以挂247个每个从机有一个唯一的地址范围1到247。通信永远是主机发起从机只能被动应答不能自己主动说话。这个设计在今天的眼光看有点“专制”但在工业现场反而是优点不会出现两个设备同时抢总线、数据冲突的问题确定性很强特别适合周期性轮询采集数据的场景。打个比方整个总线就像一个班主任主机在点名学生从机回答问题。班主任问“1号同学你多少分”1号回答“我98分”其他学生不能插嘴。如果班主任问了个没人应答的问题那就等待超时然后继续问下一个。这个“一问一答”的节奏就是Modbus-RTU工作的全部逻辑。1.3 常用功能码读什么、写什么用哪个码Modbus协议定了不少功能码但日常用得最多的其实就那么几个。我整理了一下新手只要先掌握这些就能覆盖绝大多数应用场景功能码名称作用典型应用0x01读线圈读取从机的开关量输出读取继电器状态0x02读离散输入读取从机的开关量输入读取按钮、限位开关状态0x03读保持寄存器读取从机的保持寄存器可读写读取设定值、累计值等0x04读输入寄存器读取从机的输入寄存器只读读取传感器实时值0x05写单个线圈控制单个开关量输出启动/停止电机0x06写单个寄存器写入单个保持寄存器修改设定值0x0F写多个线圈连续写多个开关量输出批量控制继电器0x10写多个寄存器连续写多个保持寄存器下发参数表这里特别要提醒一下寄存器分为保持寄存器Holding Register和输入寄存器Input Register。保持寄存器是可读可写的放的是设定值、累计量这类可以被修改的数据输入寄存器是只读的放的是传感器实时测量值这类只允许主机读取的数据。功能码的选择背后是有数据属性逻辑的用错了协议栈直接报异常码这个后面展开讲。2. 帧格式与CRC校验逐字节拆解RTU报文2.1 RTU帧的基本结构Modbus-RTU的报文结构非常紧凑一帧数据由四个部分组成从机地址1字节、功能码1字节、数据区N字节、校验码2字节。加上帧与帧之间的静默间隔至少3.5个字符时间就构成了一帧完整的报文。我们拿最常见的“读保持寄存器”请求帧来举例。假设主机要读取地址为0x01的从机从寄存器地址0x006B开始读2个寄存器也就是4个字节的数据。请求帧是这样的01 03 00 6B 00 02 7A 16逐字节拆解01从机地址表示这条命令是发给地址为1的设备。03功能码表示“读保持寄存器”。00 6B起始寄存器地址高字节在前0x006B换算成十进制就是107。00 02要读的寄存器数量这里读2个。7A 16CRC16校验码低字节在前这里0x167A发送时先发低字节0x7A再发高字节0x16。注意多字节数据在Modbus里默认是大端模式Big-Endian也就是高字节在前、低字节在后。这个点上栽过跟头的人非常多比如寄存器值是0x1234发送/接收顺序是12 34如果你把它当成小端处理数值就变成了0x3412会差得离谱。从机收到请求后会回复响应帧。正常响应帧结构是地址 功能码 字节数 数据 CRC。上面那个请求的响应大概是01 03 04 12 34 56 78 9A BC其中04是数据字节数因为是2个寄存器每个寄存器2字节所以一共4字节。12 34是第一个寄存器的值56 78是第二个寄存器的值最后是CRC。如果从机拒绝了请求会返回异常帧功能码最高位置1并附带一个异常码。比如请求的功能码是0x03异常响应帧的功能码就是0x83。常见的异常码有异常码含义常见原因0x01非法功能码从机不支持该功能0x02非法数据地址寄存器地址越界0x03非法数据值数量参数超范围0x04从机设备故障从机内部出错2.2 CRC16计算原理、手算和代码都要会CRC校验是全帧的核心。Modbus-RTU用的是CRC16多项式是0x8005实际运算是反序多项式0xA001初始值为0xFFFF。工作原理就是把整个报文地址功能码数据区当作一个二进制大数按位做模2除法余数就是CRC值。传输时低字节在前。我推荐新手直接记住现成的查表法或者直接调库但作为工程师至少要把计算过程看懂否则真遇到手算校验的场合会非常被动。这里我贴一段C语言的逐位计算方法方便大家理解运行过程uint16_t crc16_modbus(uint8_t *data, uint16_t len) { uint16_t crc 0xFFFF; for (uint16_t i 0; i len; i) { crc ^ data[i]; for (uint8_t j 0; j 8; j) { if (crc 0x0001) crc (crc 1) ^ 0xA001; else crc 1; } } return crc; }核心逻辑就是初始寄存器填0xFFFF每进来一个字节先和CRC低字节异或然后循环8次右移如果最低位是1就异或0xA001。8次循环结束这个字节就算处理完了继续下一个字节。全部报文计算完后寄存器里的值就是CRC发送时低字节在前高字节在后。上面那个请求帧01 03 00 6B 00 02算出来的CRC就是0x167A所以帧尾发送7A 16。你可以用这个例子验证自己的代码算得对不对。2.3 帧间隔3.5个字符时间为什么是硬指标Modbus-RTU有个比帧格式更隐蔽的坑就是帧与帧之间的时间间隔。协议规定帧内字符之间的间隔不能超过1.5个字符时间帧与帧之间的间隔不能小于3.5个字符时间。为什么因为RTU帧没有明确的起始符和结束符是靠“静默时间”来分帧的。如果一个帧内的两个字节之间停顿超过了1.5个字符时间接收方会认为这是两帧数据然后第二帧因为没有完整头解析就会出问题。反过来如果两帧之间的间隔不足3.5个字符时间接收方会把两帧合并成一帧直接解析失败。字符时间怎么算就是单个字节在总线上传输所需的时间公式是字符时间 1 / 波特率 × 10位1起始位 8数据位 1停止位没有校验位时。以9600波特率为例1个字符约1.04毫秒3.5个字符时间就是3.65毫秒。所以在主机发送完一帧之后别急着立刻发下一帧最好有至少5毫秒的间隔从机处理完请求后也同理。很多调试中的诡异问题最后查下来都是发送间隔太短导致的。2.4 为什么选RTU而不是ASCII一个忍不住吐槽的对比有些老设备还支持Modbus ASCII模式两种编码方式的帧结构也不一样。ASCII模式每个8位字节被拆成两个ASCII字符发送例如0x4B发送4和B并且在帧头和帧尾加了:和CRLF作为起始结束标记。从效率角度看RTU明显更占优同样传一条读请求RTU只要8个字节ASCII要17个字符帧长了至少一倍。从可靠性看RTU有CRC16校验ASCII用的是LRC校验CRC的检错能力更强。但ASCII也有它的存在价值很多老的组态软件、测试终端设备对ASCII处理更成熟而且ASCII帧有明确的开始和结束符对时间间隔不敏感在干扰大、时序不稳的环境里反而更不容易分包错。我的建议是新项目除非硬件或从机固件强制要求ASCII否则一律选RTU。它结构紧凑、校验严谨、生态友好工具箱里几乎所有调试软件都对RTU支持得最好。3. 从零搭建Modbus-RTU通信从物理层到应用层的一次完整走通3.1 物理层接线RS485的A/B线、终端电阻和屏蔽层Modbus-RTU最常见的物理层就是RS485。它用差分信号传输A线通常对应D-和B线通常对应D之间的电压差来决定逻辑电平所以抗共模干扰能力很强传输距离最远能到1200米左右和波特率有关。接线有几个硬规矩A和B线要用双绞线不要用平行线双绞能有效抵消电磁干扰。屏蔽层单端接地通常是主机侧接地不要两端都接否则形成地环路反而引入干扰。总线两端要接120欧终端电阻。终端电阻的作用是吸收信号反射避免高速率时数据波形出现振铃。如果只接两台设备在从机端并联一个120欧即可如果接多台主机端和总线最远端的从机端各接一个。设备之间手拉手菊花链连接尽量不要星形拓扑。星形接法会产生信号反射和阻抗不连续通信容易时断时续。另外特别强调一下接地。RS485是差分信号理论上看的是两线间的电压差不依赖地但是实际操作中不共地信号地的RS485系统经常出现通信不稳定的情况。因为每个设备电源的地电位不一致共模电压可能超过收发器的允许范围造成芯片损坏或通信异常。最稳妥的做法是如果距离不远、设备不多让各设备之间用一根地线连起来如果距离远就确保每个设备可靠接地避免共模电压过高。3.2 通信参数配置波特率、数据位、停止位、校验位Modbus-RTU的通信参数不是随便设的主机和从机必须完全一致否则数据收不全、乱码。最常见的配置是9600波特率8位数据位1位停止位无校验8N1。但也有一批设备默认是19200或者38400还有一些设备在“无校验”时的数据位要设成8位、在“偶校验”时要设成9位数据位这个细节不同厂家的实现不同务必看产品手册。通用建议是初调时从9600 8N1开始成功率最高。波特率越高对线路质量要求越高传输距离也越短。9600和19200在几十米范围内差别不大但超过几百米9600明显更稳。校验位尽量选无校验或者偶校验奇校验在Modbus生态里用得少部分设备支持不好。3.3 一个完整实例用0x03读保持寄存器、0x06写单个寄存器纸上谈兵没用我用一个实际场景演示一遍。假设有一块温控表Modbus地址是1寄存器地址40001协议里的地址就是0x0000存放当前温度测量值寄存器地址400020x0001存放温度设定值。我要做的操作是读取当前温度然后把设定值改成65.5。温度值在寄存器里默认是整数假设分辨率是0.1那么当前温度23.4度在寄存器里的值就是234对应十六进制就是0x00EA。第一步主机发送读请求发送: 01 03 00 00 00 01 84 0A01从机地址03读保持寄存器00 00从寄存器0x0000开始读00 01读1个寄存器84 0ACRC从机正常响应接收: 01 03 02 00 EA 39 82解析01地址03功能码02数据字节数1个寄存器2字节00 EA就是寄存器值换算成十进制234再乘以分辨率0.1就是23.4度。第二步写设定值65.5度。65.5 / 0.1 655十六进制是0x028F。写单个寄存器用功能码0x06发送: 01 06 00 01 02 8F 19 3001从机地址06写单个寄存器00 01目标寄存器地址02 8F要写入的值19 30CRC从机成功响应时会原样回显这个报文接收: 01 06 00 01 02 8F 19 30只要响应帧和请求帧完全一致说明写入成功。如果响应帧功能码变成0x86后面还跟一个异常码那就要按前面讲的异常码表去排除了。3.4 主机代码怎么写串口发送与超时解析的关键套路嵌入式端和上位机端的实现思路其实是相通的。我用C语言伪代码展示一下主机侧的请求发送和响应解析框架重点不在于完整代码而在于结构化思维。// 构建读保持寄存器请求 uint8_t req[8]; req[0] slave_addr; req[1] 0x03; req[2] (reg_addr 8) 0xFF; req[3] reg_addr 0xFF; req[4] (reg_num 8) 0xFF; req[5] reg_num 0xFF; uint16_t crc crc16_modbus(req, 6); req[6] crc 0xFF; // 低字节在前 req[7] (crc 8) 0xFF; // 清空接收缓冲区 clear_rx_buffer(); // 发送请求 uart_send(req, 8); // 等待响应超时时间根据波特率动态计算 uint32_t timeout compute_timeout(baudrate, 8); uint8_t rsp[256]; uint16_t rsp_len 0; while (1) { if (uart_receive_byte(rsp[rsp_len])) { rsp_len; // 根据最小帧长度判断是否等待完整帧 if (rsp_len 3 rsp[0] slave_addr) { // 已收到完整帧标志帧间超过3.5字符时间 } } if (millis() start timeout) break; } // 校验CRC if (!check_crc(rsp, rsp_len)) { // 处理校验失败 } // 判断功能码最高位 if ((rsp[1] 0x80) ! 0) { // 从机返回异常码 }这里要强调一个关键点接收响应时不能一收到最后一个字节就立刻去解析而要判断总线静默已经超过3.5个字符时间因为串口的接收中断不会告诉你“这一帧完了”它只会一个字节一个字节地报你需要自己用定时器判断帧结束。这也是新手最容易忽略的地方——在逻辑分析仪上看着数据都对但程序就是解析不出来。3.5 从机侧实现思路中断收帧、主循环解析如果你是在嵌入式设备上实现从机侧那思路和主机侧刚好相反。从机要做的核心事情是串口接收中断里不停地把字节存进缓冲区同时用定时器记录“距上字节到达时间”。当检测到总线静默超过3.5个字符时间认为一帧结束。主循环或状态机里对接收缓冲区做帧解析匹配从机地址、解析功能码、判断CRC、分发到对应的操作函数、构建响应帧、串口发送。从机侧最大的坑是响应速度。Modbus协议规范里没有强制规定从机必须在多少毫秒内响应但主机的超时时间通常不会设置得太长常见是100ms到500ms。如果从机内部有比较耗时的操作比如读EEPROM、做ADC转换一定要把响应处理放在主循环里异步完成而不是在串口中断里做大量工作。我见过最典型的问题从机在串口中断里直接调用了一个带延时的读温度函数结果一帧数据还没收全延时的时间片里后面几个字节丢了从机永远解析不完整。正确的做法是中断里只做“收字节计时”解析/响应都挪到主循环里。4. 调试实战从报文解析到问题定位的完整手法4.1 调试工具的选择USB转485线、串口助手和逻辑分析仪工欲善其事必先利其器。做Modbus-RTU调试手头至少要有一套USB转RS485适配器市面上主流的FTDI芯片方案的兼容性最好国产的CH340方案性价比高也够用。要特别注意买的时候确认是“自动收发切换”还是“需要手动控制方向”后者用起来很痛苦容易因为方向切换不及时导致收发冲突。软件方面串口助手类的工具有很多我这里列几个我实际用下来靠谱的Modbus Poll / Modbus Slave老牌调试利器Modbus Poll模拟主机Modbus Slave模拟从机界面直观适合快速验证。Serial Studio开源的多平台串口调试工具适合数据可视化。Docklight / AccessPort纯串口监控、报文收发工具适合逐字节分析。除了软件强烈建议备一个逻辑分析仪。USB转485只是在操作系统层面虚拟了一个串口你看到的数据是已经转成USB后的字节流看不到物理层上的信号质量。逻辑分析仪能直接抓RS485差分线上的波形判断是否有信号反射、毛刺、占空比异常等问题。排查奇怪故障时这个工具能省一个下午的时间。4.2 报文级实例用串口助手抓一次完整的读请求和响应下面我模拟一次实战把温控表接到USB转485上用串口助手向它发读请求。串口配置96008N1十六进制显示。发送区输入01 03 00 00 00 01 84 0A如果接线正常、从机地址正确接收区会立刻回一条01 03 02 00 EA 39 82如果接收区没有任何回应第一步先确认从机地址是否正确。USB转485的A、B线是否接反这个问题出现频率超高交换A/B试试。波特率是否匹配。串口号是否选对以及有没有被占用。如果收到一条异常响应01 83 02 C0 F10x83说明功能码被置最高位0x02是异常码表示“非法数据地址”。这种情况一般是寄存器地址越界或者从机不支持这个寄存器区间去查设备寄存器映射表就不会错。4.3 分层的排查思路物理层、数据链路层和应用层排查Modbus通信问题我习惯分三层去做不要一上来就盯着报文看物理层排查看信号能不能“传”——万用表量A/B之间的电压正常情况下空闲时大约1.5V到5V之间取决于驱动器如果测出来是0V或者接近0检查有没有接线松脱、收发器供电有没有问题用示波器或逻辑分析仪看发送波形确认幅度、占空比、有无明显振铃。数据链路层排查看字节能不能“收全”——确认波特率、数据位、停止位、校验位是否一致确认帧间隔是否满足3.5字符时间要求用串口助手自发自收验证USB转485本身是否正常。应用层排查看协议能不能“理通”——检查从机地址、寄存器地址、功能码、寄存器数量检查CRC计算是否正确检查设备有没有处于编程/配置模式部分设备在配置状态下不响应Modbus通信。每次调试遇到问题我都是按这个顺序走的大部分问题在物理层和数据链路层就能解决真正跑到应用层的其实不多。4.4 超时时间的工程化设定主机发完请求后等多久算超时这里有个常见的工程配置问题。如果超时太短从机稍微忙一点就误判超时如果超时太长整个轮询周期被拉长影响系统实时性。一个工程上常用的估算方法超时时间≥主从设备的总帧时间 从机处理时间 链路余量。9600波特率下一帧8字节请求约8.3毫秒16字节响应约16.7毫秒大多数从机的处理时间在10到50毫秒之间所以超时设100毫秒是合理起步值如果链路经过无线透传模块或者多级网关建议设300到500毫秒给中间环节留够转发和处理时间。需要监控多个从机时还有一点很关键主机发出广播报文从机地址0x00后从机不回任何响应所以主机的轮询循环里要单独处理广播的等待时间不要占用普通请求的超时逻辑。5. 扩展与应用多从机组网、协议网关和现代工业场景5.1 多从机轮询地址分配与时间预算当总线上挂的从机不止一台时主机就要按地址逐个轮询。比如挂了三台设备地址分别是1、2、3主机的轮询顺序就是读1号、读2号、读3号然后循环。地址0是广播地址向它发指令所有从机都会执行但不回响应。轮询周期怎么算每个从机的单次请求/响应周期约等于“请求帧时间 从机处理时间 响应帧时间 帧间隔”。以9600波特率、读2个寄存器为例请求约8.3毫秒响应约11.2毫秒从机处理约20毫秒那么单次周期大概40毫秒。三个从机就是120毫秒加上余量一个轮询周期约150到200毫秒。这对于温度、压力等慢变量足够了如果是需要更快采集的场合可以考虑提高波特率或升级Modbus TCP。5.2 Modbus-RTU与Modbus TCP的桥接网关的配置思路工业现场经常遇到既有串口设备又要接入上位机网络的局面这时候就要在中间加一个Modbus RTU转Modbus TCP网关。网关的典型配置逻辑是一个网口连接交换机一个或多个RS485口连接现场设备。配置时需要设置的参数包括串口参数波特率、数据位、停止位、校验位这些必须和现场从机一致。从机地址映射表把RTU侧的从机地址映射到TCP侧。数据区映射把寄存器区间映射成TCP侧可以访问的地址区间。调网关时最容易踩的坑是“串口参数不一致”。很多厂家的网关默认波特率是115200而现场设备是9600网关侧一直报通信错误。遇到这种情况先看网关串口的文档确认和从机用的是同一套参数。5.3 Modbus-RTU的生命力为什么新项目还在用它你可能要问都什么年代了为什么还在用Modbus-RTU以太网、现场总线、工业无线方案多得是。原因其实很质朴它够简单、够开放、成本够低。一颗几块钱的MCU、一片几块钱的RS485收发芯片就能实现一个从站协议栈实现难度低、调试工具链成熟、几乎所有工业软件都原生支持。在很多“并不需要极高性能”的场景里比如楼宇自控、暖通、小型自动化设备、环境监测Modbus-RTU依然是性价比最高的选择。它也许不够炫但它像个老伙计一样可靠这正是工业现场最看重的品质。6. 常见问题与避坑指南这些年我踩过的坑一次给你排完6.1 高频问题速查表我自己整理了一个排查速查表现场遇到问题可以按表索骥省去翻手册的时间现象可能原因检查项完全无响应A/B接反对调A/B线完全无响应波特率不一致核对主机、从机串口参数完全无响应从机地址错误确认报文首字节与从机设置一致完全无响应RS485方向切换异常检查自动收发切换芯片必要时手动控制DE/RE偶发无响应终端电阻缺失/过多确认总线两端各有一个120欧电阻偶发无响应帧间隔过短主机增加帧间延时至少大于3.5字符时间CRC校验失败波特率、数据位不匹配核对通信参数、检查有无干扰返回异常码0x02寄存器地址越界查从机寄存器映射表返回异常码0x03寄存器数量超范围减少单次读取寄存器个数多个从机互相干扰地址冲突逐一核对从机拨码/软件地址数据时对时错屏蔽层接地不良屏蔽层单端可靠接地数据值翻倍或减半寄存器数据格式理解错误确认大小端、数据类型是16位/32位6.2 老工程师的几条实操心得这些年在现场摸爬滚打总结几条文档里不会写的经验第一收发“吵架”时优先怀疑自动收发电路。有的USB转485模块用的是“自动换向”方案靠检测串口电平变化来切换方向波特率低时可能没问题但总线负载重时切换不及时就会出现“请求发出去了从机的响应被自己吞掉”的离奇现象。解决办法是用带独立方向控制脚的模块或者干脆在软件里请求前拉高一个GPIO去控制方向。第二不要小看地电位差。之前一个项目主机和从机分别接在不同电源上两边的地电位差了十几伏通信偶尔正常偶尔乱码最后量了共模电压才知道收发器已经逼近极限后来老老实实把两个设备的地连在一起问题立刻消失。第三长线传输时波特率往低调是解决90%不稳定问题的“万能药”。有的项目在38400波特率下死活调不通降到9600就稳得像无事发生别跟电气特性和线路寄生参数较劲能用低速率解决的问题就果断降低速率。6.3 数据解析中的大小端与数据类型陷阱很多人在Modbus上栽跟头不是通信本身有问题而是解析数据格式搞错了。默认情况下16位寄存器是大端传输但如果从机是PLC或者单片机寄存器内部的数据组合方式可能与标准的“高字节在前”不同。常见的有16位整数一个寄存器大端直接换算。32位整数或浮点数两个连续寄存器组合方式有“ABCD”和“CDAB”两种字节序和字序都可能反转。Modbus协议本身没规定32位数据的字节排列所以不同厂商的设备可能是完全相反的。负数有的用补码表示有的用偏移量表示如0x8000代表0这跟设备的具体数据类型定义有关。解析前建议先查设备手册中“数据映射表”和“数据类型说明”手册没写就实测写一个已知数值读回来看原始字节排列一试便知。这种“试错法”虽然在文档层面不够优雅但却是效率最高的办法。写在最后的一点体会做自动化这些年我越来越觉得Modbus-RTU像是一把“万能钥匙”。它不花哨但足够稳固几乎能打开任何工业设备的通信大门。每次调试新的设备我常做的第一件事就是翻开手册找到寄存器表然后用串口助手发一条0x03读请求看能不能得到回显。这一步通了后面的事就好办了。最后分享一个小技巧项目落地前先花半天时间做一次“收发链路的自检”——拿一个USB转485模块把A和B短接用串口助手发数据看能否原样收到能收到说明转换器和链路这一步没问题再接入现场设备排查时就把通信链路的嫌疑大大降低了。这个习惯救过我很多次也建议你试试。