企业官网建设流程全解析

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最方便但受限于射频环境；蜂窝网络看似哪里都能用，但实际体验极其依耐运营商网络质量。当我看到很多项目因为图省事选了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左右，丢包基本消失。这个案例给我的经验是：排查蜂窝网络问题，千万别只看RSRP，SINR、CQI、BLER这些指标缺一不可。而且天线安装位置对工业现场信号质量的影响，往往比模组本身还大。

6.3 案例三：双链路冗余，把可用性从95%拉到99.9%

第三个案例是一个水厂的数据采集项目，水厂有有线工业以太网覆盖，但设计院要求高可用，不允许断联超过30秒。现场有线和Wi-Fi都有部署，但我们最终采用了“有线为主+4G备份”的双链路冗余方案。

网关选用支持双WAN口的工业网关，主链路走有线以太网，备份链路走4G。平时业务流量全部走有线链路，网关通过链路检测脚本每5秒检查一次主链路连通性。如果连续3次检测失败，就自动把流量切换到的4G链路上，切换过程对业务层透明。同时，4G链路平时一直保持空闲待命状态，随时可以接管。

这个方案上线后，效果非常明显。水厂偶尔会因为电力检修、网络割接导致有线链路瞬断，以前这种故障至少要引起一次长达十几分钟的断联，现在切换到4G链路后业务几乎没有感知。这个案例说明，如果项目对可用性要求高，不要纠结于“选哪种联网方式”，而是要考虑“怎么组合多种联网方式”，冗余设计带来的稳定性提升，是指数级的。

最后分享一点个人经验

做物联网项目这么多年，我最大的体会是：选联网方式不能只看第一天连得通不通，要看它在夏天40度、冬天零下、连续运行半年之后还稳不稳。你在实验室里测Wi-Fi丢包0%，看起来完美，但拿到金属机柜里、叉车穿梭的仓库里，结果可能完全不一样。所以我现在做选型，先问三个问题：现场环境的电磁干扰严不严重？设备位置是否固定？业务能不能接受中断、中断多久能接受？这三个问题的答案，基本就决定了联网方式的大方向。

另外就是排查思路，“回环通不通、网关通不通、外网通不通”这个三段式排查流程，真的能省下大量时间。交换机ping回环地址丢包这种问题，我遇到过很多次，最后发现要么是电源老化纹波变大，要么是设备过热降频。这些和设备联网方式无关的因素，往往才是丢包断联的真正元凶。技术问题不怕难，怕的是在错误的方向上反复折腾。先把设备和环境的地基打牢，再谈网络选型和优化，事情就简单了一大半。