企业官网建设流程全解析

双协议组合的实战选择：我在厂区设备统一监控里为什么同时用MQTT和SNMP

上个月我们接手了一个老厂区的设备联网改造项目，现场的情况很典型：一侧是刚装好的温湿度传感器、PLC控制器，还有几台支持MQTT的新式电表；另一侧是已经稳定跑了七八年的交换机、防火墙，以及两台光路交换机，全部只支持SNMP。两边都要接入同一个监控平台，统一上报到一个物联网系统里做告警联动。一开始团队里有人提议"干脆都改MQTT"，结果和存量设备一对接就直接卡住了——那些设备根本没有MQTT客户端的能力。最后落地下来，我们的方案是在边缘网关层同时保留SNMP采集通道和MQTT消息通道，让两类协议各干各的擅长事，再在网关内部把数据归一化，形成对外输出的标准模型。这篇文章就把这套组合方案的思路、协议细节、踩坑点和优化措施完整写出来，供做工业物联网、设备运维监控的朋友参考。

先说结论：MQTT和SNMP，单拿出来任何一个都不够用。SNMP在存量网络设备管理上是事实标准，但它的通信模型是轮询加陷阱，拓扑感知能力强，实时主动上报能力弱；MQTT则是消息推送型协议，适合大量设备低功耗、高并发地往平台上灌数据，但对设备侧没有标准的"读取任意MIB变量"这类管理操作。工业环境里新老设备并存是常态，所以真正值得投入时间去设计的，不是二选一，而是双协议如何共处、数据如何合并、指令如何双向流转。这篇文里我会按协议特性、设备接入、网关对接、性能调优、坑点复盘五个部分来讲，全程带具体的报文示例和参数配置，尽量让读者拿过去就能落地。

1. 为什么工业设备管理不能只靠一种协议

1.1 SNMP的存量优势：网络设备管理的"正统语言"

SNMP（简单网络管理协议）从1988年RFC 1065那批文档定型算起，在网络设备管理领域已经有三十多年的历史。几乎所有企业级交换机、路由器、防火墙，包括博科的光路交换机，出厂就自带SNMP Agent，管理员只要配置只读团体名，就能用监控系统把设备的CPU、内存、端口流量、光模块功率全部拉出来。这种"老而弥坚"的地位不是没道理的：SNMP的OID（对象标识符）树本身就是一套完整的设备状态字典，比如1.3.6.1.2.1.1.3.0表示系统运行时间，1.3.6.1.2.1.2.2.1.10表示端口收到的字节数。你不需要让设备厂商开放私有API，只要OID公开，就能拿到数据。

但SNMP的短板也同样明显。第一，它默认的通信方式是Manager主动发GET请求、Agent被动应答，也就是说平台想知道设备出没出事，得自己定时去问，而不是设备主动喊"我出问题了"（虽然TRAP能实现主动告警，但TRAP本身不可靠，UDP包丢了就丢了，也不会重传）。第二，SNMP的报文结构还是ASN.1 BER编码，偏二进制，人类可读性差，调试起来不友好。第三，在大量物联网终端场景下——比如几千个温湿度传感器——如果每个都以SNMP轮询方式接入，监控服务器的轮询压力和网络带宽消耗会非常惊人，每轮全量查询动辄几百毫秒，还会拖慢网管链路。

1.2 MQTT的新生态优势：大量设备低功耗、高并发上报的最佳传输层

MQTT是一个基于发布/订阅模型的轻量级消息协议，设计初衷就是给"带宽有限、设备数量巨大、网络可能断断续续"的物联网场景用的。三个核心角色：Broker（消息代理服务器）、Publisher（发布者）、Subscriber（订阅者）。设备侧只需要建立一条TCP连接，然后往特定的Topic（主题）上发消息，平台侧订阅对应Topic就能收到。消息的发布和接收是异步解耦的，设备状态变化时随时能推，不需要平台反复来问。

MQTT给我感受最深的有三点：一是QoS分级设计，从QoS 0（最多一次）、QoS 1（至少一次）到QoS 2（恰好一次），工程师可以按实际情况选择消息可靠性，不用一刀切；二是保留消息（Retained Message）机制，设备上线后发一条保留消息，新订阅者立即可见，非常适合上报"当前状态"类数据；三是遗嘱消息（Last Will），设备异常断线时Broker会代发一条预设消息，这样平台就能快速感知设备掉线。这些特性都是SNMP生态里没有的。做工业数据采集时，MQTT把"设备状态上报"这件事的工程复杂度降了不止一个量级，我们后端的判活逻辑、断线重连逻辑，都省了很多事。

