★ FEATURED ARTICLE 产线监控画面上某台设备一直显示离线网线插着、电源亮着、指示灯也正常但数据就是不上来。上位机的调度逻辑要读这个设备的电流、温度、状态字缺了它整条线的联动保护都没法动作。现场几个工程师围在一起有人说网关坏了有人说PLC内部有故障有人怀疑交换机不行。折腾到半夜最后把抓包文件导出来在 Wireshark 里选到 Modbus 协议那一栏几秒钟就锁定了问题请求已经发出去了但响应里的功能码带了一个异常码说明从站根本没把这次请求当成合法请求处理。这个区别要是靠猜可能还要在现场耗上一两周。这篇文章写的就是 Wireshark 在工业控制中最典型的一类用法Modbus 协议分析。前面那几句话不是刻意渲染是我实际做过的场景而且类似的事几乎每年都会碰到。Modbus 在工控网络里的地位有点像楼宇里的消防烟感——看着不起眼但遍布整个系统凡是做水处理、电力、交通、楼宇自控或者产线设备集成的朋友几乎都绕不开它。而 Wireshark 作为免费、跨平台、能解码几十种工业协议的抓包工具是排查这类通信问题最快的入口之一。这篇文章会从协议本身的版本差异讲起把抓包位置、过滤器、报文结构、功能码、异常码这些基础打牢再用四个真实故障场景复盘从抓包到定位的完整思路最后聊一些我用 Wireshark 处理 Modbus 故障时踩过的坑。内容默认你已经有 Wireshark 的基本操作能力比如打开接口、录包、保存文件这类的就不展开细说重点放在“拿到包之后怎么思考”和“哪些字段值得死盯”上。1. 先搞清楚你抓的是 Modbus 的哪一层1.1 Modbus 家族不只有 TCP 一种形态很多刚开始做工控通信排查的朋友一开 Wireshark 就照样抓包但抓了半天发现报文里看不到 Modbus 的数据只有一堆 TCP 包。原因往往不是协议没跑而是你抓的东西和 Modbus 的真实载体对不上。Modbus 在实际项目里有好几种形态最常见的 Modbus TCP走以太网默认用 502 端口链路层就是普通 IP 数据包Modbus RTU 走串口比如 RS-485 或 RS-232它的报文是用二进制帧承载的并且带 CRC16 校验还有 Modbus ASCII同样走串口或者现场某些老设备报文用可打印的十六进制字符来传输逐字节转成 ASCII 显示。Wireshark 能直接解码的是 Modbus TCP因为这种形态下数据能完整地封装进 TCP 载荷Wireshark 一识别到目标端口 502就会自动规整成 Modbus/TCP 的协议分支来给你分析。如果你现场设备之间其实是 RTU 直连并没有经过网关转成 TCP那 Wireshark 直接抓是抓不到的只能先用串口监听设备把 RTU 帧采下来再手动解析或者用一个双向的 RTU/TCP 网关把串口流量透传成 TCP 再抓。实际项目里很多老旧产线都是这样的设备端用 RTU上位机前面挂一个网关网关负责把 RTU 换成一个 Modbus TCP 的服务器端口。这时候 Wireshark 抓到的其实只是网关和上位机之间的 TCP 流量网关到设备之间的那一段从 TCP 包里是看不全的。要真正验证到底是不是设备没响应往往需要在串口侧也放一个监听设备。这一点在做方案的时候要先想清楚。1.2 抓包位置决定了你能看到多少信息抓包位置的选择直接决定了你看到的是“真相”还是“局部真相”。Modbus TCP 的角色关系其实很明确发起请求的一方是客户端通常是上位机组态软件、PLC 的通信模块、或者某个数据采集器接收请求的一方是服务器通常是网关、仪表、变频器、电表这类设备。在 Wireshark 里往往是从“客户端侧”或者“交换机镜像口”去抓。如果你把抓包工具挂在服务器那台设备的网卡上同样也能抓全但看不到客户端回放过来的重传。实际现场最常见的部署方式是这样的上位机和几十台电表挂在同一个工业交换机里电表大多天生自带 Modbus TCP 支持。这时候你只要把 Wireshark 跑在上位机这台电脑上就能看到它和所有设备之间的完整请求和响应。但如果是那种 PLC 和网关之间点对点直连没有交换机可以镜像那就只能把抓包工具装在其中一端或者在中间串一个分光器/TAP。别想着靠交换机里某个没有镜像功能的普通端口去抓包抓出来大概率只有广播和组播完全没有你要的 Modbus 内容。这里我有一个小建议在计划抓包之前先画一个简单的数据流向图把客户端、服务器、中间节点标出来。不用画得多复杂纸上几条线就够。想清楚“数据一定会经过哪里”再决定把网口插到哪台设备上比打开 Wireshark 瞎点要高效太多。2. 抓包前这些准备不做后面全是坑2.1 接口和镜像口别抓了半小时才发现网卡选错Wireshark 主界面列表里通常有好几个接口有些笔记本会有虚拟网卡、远程抓包专用网卡选错了录下来的文件就全是无关流量。最稳妥的办法是在开始抓包前先用 ipconfigWindows或者 ip addrLinux查一下本机网卡的 IP 和名称然后在 Wireshark 的捕获接口列表里选对应的那一个。如果是通过交换机镜像口抓包需要注意一个问题镜像口在多数工业交换机上默认只镜像入方向或者出方向某一个方向不同厂商的行为不一致。如果你的交换机支持“both”务必选 both否则你有可能看到的只是从被镜像端口出去的包回程的响应完全看不见。抓的时候如果发现大量请求没有响应先别着急判断设备故障先检查镜像方向是不是丢了往返半边。还有一点使用普通办公用 USB 网卡和工业网卡抓包性能差别其实很大。工业现场流量本身不大Modbus TCP 一般也就每秒几十到几百个包普通百兆网卡足够但如果现场总线风暴灌进来几千个包普通网卡的驱动缓冲可能就溢出抓包本身丢包Wireshark 下端看起来就会大量乱序重排。条件允许的话抓包机尽量用千兆网卡、CPU 强一点的电脑抓包文件存入本地 SSD能少很多误判。2.2 捕获过滤器相当于“进站安检”要把杂讯提前挡掉捕获过滤器和显示过滤器是两回事很多刚开始用的朋友把它们混在一起。捕获过滤器是在数据包进入 Wireshark 之前用 BPF 语法做前置过滤也就是说数据包根本不会被录进内存或硬盘。显示过滤器则是在已经录到的所有包里做筛选类似于数据库里的查询条件。对 Modbus 排查来说建议两层都用。捕获过滤最常用的是这条tcp port 502如果你的排查范围只针对某一台设备比如现场有几十台电表只想看其中一个网关和上位机的通信可以加上目标主机tcp port 502 and host 192.168.1.50有些上位机和 PLC 之间还会用自定义的端口承载 Modbus不一定都用 502。这时候可以先不管端口用modbus显示过滤器把能识别的 Modbus 包挑出来再看它们实际跑在哪个端口上然后再回去改捕获过滤器。这里有一个关键点工业抓包要防止文件太大。Modbus 本身数据量小但如果正好碰上设备在反复重连、广播风暴、或者网络里跑着其他大流量业务录一个 1GB 的 pcapng 文件也就是几分钟的事。为了不让现场排查变成“等文件加载半小时”捕获过滤器必须记得设上。2.3 显示过滤器先看想确认的东西再慢慢看全貌捕获过滤器挡掉的杂讯已经省了不少空间到了显示过滤器这一层就是你真正“分析”的时候。几个我几乎每次都会用到的过滤条件modbus把所有被识别为 Modbus 的包全部显示最适合先扫一眼整体规模。modbus tcp.stream eq 0只看 TCP 会话里编号为 0 的那一路流量适合排查单一连接。modbus.func_code 3只看读保持寄存器功能码 3的请求和响应。modbus.func_code 6只看写单个寄存器功能码 6。modbus.exception_code 1把所有带异常码的响应包挑出来这是排查设备报错时最关键的过滤器。modbus.func_code 5 modbus.func_code 0x10把写线圈和写寄存器相关的功能码全部筛选出来适合检查现场有没有异常的写操作。实际排查的时候我一般会先用modbus.exception_code 1把异常包都拎出来数量和内容一目了然。如果异常包里刚好有你要找的那台设备的响应那基本上就是功能码执行失败如果没有异常但数据就是不对那问题更多在数据定义和字节序这一层。Wireshark 的“解码为”功能也要记住如果项目里不是标准 502 端口而是某个自定义端口比如上位机软件用了 5008你抓到的包就不会被自动反汇编成 Modbus。这时候可以右键任意一个 TCP 包选择“协议首选项 - 解码为”在目标端口那一行把 TCP 端口 5008 强制解码为modbus。这个操作在很多异形实现的上位机环境里几乎是必用的。3. 会看报文结构你才真正开始懂 Modbus3.1 MBAP 头模板化的七个字段不管请求还是响应一个完整的 Modbus TCP 报文在 Wireshark 里都会展开成多层结构。最外层是 Ethernet如果走了以太网、IP、TCP然后 Wireshark 把 TCP 载荷归成 Modbus/TCP 协议树。这个协议树里最重要的就是 MBAP 报文头。MBAP 的七个字节是核心Wireshark 会拆成这几个字段字段长度示例值含义事务标识 Transaction ID2 字节0x002A请求和响应用同一个 ID 配对。上位机每发一个请求会生成一个序号从站响应时原样带回来协议标识 Protocol ID2 字节0x00000 代表 Modbus。如果不是 0说明这个包不是标准的 Modbus 数据长度 Length2 字节0x0006后续还有多少个字节包括单元标识、功能码和数据区。长度是动态变化的单元标识 Unit ID1 字节0x01相当于串行链路上的从站地址。一个 Modbus TCP 服务端口后面如果挂了多台串行设备靠这个字节区分拿到一个请求报文我习惯先把 MBAP 这四个字段读完尤其是事务标识和长度。事务标识能告诉你这是哪个请求长度能判断响应有没有被截断。协议标识几乎永远是 0一旦看到非 0那就要警惕可能是封装方式不对或者包被篡改。单元标识对应现场的设备地址有些项目的组态里没有正确配置站号就会出现上位机向单元标识 0 发起请求但从站地址是 3那响应就永远不对。3.2 功能码速查表和异常码速查表MBAP 之后是功能码它是 Modbus 报文的“动词”告诉从站你到底想干什么。工控里常用的功能码并不多但必须能一眼认出来功能码十进制名称作用数据长度特征1读线圈读取位输出状态返回按位打包2读离散输入读取位输入状态返回按位打包3读保持寄存器读取可读写的 16 位寄存器值返回 2 字节乘以寄存器数量4读输入寄存器读取只读的 16 位寄存器值返回 2 字节乘以寄存器数量5写单个线圈写一个位输出数据区固定两个字节6写单个寄存器写一个 16 位寄存器数据区固定两个字节15写多个线圈批量写位输出数据区包括字节长度16写多个寄存器批量写寄存器数据区包括字节长度如果响应里有异常从站会把它收到的功能码最高位改成 1。举例你发了功能码 3 读保持寄存器正常情况下响应功能码还是 3如果从站认为这个请求不合法会返回功能码 0x83同时带一个异常码。这时 Wireshark 会高亮显示异常并在 Expert Info 里生成一条提示。异常码的含义是必须背下来的异常码含义常见的现场原因1非法功能从站固件不支持这个功能码比如老设备不支持功能码 162非法数据地址请求的起始地址或寄存器数量越过设备允许的范围3非法数据值数据区里的值超出了从站允许的范围4从站设备故障从站内部异常可能是硬件或软件故障6从站忙从站正在处理其他事务无法响应11网关目标设备无响应网关收到了请求但后面的串行设备没回应有朋友问我“Wireshark 里能直接看到中文说明吗” Wireshark 本身会显示异常码的数字你需要对照表。用熟练之后看到 0x02 立刻会想“这个地址越界了”看到 0x01 就想“功能码不支持”这种条件反射就是效率。3.3 地址偏移问题40001 到 0x0000 的弯弯绕地址问题是我见过最容易让人一头雾水的部分。Modbus 寄存器地址在 OEM 手册和组态软件里常常写成 40001、30001、00001 这种“五位数字”的旧式符号。其中 4 开头表示保持寄存器对应功能码 3/6/163 开头表示输入寄存器对应功能码 41 开头是离散输入对应功能码 20 开头是线圈对应功能码 1/5/15。在报文里从站地址不是 40001 这个完整数字而是 0x0000 부터 0xFFFF 的十六进制偏移地址。以最常见的保持寄存器为例组态里写 40001对应报文起始地址 0x0000组态里写 40011对应报文地址 0x000A。如果厂家人给你一个寄存器表直接写“寄存器地址 21”你必须先搞清楚它指的是组态地址 40201还是偏移地址 0x0015两个表达可能差出 200 个寄存器。不少排查最后查出来的结论其实就是这个偏移算错了。上位机按 0x0000 读设备按 40001 的另一套映射响应两边看着都有理但数值根本对不上。遇到这种情况最好的验证办法是先用 Wireshark 看请求里的起始地址再拿厂家文档里给的寄存器表换算一遍看看人写的和报文里跑的到底差多少。3.4 一个典型的“读保持寄存器”全过程假设上位机要读网关后挂的一台设备报文可能长这样请求十六进制00 2A 00 00 00 06 01 03 00 0B 00 32拆开看段值含义00 2A0x002A事务标识00 000x0000协议标识00 066后续字节数010x01单元标识033功能码读保持寄存器00 0B0x000B起始寄存器地址 1100 320x0032读 50 个寄存器响应十六进制00 2A 00 00 00 6A 01 03 64 100 字节数据响应里事务标识 0x002A 和请求一模一样你可以用这个字段在 Wireshark 里快速把同一个事务的请求和响应配对。长度 0x006A 换算成十进制是 106包含 1 字节单元标识、1 字节功能码、1 字节字节计数、100 字节数据以及 3 不106 是010364 100 字节数据这里03是功能码64表示有 100 个字节后面跟 100 字节所以 010364100106不对010364100 3 0x64 100 3 100 100 203我需要小心。Modbus TCP 长度字段表示 PDU单元标识功能码数据的长度。对于该响应长度0x006A106 十进制。组成部分单元 ID(1)功能码(1)字节数(1)数据(100)103。这不匹配。所以让我显示正确的内容。正确的响应例子 请求读 10 个寄存器00 2A 00 00 00 06 01 03 00 0B 00 0A长度 0x0006 是正确的unit function data 116 6。 响应00 2A 00 00 00 17 01 03 14 [20 bytes]长度 0x0017 23 1 1 1 20 23。正确20 字节来自 10 个寄存器 * 2。我将在文本中修复这个问题。好。4. 四个真实故障场景抓包复盘比理论更提神4.1 场景一轮询突然变慢数据刷新像“挤牙膏”某水处理项目上位机要周期读取 20 台仪表的状态正常情况下每 10 秒刷新一轮没什么问题。突然开始闪断画面上的数据要么停留在旧值要么刷新出来已经是 30 秒之前的值。抓包结果看一下 Time 列就发现问题每一个读请求发出去之后响应要 2 到 6 秒才回来而且响应里的 TCP 包基本没有重传就是纯粹慢。继续看事务标识发现上位机并发发了 20 个读请求但每一台仪表都只是在挨个处理也就是说设备后面串了一个轮询队列。后来到现场确认是因为上位机改成多线程并发访问而那个网关是低端的串口转以太网模块它内部同时只支持一个 RTU 事务。如果并发 20 条请求进来后面的请求就全部排队每个请求都要等前面十几台设备轮完整体延迟立刻上来。这种问题只看 PLC 或者上位机的报警日志根本定位不了因为协议栈认为没有出错只是慢。Wireshark 里把请求和响应的时间差一算结论就蹦出来了。处理办法也很简单上位机那边改成串行轮询或者把并发数降下来问题马上消失。4.2 场景二写操作被拒绝返回异常码 2另一个场景现场工程师在中控室用组态软件往某个阀门控制器写报警阈值写不进去。组态软件界面只提示“写入失败”。Wireshark 打开发生故障的那个时间窗一条请求是功能码 6写单个保持寄存器起始地址0x03E7对应地址 40008数据值0x00C8。紧接着的响应功能码变成了0x86异常码 2。异常码 2 说明数据地址非法。但工程师不理解明明组态软件上能看到“40008”这个地址为什么从站说非法。后来查设备手册才发现这台阀门控制器的保持寄存器范围只到 40007所谓的 40008 是个只能在扩展模块安装后才能激活的映射地址。因为扩展模块没装固件就把这个地址视为越界。这个案例想说明的是异常码是很好的方向提示但不能代替你读设备手册。看到异常码 2第一反应应该去核对地址范围和设备型号而不是直接怀疑线缆和波特率。很多项目卡了好几天就是因为顶部软件显示“失败”但没人愿意开 Wireshark 看看具体返回什么异常码。4.3 场景三间歇性离线包偶尔丢失还有个更挠头的场景网关和设备之间通信时不时断开上位机提示连接丢失自己又恢复一天要好几次。抓包后发现断开的时间点全部集中在一个特征上TCP SYN 重传。上位机发 SYN 给网关的 502 端口网关不回 SYN-ACK上位机认为连接建立失败重试三次之后直接判定离线。等了一段不确定的时间网关恢复了连接又建上了。这个现象让我一开始也误判成网关 CPU 死机或者电源不稳。但仔细看 SYN 重传的间隔又非常规律都是 1s、3s、6s 这种指数退避说明是主动发起方在试探。后来沿链路走了一遍发现网关上联的是一台比较老的工业级交换机它的某个端口在单播流量打满时触发了保护机制把端口暂时阻塞了。也就是说不是设备不响应是网络中间层丢了包。在排查中我总结出一个规律如果 Wireshark 里看到大量 SYN 重传先别怀疑应用层协议优先查物理链路、交换机端口协商、镜像口配置这些基础。只要 SYN 都没到网关后面 Modbus 再合理的实现也白搭。4.4 场景四数值“颠倒了”但功能码完全正常曾经有人在抓包里看到一个寄存器返回的数据值是0x3412但现场仪表显示的值应该是0x1234。从协议层面看请求正常、响应正常、异常码为空CRC 或者 TCP 校验也都正确什么都不报错。这就是典型的大小端问题。Modbus 协议本身明确规定寄存器数据采用大端序也就是高字节在前低字节在后。但实际设备五花八门有些仪表厂为了和自家的老协议统一在寄存器内部是按小端模式填充的或者把 32 位浮点数拆成两个寄存器的时候字序反了。上位机读到之后直接用不转换就会出现这种“数值完全对不上”的现象。抓包对这个问题的价值在于它能帮你确认交换到底发生在哪个层面。如果报文里原始字节就是0x3412而仪表串口终端显示的也是0x3412说明转换要放在上位机侧如果仪表显示0x1234报文里是0x3412那就要查仪表配置是不是大小端设置错了。总之先看到原始字节再谈转换规则这个顺序千万不能反过来。5. Wireshark 里那些常被忽略的统计功能很适合处理 Modbus5.1 IO Graph把延迟波动画成曲线Wireshark 的主窗口你在逐条看报文人脑对时间跨度不敏感。建议用 统计 - IO Graph 功能。先建一个过滤器显示所有功能码为 3 的请求modbus.func_code 3用同样的办法加一条响应过滤modbus.func_code 3 tcp.analysis.ack_rtt然后设置 Y 轴为“计数”X 轴时间内选合适的粒度。如果某些时间点请求和响应的计数出现“突然拉高”或“长期锯齿”那个区域就是问题高发时区。对比“请求数”和“响应数”的峰形可以快速判断到底是请求侧压力大还是响应侧吞吐低。IO Graph 对定位“周期性卡顿”特别有效。有些 Modbus 网络定时故障比如每小时的后半段丢包人眼看报文要翻几百行IO Graph 曲线里只要有一个周期性的周期性尖峰立马就能看出规律。你甚至可以直接点图上某个区间Wireshark 会自动跳到对应的数据包列表配合时间过滤进一步深入。5.2 专家信息帮你把“可疑点”集中列出来菜单 统计 - 专家信息 会把 Wireshark 分析器认为值得注意的事件集中展示。Modbus 异常响应会被标记为 ErrorTCP 重传、乱序、重复 ACK 会标记为 Note少数情况还会有 Warning。我的习惯是打开专家信息窗口之后第一眼看 Error 级别的条目第二眼看 WarningNote 级别先忽略。工控系统本身会有少量 TCP 层面的噪声如果一上来就盯着几百条 Note 看容易把自己绕进去。如果专家信息里出现大量 Modbus 异常可以直接点条目跳到对应包再从那个位置进入报文展开树逐层看。这个方法比手动搜索快得多几乎就是 Wireshark 的“病历首页”。5.3 用 tshark 命令行批量筛选大文件也不怕图形界面处理几万包还行超过几十万包就会开始卡。这时候 tshark 才是最终武器。比如我要从一个 500MB 的抓包文件里把所有功能码 3 的请求事务标识和起始地址导出来只要一条命令tshark -r modbus_large.pcapng -Y modbus.func_code 3 -T fields \ -e frame.number -e modbus.transaction_id -e modbus.starting_address \ -e modbus.quantity_of_registers输出就是表格化的字段列表可以直接复制到 Excel 里做统计分析比如统计同一时间段内哪个从站响应最慢哪个寄存器被访问最频繁。如果要统计哪些设备产生了最多异常响应可以配合 uniq 工具把单元标识和异常码统计排序tshark -r modbus_large.pcapng -Y modbus.exception_code -T fields \ -e modbus.unit_id -e modbus.exception_code | sort | uniq -c | sort -rn这个操作批量看一眼你能快速判断是全场都在报错还是只有某一台设备在捣乱。6. 我做 Modbus 抓包这些年踩过的几个坑6.1 抓包位置不对会把“请求发出去了”误判为“根本没请求”有过一次印象很深的经历排查一台光伏逆变器的通信故障用 Wireshark 在上位机侧抓包看到的全是上位机发的请求响应一个都没有。当时差点判中型号不对、协议没配置好。后来在逆变器侧再加了一台抓包机才发现上位机的请求确实送到了但逆变器每次回包都被交换机丢掉了。问题的根源就出在那台工业交换机的下行口和逆变器网口之间存在大量 CRC 错帧链路层质量差到一个级别应用层一点办法都没有。经过这事之后我对“抓包位置”这个事的重视程度就完全不同了。只要条件允许我至少会在两处抓客户端侧一包服务端侧一包。两个文件一对比包到哪里断的立刻清楚。如果只能一个位置那我优先选靠近“嫌疑最大的设备”那侧而不是靠近自己电脑那侧。6.2 看到 TCP 重传就赖设备不行这是最容易翻车的判断Wireshark 里只要出现 TCP Retransmission 字样很多人的第一反应就是“网络质量太差”。但实际上在 Modbus 这种小报文短连接场景里偶尔几个重传是正常现象。TCP 重传的原因可以是设备 CPU 忙、串口侧慢、链路误码甚至只是上位机多线程并发请求把自己发送缓冲堵了。如果你只看重传标签就下结论很容易把矛头指向最无辜的那台设备。我现在看到重传会先查重传发生在哪个 TCP 流上以及重传的 payload 是不是同一个 Seq 号。如果重传的都是同一个请求就继续看对端有没有回应过如果对端回应了但响应很慢那大概率是应用层处理速度问题。要得出稳妥结论应该结合 Modbus 异常码、IO Graph 曲线和现场设备的运行日志而不是孤立地揪着一个 TCP 行为不放。6.3 抓包录太久结果文件巨到打不开有朋友就干过这事把抓包挂在现场连上三天回来文件有 8GB加载半天打不开想找什么都很痛苦。正确做法是分段保存而且要提前根据现场流量估大小。比如一个 502 端口流量估计每小时 100MB那就在捕获选项里设置“多文件模式”每个文件 100MB 轮换保留最近 20 个文件。这样做还有个好处你可以在文件上直接标注时间区间比尔现场排查只需要某一段的文件就单独导入那个文件不用再把整个包翻一遍。6.4 现场排查时别光顾着看数据忘了看时间线最后算一个经验性的提醒Wireshark 默认时间显示格式是“相对时间 0.000”也就是从抓包开始计时。如果你抓了两个小时想找“到底哪一刻开始出问题的”建议把时间显示格式改成“绝对日期时间”快捷键是 CtrlAltShiftT 之后选 UTC 或本地时间。这样配合现场中控室的报警日志可以直接对齐“上位机报故障”和“网络断链”是不是同一个时刻省一大堆来回核对的口舌。我个人在实际操作中其实已经很依赖一个习惯每到一个现场第一件事不是翻设备配置而是先抓一分钟的 502 端口流量保存成基线文件。等故障发生了再抓一份故障时段文件。两次一对比哪里变化大可疑点就浮出来了。这个习惯帮我少走了很多弯路也让“抓包”这个动作从被动救火变成了主动免疫。如果你日常也会和 Modbus 设备打交道我建议你也把这个方法纳入自己的排查流程里。
阅读完成 · 觉得有帮助？
