1. 排查丢包的第一步先分清故障到底在哪一层先讲一个我前阵子遇到的现场。某工厂的设备数据采集项目网关装在配电柜里每隔两三个小时就断一次远程ping网关的IP地址丢包率在20%到40%之间来回跳。现场同事第一反应是换交换机、换网线折腾了一天没好转。我到了现场做的第一件事不是去查网络而是让同事在网关的串口命令行里执行一条最简单的命令ping本机回环地址也就是ping 127.0.0.1。结果很有意思。ping回环地址居然也有接近10%的丢包而且延迟忽高忽低偶尔还出现timeout。这里要先给不太熟悉网络的朋友解释一下回环地址是设备自己跟自己通信数据包根本不经过网口、不经过网线、不经过交换机纯粹是CPU、协议栈、操作系统和内存之间的内部循环。所以“交换机ping回环地址丢包”这个现象在网络运维圈里通常意味着设备本身已经“不健康”了——要么CPU负载过高导致ICMP处理被延后要么内存缓冲区不足导致包被丢弃要么网卡驱动的中断被频繁打断要么电源纹波太大导致芯片工作不稳定。这个案例最终定位到的根因说出来大家可能觉得不可思议网关内部的DC-DC电源模块在高温环境下输出纹波超标导致Wi-Fi模块和以太网PHY芯片间歇性工作异常。也就是说根本不是“网络选型”的问题而是设备供电和散热的问题。但这件事给了我一个特别大的启发排查丢包断联一定不要一上来就查链路先把故障分层每一层单独验证才能快速锁定真正的原因。1.1 回环地址丢包说明设备自身就不健康很多工程师包括我自己早期遇到丢包第一反应就是查交换机配置、查网线通断、查光模块收发光功率。但“交换机ping回环地址丢包”这个现象反而能帮我们快速区分问题的责任方。如果交换机本身ping回环都不稳那问题大概率在设备自身或者供电环境跟“网络”没关系。如果回环稳定、ping网关也稳定再去查上游链路才有意义。这个逻辑放在物联网网关的场景里同样适用。网关比交换机更复杂它里面有CPU、内存、4G模组、Wi-Fi模组、串口芯片、电源管理芯片任何一个部分状态异常都会表现出“丢包、断联”的假象。我碰到过不少项目客户一口咬定是“网不好”结果我让他在网关本地跑一个回环测试脚本丢包率惨不忍睹。再一看网关被塞在不通风的机柜角落里外壳温度摸上去烫手打开后台一看温度传感器显示79度。这种环境下芯片的时序和射频性能都会劣化丢包是必然的。所以我的习惯是任何丢包故障第一件事永远是先排除设备自身问题。具体操作分为几步。先看CPU负载和内存占用如果load average持续高于2.0或者内存使用率长期超过90%先解决资源瓶颈再看网络问题。再看温度工业级网关的工作温度范围一般是-40℃到85℃但实际运行中超过65℃就要警惕因为射频前端和电源部分会先开始不稳定。再看电源用万用表在网关电源输入端量一下电压波动如果是开关电源纹波太大或者电压跌落明显先换电源试。最后才是ping回环地址连续ping几十次如果回环都丢包说明设备基础状态有问题后面的网络排查暂时都不用做。1.2 分层排查回环、网关、外网三段定位法这里我直接给出一套我自己在用的三段定位法大家以后遇到物联网网关丢包断联可以照这个顺序来第一段ping设备回环地址127.0.0.1。这一步验证的是设备自身的协议栈和CPU是否正常。丢了先查设备负载、温度、电源、驱动不要动网络配置。通了进入第二段。第二段ping网关的内网IP地址或者直连设备的有线网口IP。这一步验证的是物理链路、交换芯片、网线、协商速率。如果这一段丢包就要查网线是不是劣质线、水晶头工艺是不是有问题、网口协商速率是不是发生了跳变、端口是否在半双工状态。顺便说一句很多“丢包”其实是网线质量问题。标准超五类网线在100米内跑百兆没问题但工业现场很多工程队用的网线是“铜包铝”的或者水晶头压接没到位长时间振动后接触不良丢包率就上来了。第三段从网关ping公网地址或者云平台的域名IP。这一段丢包才轮到查运营商的链路质量、带宽拥塞、DNS解析、防火墙策略。不过这一步要特别注意区分“丢包”和“延迟抖动”。很多人在网关ping外部地址看到偶尔的timeout就认为是丢包实际上可能是云平台安全策略主动丢弃了ICMP报文而真正的业务数据走TCP/UDP反而正常。所以判断链路质量不能只看ping一定要配合业务的真实流量来看比如MQTT的QoS 1报文确认是否正常。把这三段跑完基本就能把责任方锁定在一个很小的范围内。这时回头看标题里的问题——为什么物联网网关总是丢包、断联有一半以上的项目根子都是出在“选错了联网方式”而不是“网络本身不行”。这个我们下一章展开讲。2. 物联网网关联网方式选型为什么大多数人会选错需要先给“联网方式”做一个准确的范围界定。物联网网关和传感器设备不一样传感器接传感器网关负责向上回传数据到服务器平台所以这里说的联网方式指的是网关到服务器链路这一段的上行链路选型而不是传感器和网关之间的短距离通信。常见的选择无非四类有线以太网、Wi-Fi、4G/5G蜂窝网络以及少部分场景里用到的低功耗广域网如LoRa网关上行到基站。选型看起来简单实际坑特别多。我见过太多项目是“拍脑袋”选型公司技术负责人说Wi-Fi方便于是所有设备全上Wi-Fi或者客户现场有网口就直接拉网线又或者觉得移动网络覆盖好直接上4G模块。最后上线了才发现丢包、断联、延迟抖动全来了。选错的原因本质上是同一个大家只看“能不能连上”没看“长期在恶劣环境下能不能稳定连上”。2.1 四种主流联网方式的能力边界先看一张对比表我的习惯是把这个表打印出来贴在办公桌上每次给项目选型前先过一遍。联网方式典型场景优势最容易踩的坑有线以太网固定机柜、工厂车间、园区机房稳定、低延迟、不受无线电干扰网线质量差、水晶头氧化、长距离走线衰减、地电位差Wi-Fi办公区、仓库、短期部署部署灵活、免布线、成本低同频干扰严重、信号穿墙衰减大、AP漫游断流、金属环境屏蔽4G/5G蜂窝户外、移动设备、偏远站点覆盖范围广、无需物理线路信号强度虚高、基站拥塞、运营商NAT会话超时、套餐限速LoRa/NB-IoT等传感器数量大的低速率场景低功耗、单站覆盖广上行带宽极小不适用于网关大量数据回传仅适合传感器侧从这张表能看出一个问题没有一种联网方式是“万能”的。有线最稳定但受限于布线Wi-Fi最方便但受限于射频环境蜂窝网络看似哪里都能用但实际体验极其依耐运营商网络质量。当我看到很多项目因为图省事选了Wi-Fi结果现场是金属货架密布的仓库时心里就有数了——这个项目从选型那一刻起就注定会丢包。另一个容易被忽视的是“名义速率”和“实际可靠速率”的区别。比如有的Wi-Fi网关标称速率300Mbps看着很高但在2.4G频段下信道干扰严重时实际有效吞吐率能掉到10Mbps以下如果同时还有多台设备竞争信道单个网关的上行质量会更差。同样4G模块标称下行100Mbps但在弱信号区域MCS调度降级后实际速率可能只有几十kbps。所以选型一定要参考“最差场景下的最低保障速率”而不是理想状态下的峰值速率。2.2 选型判断的两个核心原则我在实际项目里总结了两个选型原则适用性很强。第一个原则是先确认可靠性边界再谈速率和成本。意思是先搞清楚这个项目允许的最大丢包率和最大断链时间。比如做工业设备状态监测允许丢包率可能在1%以内断链后要求10秒内自动重连。但如果做AGV调度或者产线联动控制丢包率最好低于0.1%断链恢复时间尽可能短。把这两个数字定下来之后再倒推应该选什么联网方式。否则你连“能不能接受断联”这个问题都没想清楚选型自然跑偏。第二个原则是能用有线就不用无线必须在无线里选时优先选可控性更高的方式。有线以太网可以自己做工程质量管理网线不行就换、距离不行就加工业交换机这些都有成熟的工程手段。Wi-Fi受外界干扰影响大你控制不了隔壁工厂的AP信道怎么配置控制不了现场什么时候多了一台微波炉。蜂窝网络同理你控制不了基站的负载和运营商的核心网调优。所以“可控性”这个维度非常关键。不是说无线不能用而是说无线环境的不确定性天然就高选型时要留出更多的余量。3. 明明选了Wi-Fi为什么现场还是疯狂丢包Wi-Fi是物联网网关丢包断联的重灾区。我接触的项目里十个出问题的网关有六七个都是Wi-Fi连接。不是说Wi-Fi不能用而是很多人低估了Wi-Fi在工业现场环境的脆弱程度。这一章我把Wi-Fi相关的坑掰开揉碎讲清楚。3.1 2.4G频段的物理困境先说一个最根本的问题2.4G频段本身就是一个“拥挤且容易受干扰”的频段。Wi-Fi、蓝牙、ZigBee、微波炉、无线鼠标甚至部分工业设备都工作在2.4G频段。Wi-Fi在2.4G下只有1、6、11三个互不重叠的信道在工厂或者办公楼里这些信道上可能挤了十几个AP大家都在抢空气里的无线资源。Wi-Fi的介质访问机制是CSMA/CA通俗说就是“先听再讲”。每个设备发数据前都要先侦听信道发现信道忙就随机退避一段时间再试。设备越多冲突概率越高重传就越多。这个机制在AP数量少的环境下没问题但在密集部署的工业现场网关发送的每一帧数据都要跟周围几十台设备竞争丢包和延迟都是这么来的。更麻烦的是干扰是动态的。隔壁车间可能白天开着一台大功率设备晚上关掉了你的网络质量随之起伏。这种“时好时坏”的状态最让人头疼。另外2.4G频段的物理特性决定了它穿墙能力尚可但遇到金属几乎是天敌。金属货架、金属机柜、传送带框架哪怕是不锈钢门都会对2.4G信号形成强反射和吸收。我做过一个仓储存取系统的项目网关安装在货架顶部的设备箱里周围全是金属货架Wi-Fi信号从远处的AP传过来经过多径反射后衰减极其严重RSSI在-80dBm附近徘徊丢包率自然居高不下。3.2 天线、机柜与漫游细节除了频段本身的问题工程细节上的坑也特别多。天线就是重灾区。很多物联网网关为了外观好看把天线内置了而且是PCB天线增益往往只有0dBi左右。如果网关再安装在金属机柜内部金属外壳对无线信号有屏蔽效果内置天线等于被关在牢笼里。我之前测过一个项目网关在一个14U的机柜里Wi-Fi天线内置机柜门一关旁边2米外的AP信号强度从-50dBm跌到-75dBm丢包率直接翻倍。解决办法看起来很简单用外置天线把天线引到机柜外面。但很多工程团队压根没想到这一点。漫游问题也很要命。工厂或者园区往往部署了多个AP网关从一个AP的信号覆盖范围走到另一个AP的范围时终端需要完成一次重新认证和关联这个过程叫漫游。如果AP的漫游阈值设置不合理或者网关的Wi-Fi驱动在漫游时切换不及时就会出现短暂的断流表现就是ping丢包、MQTT掉线。另外如果AP之间没有配置相同的SSID和加密方式网关漫游时会直接断开重连这个过程的耗时大概率超过10秒对于心跳周期只有5秒的网关来说就意味着一次掉线告警。3.3 DHCP与省电模式的隐性断联还有一个很多人查不到的坑DHCP租约。网关通过Wi-Fi接入网络时通常由路由器分配一个IP地址这个分配是有时间限制的叫租约期默认通常是24小时也可能更短。网关拿到IP地址后如果它的心跳周期或者业务通道不频繁它可能不会在租约到期前及时续约。一旦租约到期路由器把IP收回网关还在用旧IP通信结果就是断联。这个问题的隐蔽性在于看起来Wi-Fi信号满格链路状态正常但数据就是出不去。我在一个智慧楼宇项目里就遇到过这个情况。几十个网关连接同一个路由器每隔一段时间就有一批网关集体掉线。查了一圈最后发现是路由器默认DHCP租约时间设置太短只有12小时而网关的MQTT心跳是5分钟一次理论上应该会触发续约但网关的DHCP客户端实现有bug只在重启时续约一次。最后我们把路由器租约改成7天再在网关里加了定时重启脚本问题才算解决。另外一个隐性问题是Wi-Fi省电模式。Wi-Fi模块为了降低功耗默认可能开启省电模式网卡在空闲时会自动进入休眠状态。休眠状态下AP要先把数据缓存住等网卡醒来再取。如果网卡的休眠周期和AP的缓存机制之间配合不好数据包就会显著延迟表现就是“ping忽快忽慢”“偶发性丢包”。在做物联网网关的时候如果设备是外部供电而不是电池供电务必在驱动层关掉Wi-Fi的省电模式换来的是更稳定的延迟表现。4. 蜂窝网络“信号满格”却总是掉线问题藏在哪很多人觉得Wi-Fi靠不住干脆上4G/5G蜂窝网络心想运营商基站覆盖肯定没问题。实际上蜂窝网络用在物联网网关上有另一套完全不同的坑而且这些问题比Wi-Fi更隐蔽因为“信号满格”的假象特别容易误导人。4.1 信号强度和信号质量是两回事手机或者网关的状态栏显示“满格信号”很多人就认为网络没问题。这里需要澄清一个概念信号格数通常只反映参考信号接收功率RSRP的大小但它完全不能反映信号质量比如信噪比SINR如何。就好比你在嘈杂的餐厅里手机显示信号满格但是旁边有好多人在同时讲话你能听到对方的每一个字吗听不清楚吧信号满格但干扰大通信一样会失败。我遇到过这样的场景工厂楼顶的网关显示RSRP为-75dBm这个数值在移动通信里算良好水平但SINR只有-2dB也就是说噪声比信号还要强一点。结果就是MCS调度等级被基站压得很低数据速率骤降加上重传率高网关看起来一直在线但数据要么迟到要么丢失。这个问题的根源可能是网关附近有工业设备产生强电磁干扰也可能是基站侧拥塞。解决办法不是换SIM卡而是先通过AT指令查询模组的RSRP、SINR、CQI、PCI等指标确认信号质量真的达标再做后续处理。网关自带的指示灯通常只显示注册状态不显示信号质量所以很多问题被藏住了。我习惯的做法是在网关里写一个脚本定时通过串口AT指令查询信号质量并打日志。这样出了问题才能看到是“信号强度不足”还是“信号质量差”而不至于靠猜。4.2 模块等级、天线布线与SIM卡隐性因素蜂窝网络丢包断联还有一个常被忽略的因素模组本身的质量差异。市面上4G模组价格差异很大有些网关为了压成本用的是低成本的消费级模组甚至二手模组稳定性跟工业级模组完全不是一个量级。工业级模组在长时间工作下的温漂更小抗电磁干扰能力更强功耗管理也更好。我之前拆过一个频繁断线的网关打开一看里面的4G模组型号是某手机拆机料供应商把库存货清给了设备厂商。这种模组的射频性能和可靠性都得不到保障丢包断联几乎是必然的。天线工程同样不容忽视。网关的4G天线如果用的是劣质馈线长度超过3米或者SMA接头没有拧到位驻波比升高之后信号质量会大打折扣。这种问题在工程现场特别常见因为很多施工人员会把天线馈线用力折弯或者用普通的视频线替代同轴线缆结果射频信号在传输过程中损失惨重。4G天线的安装位置也很关键金属机柜内部、电箱角落都是信号杀手天线一定要尽量外露、远离金属体、垂直朝上并且保持周围有一定的净空。SIM卡这块也有不少隐形坑。首先是套餐问题有的物联网卡是限速卡流量用超过阈值后限速到1Mbps甚至更低高负载下丢包就来了。其次是APN设置部分行业卡要求手动配置专用apn如果不正确设置看起来能注册网络但数据通道丢包严重。最后是卡的接触问题工业现场温度变化大SIM卡座的金属弹片容易氧化接触电阻变大后导致模组间歇性掉卡重启这种故障的表现就跟网络断联很像。4.3 运营商侧的NAT与资源回收机制这个坑是最坑人的因为它发生在运营商网络内部你几乎无法定位。很多物联网卡拿到的是私网IP运营商通过NAT把私网流量转到公网。NAT会话是有超时时间的通常是30秒到5分钟不等。如果网关建立了TCP长连接或者UDP数据流但在超过NAT超时时间内没有数据包经过NAT会话就会被回收。等网关下一次再发数据时原来的映射已经不存在了数据到不了服务器连接断开。这正好解释了一个经典现象网关的心跳周期如果是60秒而运营商NAT超时是30秒那就永远正常。但如果你把心跳改成10分钟一次来省流量连接就必然在超过超时时间后断掉。服务器端看到的就是“网关掉线了”而网关侧看自己模组状态还显示正常。很多工程师不知道这一点在服务器端反复重启、重启防火墙最后才发现是心跳周期和NAT超时时间不匹配。解决思路非常多可以用TCP长连接加服务端主动探测的方式在业务空闲期发链路保活包把NAT会话维持住保活包的间隔必须小于NAT超时时间也可以改用MQTT的QoS 1级别broker和客户端之间的PUBACK/PINGREQ本身就能起到保活作用还有更彻底的办法是申请静态IP或者使用专网APN但成本会高一些。在项目规划阶段就要先问清楚运营商卡的类型和NAT策略把链路保活方案一并设计进去。5. 在联网方式已定的前提下如何把丢包率压下来有不少项目联网方式已经选了被现场环境卡住了换联网方式成本巨大。这种情况下有没有办法把丢包率压下来当然有。这一章讲实战层面能落地的优化手段每一招都是我在现场验证过的按优先级从高到低排列。5.1 网关侧心跳、看门狗与传输协议配置网关侧能做的优化最多见效也最快。第一招是调整链路保活周期。前面已经强调过NAT超时问题。如果用的是蜂窝网络把应用层心跳周期设置为运营商NAT超时的二分之一以下通常设置为30到60秒既能保活又不会太费流量。用TCP长连接的话可以应用层发PING请求也可以调整TCP keepalive参数让内核在空闲期自动发探测包。无论哪种方式核心就一句话让链路在NAT会话超时之前有数据经过。第二招是加“自愈”机制。网关层面的自愈最简单的形式是看门狗脚本。脚本每隔几分钟检查一次网络连通性如果连续多次ping不通或者TCP连接断开就主动重置4G模组或者Wi-Fi网卡让设备重新拨号或重新关联AP。这个机制就像个“傻瓜式开关”成本低、效果好。有条件的话最好再加硬件看门狗防止系统本身卡死。很多网关断联的真正原因是系统盘IO卡住或者进程僵死硬件看门狗能强制重启把设备拉回来。第三招是优化传输协议。数据上报尽量避免用明文UDP裸传因为UDP没有确认机制丢了就是丢了上层不知道。尽量用MQTT并且根据数据重要性选择QoS级别。QoS 0适用于遥测类的非关键数据丢了还能接受QoS 1至少保证broker能收到一次适合设备状态、告警等关键数据。从现场实测来看同样的网络环境下从UDP裸传切换到MQTT QoS 1之后业务侧感知到的“数据丢失”大幅下降因为MQTT的重传机制把物理链路丢包给兜住了。5.2 网络侧信道、功率、漫游阈值调整如果联网方式还是Wi-Fi网络侧的优化空间也很大。信道规划是最基本的一条。在部署之前用无线扫描工具比如手机上的Wi-Fi分析仪或者笔记本上的inSSIDer先扫一遍现场的2.4G和5G信道占用情况选择一个干扰最少的信道固定下来。设备少的话优先用5G频段因为5G信道的数量多、干扰源少、底层速率高。但要注意5G频段穿墙能力比2.4G差不少设备离AP远了信号衰减更快所以5G适合AP和网关距离相对近的场景。AP的发射功率不要开满。这个反直觉但非常重要。在一个多AP覆盖的环境里如果每个AP都开满功率覆盖范围变大重叠区域变多网关会在多个AP之间频繁触发漫游反而导致频繁断流。正确做法是把AP功率调低让每个AP覆盖一个明确的小范围相邻AP之间留出一定的重叠但不要过大。同时把AP的漫游阈值调低一点比如RSSI低于-75dBm时才允许终端漫游避免网关在信号还凑合的时候频繁切换。还有个容易被忽视的细节如果网关是固定安装的完全可以把Wi-Fi模块设置为只连接指定的AP关闭自动扫描和漫游功能。很多网关的Wi-Fi驱动支持“bssid锁定”的功能直接把AP的BSSID写死切换行为就消失了丢包率自然就降下来了。5.3 数据侧降低广播、带宽与并发压力网络基建优化完了还要看业务流量本身。很多物联网网关的丢包其实是带宽被大量无效流量吃掉了或者说网关自己“忙不过来”。先看广播流量。网关所在的局域网里如果有大量的广播包比如ARP请求、NetBIOS广播这些虽然不会瞬间打爆链路但在无线环境下会占用大量的空口资源挤压正常业务数据的发送窗口。解决方法是把网关划分到独立的VLAN里或者使用有线路由代替Wi-Fi路由器减少广播域的规模。再看网关的数据量本身。有些网关在上传数据时习惯“一股脑”把所有数据都推上去比如同时开启视频流、频繁上报全量配置、把调试日志也外传。这种高并发流式数据在弱网环境里很容易引发拥塞表现为丢包和延迟飙升。我的建议是对非实时数据做本地缓存批量上报比如每分钟攒一批数据用一次HTTP POST或者MQTT publish发送而不是每秒钟都发一条小报文。这样做能明显降低空口占用率丢包率也随之下降。最后是并发连接数的问题。有的网关同时维护了多条TCP连接比如一条MQTT、一条HTTP、一条Modbus TCP轮询每条连接都要占资源。弱网环境下并发连接越多某条连接触发重传的概率越大。理想情况是收敛连接数量能合并的通道尽量合并不能合并的也要降低轮询频率给关键业务留出足够的带宽余量。6. 三个真实案例从“反复断联”到“稳定运行”理论讲再多不如看实际案例来得直观。下面三个案例都是我从真实项目中脱敏处理过的但现象、排查过程和最终方案都是原汁原味的希望你能从中看到自己项目的影子。6.1 案例一金属货架仓库里的Wi-Fi噩梦项目背景是一个约5000平米的零配件仓库需要部署20多个网关采集温湿度和环境数据。当时技术负责人图省事选了Wi-Fi方案在仓库天花板上部署了8个AP网关挂在货架立柱上和AP的直线距离大多在10到15米之间。上线第一天就开始丢包ping AP丢包率在15%上下而且仓管员开着电动叉车经过时丢包率还能再跳高一截。排查过程我先让同事在网关本地ping回环地址没丢包说明网关自身没问题。然后ping网关的默认网关AP丢包基本锁定是无线链路的问题。用信号分析工具现场测量发现网关所在的位置虽然能收到AP信号但RSSI在-75dBm到-85dBm之间波动而且多径效应严重。原因是仓库里全是金属货架信号被反复反射后形成衰减和相消。最终方案把联网方式整体切成了4G每个网关插一张工业物联网卡。虽然4G方案月流量费用上去了但丢包率从15%降到了0.1%以下运维电话从一天十几次变成一周都不响一次。这里要特别说一句当时不是没试过改用5G频段的Wi-Fi但金属货架对5G的衰减比2.4G还厉害效果更差。从这以后我就养成一个习惯凡是金属结构密集的室内场景默认先排除Wi-Fi方案。6.2 案例二工厂机柜中的4G“信号满格”假象格栅背景是某化工厂的数据采集项目网关全部装在配电柜里用4G上云单点故障率非常高。现场人员反馈“网卡完全满格但数据时不时中断”重启网关后又恢复正常过一会儿又断。排查过程这个案例最迷惑人的地方就是“信号满格”。我用AT指令查了模组的详细指标RSRP是-70dBm确实很好但SINR只有1dB左右CQI也偏低说明虽然信号强度高但干扰极大。进一步排查发现配电柜内还有变频器、伺服驱动器等大功率设备这些设备的电磁辐射把4G模组接收到的信号质量严重劣化。信号强度高但噪声更高等于你考试时题目都会但周围有一百个人在大声念答案你根本听不清楚自己在写什么。最终方案把4G天线从配电柜内部移出来用磁吸天线安装在配电柜外侧顶部让天线远离变频器同时给4G模组外部加了一层金属屏蔽罩隔绝内部辐射干扰。天线移出来之后SINR从1dB提升到了15dB左右丢包基本消失。这个案例给我的经验是排查蜂窝网络问题千万别只看RSRPSINR、CQI、BLER这些指标缺一不可。而且天线安装位置对工业现场信号质量的影响往往比模组本身还大。6.3 案例三双链路冗余把可用性从95%拉到99.9%第三个案例是一个水厂的数据采集项目水厂有有线工业以太网覆盖但设计院要求高可用不允许断联超过30秒。现场有线和Wi-Fi都有部署但我们最终采用了“有线为主4G备份”的双链路冗余方案。网关选用支持双WAN口的工业网关主链路走有线以太网备份链路走4G。平时业务流量全部走有线链路网关通过链路检测脚本每5秒检查一次主链路连通性。如果连续3次检测失败就自动把流量切换到的4G链路上切换过程对业务层透明。同时4G链路平时一直保持空闲待命状态随时可以接管。这个方案上线后效果非常明显。水厂偶尔会因为电力检修、网络割接导致有线链路瞬断以前这种故障至少要引起一次长达十几分钟的断联现在切换到4G链路后业务几乎没有感知。这个案例说明如果项目对可用性要求高不要纠结于“选哪种联网方式”而是要考虑“怎么组合多种联网方式”冗余设计带来的稳定性提升是指数级的。最后分享一点个人经验做物联网项目这么多年我最大的体会是选联网方式不能只看第一天连得通不通要看它在夏天40度、冬天零下、连续运行半年之后还稳不稳。你在实验室里测Wi-Fi丢包0%看起来完美但拿到金属机柜里、叉车穿梭的仓库里结果可能完全不一样。所以我现在做选型先问三个问题现场环境的电磁干扰严不严重设备位置是否固定业务能不能接受中断、中断多久能接受这三个问题的答案基本就决定了联网方式的大方向。另外就是排查思路“回环通不通、网关通不通、外网通不通”这个三段式排查流程真的能省下大量时间。交换机ping回环地址丢包这种问题我遇到过很多次最后发现要么是电源老化纹波变大要么是设备过热降频。这些和设备联网方式无关的因素往往才是丢包断联的真正元凶。技术问题不怕难怕的是在错误的方向上反复折腾。先把设备和环境的地基打牢再谈网络选型和优化事情就简单了一大半。