1.3 组合的必然性：存量资产和新生设备之间需要一座桥

在真实的工业现场，我几乎没见过哪套系统是纯SNMP或纯MQTT就能覆盖完整的。生产网络里有老的博科光交、思科交换机，它们静默工作了七八年，固件版本很老，不会对外提供任何MQTT接口，你只能SNMP去采集；而新增的传感器、智能电表、边缘计算盒子则完全走向MQTT生态，更别提很多设备本身内部跑的就是MQTT客户端。如果只保留一种协议，要么新设备没法接入，要么几千台旧设备全部要换，这笔成本在预算会上就能把项目否决掉。

所以双协议组合的第一原则不是"二选一"，而是"各归其位"：存量网络设备和传统机房基础设施走SNMP采集，新式传感器和智能设备走MQTT接入，两边在边缘网关层汇合，由网关统一做协议转换、数据归一化、指令路由后，再向上对接统一的物联网平台。这套架构既保护了既有投资，也顺应了设备联网化的大趋势。后面我将按照这个思路，分别讲透两条接入链路的关键实操细节。

2. MQTT端：老设备上云的关键一跳——485设备接入与指令下发

2.1 485设备与MQTT之间到底隔着什么

很多做IT出身的人第一次接触工业485设备时都会问一个相同的问题："MQTT怎么直接给485设备发指令？"这其实是个协议层级上的误解。RS-485是物理层总线标准，规定的是电气特性：差分信号、半双工、传输距离可达1200米。它上面跑的往往是Modbus RTU协议——这才是应用层协议，用功能码03读保持寄存器、06写单个寄存器，一个字节一个字节地约定报文格式。而MQTT是典型的应用层消息协议，运行在TCP/IP之上，按Topic和Payload组织内容。

你在485总线上根本找不到一个"MQTT客户端"，因为485设备没有网络协议栈，更不认识TCP端口1883。所以"MQTT给485设备发指令"这句话，准确的表述应该是：通过MQTT向边缘网关下发指令，网关再把指令翻译成Modbus RTU报文，在485总线上控制对应的设备寄存器。网关是这道翻译动作的执行者，这才是通行的工业接入方式。与其纠结协议层级，不如设计好网关的Topic规范和指令模板，让上层平台把485设备当成"通过MQTT可达的虚拟设备"来管理。

2.2 让485设备开口说话：Modbus RTU的读写模型

以最常见的Modbus RTU为例。一条完整的读指令报文分四段：从站地址（1字节）、功能码（1字节）、寄存器起始地址（2字节）、寄存器数量（2字节），最后再加CRC16校验。比如往从站地址为1的设备读第0号寄存器的值，报文就是01 03 00 00 00 01 84 0A。设备收到后返回01 03 02 [数据高字节] [数据低字节] [CRC]，一次往返完成一次读取。写单个寄存器的指令是01 06 00 00 [数据高字节] [数据低字节] [CRC]，注意功能码是06，写入寄存器后设备会原样返回这条指令作为确认。

实际项目中，一个网关的485口上往往挂着一串设备，比如8台电表、3个温湿度探头、1台PLC。每个设备分配一个Modbus从站地址，每个监测量对应一个寄存器地址或线圈地址。网关侧要有能力维护一张"寄存器映射表"——表里每个点记录所属从站地址、寄存器地址、数据类型（整型16位、浮点32位、布尔线圈）、缩放系数（比如采集到的原始值是1000，实际温度是10.0度，缩放系数就是0.01）。这张表是整个MQTT数据上报的基础，因为网关通过Modbus轮询把原始数据读回来后，需要在内部分辨出"这个值对应哪个传感器、该除以还是乘以多少、单位是什么"，然后再封装成JSON发布到MQTT Broker上。

2.3 指令下发怎么设计：MQTT Topic与JSON命令模板

指令下发要解决的核心问题是"消息往哪发、怎么区分不同设备的指令、平台怎么知道执行成功"。我给出的设计是这样的：

• 平台发布设备指令的Topic统一用iot/devices/{deviceId}/command，其中deviceId用设备编码标识；
• 指令Payload用JSON，至少包含cmd（命令类型）、params（参数）、requestId（请求唯一标识）；
• 设备端或网关侧收到指令执行后，把结果发布到iot/devices/{deviceId}/command/reply。

比如要遥控一台485电表的继电器合闸，平台发出的指令是这样的：

{ "requestId": "REQ-20240517-0001", "cmd": "writeRegister", "params": { "slaveAddr": 3, "registerAddr": 0x0000, "value": 1, "dataType": "uint16" } }

网关收到后，解析出slaveAddr=3、registerAddr=0x0000、value=1，然后组装Modbus RTU报文03 06 00 00 00 01 CRC，写入总线。设备应答成功，网关再把结果封装成一条MQTT回复消息：

{ "requestId": "REQ-20240517-0001", "code": 0, "message": "success", "ts": 1715932345000 }

平台侧用requestId把请求和回复对上，就知道这次控制成功了。requestId非常重要，因为QoS 1或QoS 2下，MQTT可能重复投递消息，没有唯一ID的指令就会被重复执行，这在工业控制里轻则操作日志错乱，重则引发事故。

2.4 485轮询策略与并发模型：别让慢设备拖垮整条链路

做了几个项目之后，我强烈建议不要在MQTT上报逻辑里做"同步等待式"的485指令操作。曾经我们在一个网关里让主线程先发Modbus读请求、阻塞等待应答、把结果发布到MQTT，结果连接到同一网关的一台指针式仪表响应特别慢（一次应答要3秒），导致后面几十个采集点的数据全部排队卡住。后来改成"采集线程池+消息队列"模型：一个独立的Modbus主站线程按调度表轮询各从站地址，只负责把读回来的原始值丢进环形队列；另一个数据格式化线程消费队列，把寄存器映射成有意义的业务量，再通过MQTT客户端异步发布。轮询超时对单个从站的感受不到，整条链路不会因为个别慢设备而停滞。

轮询间隔也要按数据变化的快慢分级。温度、湿度这类缓变数据，10秒一次绰绰有余；电表的电压电流可以2秒一次；开关状态（DO/DI）这种需要快速感知的，1秒甚至更短。分级轮询能显著降低485总线的占用率，也给MQTT Broker减少不必要的消息压力。我记得有一次现场做了400个采集点全用1秒轮询，总线负载率接近60%，在强干扰环境下导致满地CRC错包，后来把缓变数据改到10秒间隔，负载率一下降到15%，误码问题再没出现过。

3. SNMP端：存量网络设备的统一监控入口

3.1 SNMP离不开的几个核心概念：OID、团体名、TRAP、MI B对象

SNMP对不熟悉的人来说有点门槛，因为整个模型非常"面向字典"。经常打交道的核心概念就这几个：

• OID：设备的每一项可管理信息都对应一个全局唯一编号，物理上是一个整数序列，逻辑上是一棵从根节点往下生长的树。常见标准OID有：sysDescr（1.3.6.1.2.1.1.1.0，设备描述）、sysUpTime（1.3.6.1.2.1.1.3.0，运行时间）、ifInOctets（1.3.6.1.2.1.2.2.1.10，端口入流量字节计数）。
• 团体名（Community）：类似密码，分只读（public通常只读）和读写（private通常读写）。v2c版本下团体名是明文传输的，所以生产环境一定要改掉默认值，并且尽量不用读写团体名。
• Manager与Agent：监控平台是Manager，被监控设备上是Agent。Manager发GET/SET请求，Agent响应；Agent如果配置了TRAP目标地址，在特定事件（端口down、风扇故障）发生时主动发TRAP给Manager。
• MIB：描述OID含义的字典文件。虽然大部分标准OID可以靠网上的MIB资料查，但博科这种厂商的私有MIB（1.3.6.1.4.1.1588这个节点以下是博科私有）往往只能找厂商要，没有MIB文件，OID对应不上业务含义，采集就是瞎抓。

3.2 博科光交的SNMP配置实操：开启Agent并限制访问来源

我以现场那两台博科光纤交换机举例。登录到交换机命令行后，开启SNMP服务并设置访问控制的操作大致如下：

switchexample:admin> snmpconfig --set snmpv1

执行后交换机进入交互配置界面。需要逐项确认或修改的参数包括：

• 只读团体名：建议定义一个生产环境专用的随机字符串，不要用public；
• 读写团体名：光交换机一般不需要远程改配置，直接禁用或设置复杂密码；
• 访问主机列表（access list）：只允许监控服务器的IP地址来查询，不填这个就相当于把光交的SNMP端口暴露给整个网段，谁都能开关SNMP会话；
• 系统位置（sysLocation）：写明物理位置，方便监控平台上溯源。

配置完成后可以用监控服务器上的工具验证一下。比如用snmpwalk命令（net-snmp套件自带）看一条完整的OID叶子数据：

snmpwalk -v2c -c 生产团体名 192.168.10.20 1.3.6.1.4.1.1588

能成功返回一串OID和值，没有超时和no Such Object报错，就说明配置没问题。这里有个细节：光交换机的端口流量计数和光模块功率都在私有MIB节点下，必须确认设备固件版本支持的MIB表是够新的，否则底层端口数量有增加（比如加了扩张槽位），OID表错位会导致采集数据串位。

3.3 监控项设计：把散落的OID组织成业务指标

SNMP采回来的原始OID数据本身可读性差，比如ifInOctets返回的是一个单调递增的计数器字节数，而监控人员真正关心的是"当前该端口每秒有多少流量"。所以平台侧在采集完原始值后，还得做三层加工：

1. 基线对齐：根据MIB定义明确计数器类型（32位还是64位）；
2. 差值计算：用两次采样的计数差值除以时间间隔，得到速率；
3. 阈值判断：对速率、CPU占用率、温度值设置告警阈值。

实际落地时我会建议先做一个"MIB盘点"工作，把设备所有的OID导出来，逐个标注"采集频率高、低频、不采集"。高频项（端口状态、CPU利用率、温度）每1~2分钟采集一次；低频项（配置文件、系统信息）每天或每周采集一次即可。千万不要把所有OID不分青红皂白全部高频轮询，否则监控服务器和设备的CPU都会被打满。我见过一个用Zabbix做SNMP监控的案例，默认模板会把接口表和ARP表全量拉取，几十台交换机就把采集器拖垮了，后来把ARP表这种超低频数据从轮询列表里排除，采集器负载直接降了七成。

3.4 避免轮询风暴：批量Walk与增量感知结合

轮询风暴是最常见的SNMP集成事故。当监控对象数量从几百台涨到几千台，如果每台设备都按固定的全量列表高频查询，监控服务器的并发连接数会瞬间飙升，交换机的SNMP Agent要同时响应来自多个采集器的请求，轻则CPU飙高，重则中断协议栈。我们实践下来的几个缓解手段是：

• 尽量用GET-NEXT（或批量Walk）而非逐个GET：一条snmpwalk可以遍历一大段OID子树，把几百个叶子节点的数据一次性带回来，请求次数大幅减少；
• 对不同OID分组用不同轮询周期：状态类数据快轮询，统计类数据慢轮询；
• 充分利用TRAP做事件感知：端口down/up、风扇故障这类阈值性事件，不要靠轮询去撞，全是浪费。让设备主动上报TRAP，平台收到TRAP后再反过来做一次精确的GET确认现场数据，这样既保障及时性又降低轮询开销。

4. 双协议的汇合点：边缘网关的数据翻译与双向流转

4.1 网关扮演的角色远不止"协议转换"

不少人在架构图上把边缘网关画成"一个插线即用的盒子"，实际部署的时候才发现，它承担的任务包括：多协议接入、断点续传、数据缓存、时间戳统一、指令鉴权、逻辑联动，甚至在弱网环境下要能独立维持一轮本地闭环控制。你把它想象成一个心脏——SNMP网线和485总线是静脉，往回流数据；MQTT Broker的上下行链路是动脉，承担平台与设备的双向消息。心如果停跳，两边都白搭。

所以在选型或自研网关时，我首选能同时支持以下能力的设备/软件：Modbus主站功能、SNMP Manager功能、内置MQTT客户端、落盘缓存（至少能保存24小时数据），以及一套可配置的规则引擎。最怕的是网关只支持某一种协议栈，比如只能485采集但SNMP得靠另一台设备，那你又得增加一个中间件，链路一长，故障点就翻倍。

4.2 数据模型统一化：把分散的SNMP OID和JSON消息对齐到同一张表中

双协议汇合的关键是数据模型统一，这里我强烈建议建一张"资产模型点表"。表里每一行定义了一个逻辑点位信息，不管点位数据来自SNMP还是Modbus，最终都归一化成同样的结构，再通过MQTT统一上报。字段设计参考如下：

SNMP采集线程拿到端口光功率OID1.3.6.1.4.1.1588...后，带上assetId=SW-BROC-001写入这条点表；Modbus采集线程读到电表电压寄存器后，同样带上assetId=EM-001写入点表。之后统一由MQTT发布组件把点表数据发布到对应Topic，平台侧只需要处理一套数据格式，完全不用关心底层协议差异。这样做还有个好处：设备换品牌换型号时，只要点表里协议和OID/寄存器地址改掉，上层逻辑和告警规则不用动，改造成本极低。

4.3 双向流转：上行采集和下行指令的完整链路

把前面两部分串起来，双协议在网关里的双向流转大致是这样的：

上行链路：SNMP轮询线程读博科光交的OID -> 加工成业务值写点表；Modbus轮询线程读电表寄存器 -> 加工后同样写点表；MQTT发布组件定时把点表新数据发布到iot/telemetry/{assetId}。

下行链路：平台下发控制指令到iot/devices/{deviceId}/command-> 网关MQTT客户端订阅到 -> 指令解析引擎判断目标是不是485设备，若是则组装Modbus报文写入总线；若不是，则组装SNMP SET请求改设备参数 -> 执行结果发布到reply Topic。

这个双向流转最考验细节的地方是时序。如果485总线上Modbus主站正在轮询半途中，平台指令下来了，不加以协调，报文两个功能码可能会撞车，导致总线电平互相踩踏。我在网关实现里做了一个个"命令队列优先级高于轮询"的调度策略：轮询线程每发送一条请求后等应答，应答回来再发下一条；当高优先级的指令进入队列时，轮询线程进入待命，暂停下一轮，先让指令报文占用总线。实测这样处理之后，指令时延稳定在几十毫秒内，且485总线上几乎没有报文乱序。

4.4 安全与访问控制：双协议环境下最容易忽略的配置

最后必须单独提醒安全配置。SNMP v1/v2c的团体名是明文传输的，凡是在交换机上留了public/private默认值的项目，基本等于把设备管理模式暴露给了网内所有人。能升级到SNMP v3最好，至少也要把只读团体名和读写团体名分离，并在接入层做IP白名单。MQTT侧也同理，生产环境一定要用TLS加密传输，禁止用1883明文端口在不可信网络上跑设备数据。而Broker的ACL（访问控制列表）应该精确到Topic级别：不同设备只能发布/订阅自己的Topic前缀，平台上不同角色订阅权限也分开。如果把所有设备的消息都放到一个通配Topic，任何人都能订阅到全厂实时数据，这在合规审查上就是硬伤。

5. 从Demo到生产：性能调优与踩坑实录

5.1 轮询风暴复盘：一次慢网页卡死整个采集链路的教训

这个坑特别有代表性。最早我们在测试环境把网关接了一台博科光交，SNMP每个OID都逐条GET，几十条OID就够用了，一切正常。上线接入80多台交换机后，采集线程数不够，轮询请求在设备侧堆积，某台老交换机SNMP Agent响应极慢，紧接着一连串设备都开始查询超时。表面看是设备负载高，实际上是我们的轮询模型没有一个"慢设备熔断"机制。

后来把SNMP Manager改成"批量Walk + 无同步等待"的模型后解决：每台设备的采集任务独立成一个worker，如果某台设备连续3次超时，自动标记故障并降低采集频率，不再跟健康设备抢线程。同时网关增加采集结果缓存，即使SNMP侧查询失败，MQTT上报线程仍按正常节奏发送，平台端至少能看到"数据过期"而非"数据中断"，这大大减少了误告警量。

5.2 计数器回绕与时间戳失真问题：32位计数器清零后怎么算

SNMP的很多计数器是32位的，比如ifInOctets，当端口累计流量超过4GB后计数会归零重新累加。如果监控系统按"本次值-上次值"直接算差值，就会得到一个负值，误判成流量急剧下降甚至负流量。这个问题在光交端口流量监控中特别容易踩，因为光交的端口速率很高，千兆跑满也就34秒就能冲满4GB计数范围。

正确做法是使用无符号差值算法：设current为本次读数、last为上次读数、max为计数器最大值加1，则实际差值为(current - last + max) % max。32位计数器max = 2^32。如果设备支持64位计数器（OID以ifHCInOctets开头的一般就是64位），优先用64位，因为32位的回绕频率在高速端口上太吓人了。除了计数器，轮询采样时间戳也很重要。不要在每次轮询时用设备返回的sysUpTime做时间戳，那个值是设备自己内部计时，不同设备之间不一定同步；统一用网关本地时钟打时间戳，并跟平台做一次NTP校时，才能保证同一时刻不同设备的数据可比。

5.3 QoS级别与重复消息的坑：指令幂等设计必须做

MQTT的QoS 1在Broker和客户端之间保证"至少一次"投递，但也因此带来了重复消息问题。假设平台下发了一条继电器合闸指令，客户端断线前收到了消息但还没来得及回ack，Broker用会话保留机制重新投递一遍，网关如果没做幂等处理，就会连续执行两次合闸，这在工业控制上很严重。

我们的解决办法分两层。第一层：指令消息里带上requestId，网关执行前查一张"已处理指令表"，如果requestId已经执行过，直接回复成功，不再实际写寄存器；第二层：对具体的控制类指令，在网关的命令队列里做"同目标设备同指令去重"，同一设备在一秒内只保留最新一条控制指令，避免控制指令的重复堆积。这样即使Broker异常重投，也不会造成设备被重复驱动。

5.4 遗嘱消息误触发：网络抖动把设备"判死"怎么办

MQTT遗嘱消息在设备异常掉线时会由Broker代为发布，听起来很合适，但有个坑。网关的MQTT客户端使用的是长连接，如果网络偶尔抖动一下，TCP连接断了，Broker立刻发布遗嘱消息，平台就收到"设备离线"告警；但很快网关重新连上来，又发一条"设备上线"。一次网络抖动就是两条告警，在弱网环境里这就是告警轰炸。实测我们某个工厂项目，一天能收到几百条这样的误告警。

解决方案是平台侧不要只看遗嘱消息就下结论，而是设置一个"确认窗口"：收到设备离线遗嘱后，先等一段时间（比如90秒），如果网关没有在期限内重新登录，才真正标记为离线；若重新在线了，撤销离线标记。同时建议网关侧把MQTT的心跳间隔（KeepAlive）调长一点，比如30秒，让它能容忍短时间的网络抖动，而不是一断就急着重连。网侧和处理侧双重机制配合下来，误告警数量直线下降。

5.5 故障排查的三板斧：日志、抓包、MIB验证

双协议组合的排查链路天然比单协议复杂。出问题时先看网关日志里最关键的三个时间点：MQTT连接时间、最后一条上行遥测发布时间、最后一条Modbus/SNMP下行指令执行时间。这三个时间错开，就能快速把问题圈定在消息接入段、转换段还是平台下发段。

第二个排查利器是抓包。485链路可以用串口抓工具直接看到Modbus RTU报文；SNMP链路用Wireshark抓UDP 161/162端口能看到GET请求和响应；MQTT链路在Broker侧启用会话日志就能看到设备上下线和消息投递情况。抓包唯一要提醒的是生产环境不要长时间多端口并行抓，数据量太大基本看不过来。

第三个是MIB验证。很多时候查出的问题是厂商私有OID返回值格式和预期不符，这种时候不能只网上搜MIB文件，最好找厂商要对应固件版本的官方MIB，用snmptranslate工具把OID翻译成名称再对照数据表，防止因为OID映射错误导致整批设备的数据串线。

我做完这套双协议组合方案，最深的体会是：协议本身并不是重点，重点是"围绕协议建立的一套管理规则"。SNMP轮询间隔、Modbus地址表、MQTT Topic设计、遗嘱消息处理，这些东西没有一件是花哨的技术，但每件都决定了系统在真实环境中能不能扛得住。如果你也是在做工业设备接入这块，建议先别急着起平台，把你现场设备的存量清单拉出来，按协议分个类，把点表和指令模板这层基本功做扎实。这套地基本质上就是数据架构，它稳了，后面加设备、加告警规则都只是"填表"的活。如果大家在做过程中有类似的坑和思路，非常欢迎交流。