企业官网建设流程全解析

机房里的设备娇贵，这不是玄学。一个机柜里堆着几十台服务器和交换机，温湿度一旦失守，轻则硬件寿命缩短，重则直接宕机。传统机房巡检是值班人员拿着手持仪表逐个机柜去测，数据记在本子上，等发现异常往往已经晚了。这次项目要做的，就是给服务器机房做一次可视化升级：把分散在机柜和空调口的温湿度记录仪数据，通过双协议统一采集上来，再实时联动到可视化大屏上，让运维人员一眼看清机房环境状态。换句话说，就是把机房从“盲人摸象”变成“一目了然”。这篇我从设备选型、协议设计、采集实现到大屏落地的全过程都写一遍，适合正在做机房监控、数据中心动环改造或者大屏可视化项目的朋友参考。

1. 项目背景与需求拆解

1.1 机房温湿度监控的痛点在哪

先说现实状况。不少企业的机房温湿度管理还停留在相当原始的阶段：装了几台独立温湿度记录仪，设备自带小屏幕，需要人走到跟前去看；或者干脆靠巡检人员拿手持仪表一个一个机柜去测，数据全靠手抄。这带来的问题很直接：

第一，巡检频率低、覆盖不全。正常值班情况下一天测两三次就不错了，夜间和节假日基本是盲区。偏偏机房最容易出事的时段就是空调故障、断电后的那几个小时。凌晨空调压缩机挂了，到早上才发现机房温度已经飙到35℃以上，硬盘大量报错。

第二，数据是割裂的。每台记录仪只记录自己周边的数据，无法汇总分析。某个机柜长期温度偏高，空调负载是不是不均衡，这些信息根本看不出来。

第三，告警手段太弱。市面上很多记录仪自带声光报警，装在现场，但机房通常没人在里面长期值守，报警了也没人听到。等到手机收到短信通知的时候，可能已经过去了个把小时。

第四，没有历史趋势。出了问题只能事后看现象，想回溯“温度什么时候开始起飞的”“对应哪台设备操作”完全没有依据。

所以这次项目的最核心目标，就是把“人去找数据”改成“数据找人”。利用已有的温湿度记录仪，把数据实时采集出来，通过大屏集中呈现，温度异常、湿度超限、设备离线都能第一时间看到，并且具备历史追溯能力。

1.2 可视化大屏解决的不只是“好看”

有人会问，温湿度数据用列表和表格看不行吗？行是行，但效率完全不是一回事。机房运维的时候，你要的是几十秒内掌握全局态势：哪个区域温度偏高，哪几个机柜有异常苗头，空调出风口和回风口温差是不是正常。表格里一百个点位按顺序往下翻，眼睛是抓不住空间关系的。这正是可视化大屏的核心价值所在。

大屏的三个关键能力：

一是空间化。数据不是孤立的一行行数字，而是落到机房平面图上。每个机柜是一个色块，温度高低用颜色深浅表达，扫一眼就知道热点在哪个位置。值班人员不需要记忆哪个点位编号对应哪个机柜，直接看图形。

二是实时性。大屏数据是秒级刷新的，空调启停、设备负载变化带来的温度波动，两三分钟内就能在曲线上看到拐头。以前这一步要靠人肉巡检去发现，现在系统自动做到了。

三是联动性。大屏不只是展示，更是告警和操作的入口。点击某个机柜色块能下钻看这个点位的详细温湿度曲线。温度异常时，大屏弹窗闪烁、声音提醒，甚至可以通过联动规则远程开启排风机或通知空调厂家处理。这就把“监控”升级成了“联动处置”。

1.3 为什么要用双协议方案

“双协议”这三个字，在设计阶段是争论最多的。最初的方案是全走RS485 Modbus RTU，因为机房里的温湿度记录仪基本都是RS485接口，属于行业标配，用一套串口服务器转以太网就能把所有点位接到网络上。但真正去现场盘点点位的时候发现，情况没那么简单。

机房里有历史遗留的老设备，也有这次新采购的传感器。老设备走RS485，布线距离一长信号就衰减；新点位有些分布在网络条件好的机柜附近，直接走以太网更方便。而且不同批次设备，有的只支持RS485，有的自带RJ45网口支持Modbus TCP。如果强行统一到单协议，要么得淘汰一批还能用的老传感器，要么得为每个RS485点位单独拉很长的屏蔽双绞线，成本都不低。

所以最后方案定为双协议并存：

• 链路一：RS485 Modbus RTU，通过串口服务器转换成Modbus TCP，适用于老设备和距离远、现场布线成本高的点位。
• 链路二：传感器自带以太网口，直接以Modbus TCP协议接入，适用于新设备和网络条件好的点位。

两条链路最终都把数据汇聚到同一套采集服务，对大屏和告警逻辑完全透明。简单说，底层不管数据怎么上来，上层统一处理。这就是双协议方案最核心的设计逻辑：不跟现场条件拧着来，能用什么就用什么，但统一出口。

2. 设备选型与整体架构设计

2.1 温湿度记录仪怎么选不踩坑

这个环节踩过的坑比后面所有环节加起来都多。直接说结论，按这几个维度选，基本不会出大问题。

首先是测量精度。温度必须选±0.3℃或更高精度，湿度选±2%RH或±3%RH。机房环境温度范围窄，正常就在20℃到27℃之间，如果买个精度±1℃的传感器，温度变化两三度根本区分不出来，阈值告警形同虚设。预算集中在传感器上，别在核心测量部件上省钱。

其次是接口形式。优先选RS485接口、Modbus RTU协议的，这是行业标配，后接的设备、调试工具、参考资料都最多。如果预算允许，直接买同时带RS485和以太网口的型号，这样同一个点位既能走485链路也能走TCP链路，灵活性最高。

第三是供电方式。机房环境下，DC 12V或24V供电是主流，有条件选支持POE的型号，网线供电省一路电源线。独立供电的话要提前算好电源总容量，多路供电才能避免一个保险丝挂掉导致一片传感器离线。

第四是探头结构。强烈建议选探头外置型而不是一体化SD卡型。外置探头可以伸到机柜内部、天花板回风口这种关键测温位置，设备本体留在机柜外侧方便维护。一体化设备只能测自己身边的环境，灵活性差很多。

第五是本地显示。带LCD显示屏的型号调试时非常方便，接好线直接看面板读数对不对，不需要额外拿万用表或者调试工具去比对。这个功能看着小，实际体验差别很大。

2.2 双协议链路的具体做法

双协议听起来高大上，本质就是两条数据通路。把链路拆开来看就很清楚了。

链路一：RS485 Modbus RTU → 串口服务器 → Modbus TCP

RS485是两线制差分信号，传输距离理论上能到1200米，实际机房这种环境几百米内没问题。布线用屏蔽双绞线，A和B两芯不能接反，这几乎是最常见的低级错误。串口服务器的作用是把RS485串口信号转换成网络信号，相当于给老传感器配了一个“网络翻译器”。市面上这类设备很多，比如有人物联网USR-M511、卓岚ZLAN5143这一类，价格不高，功能也稳定。串口服务器一般自带Modbus TCP网关功能，上层直接用TCP轮询即可，不用自己解析RTU报文。

链路二：传感器自带以太网口，直接Modbus TCP

新设备更省事，插网线、配IP、开端口就能访问。这类传感器内部本身做了485转网络的处理，性能更好，而且可以通过网页直接查看和配置参数。缺点是价格高一些，而且每个点位都要占用一个IP地址。IP规划要做好，我习惯单独划分一个温湿度采集网段，和业务网络隔离，避免IP冲突和安全隐患。

两条链路的关键配置参数对比如下：

设计上的原则就一条：能走485的走485，网络条件好的新增点位直接走TCP，两条链路上层全部接入同一个采集服务。这样后面扩容，新设备按类型选一条链路接进来就行，不用改架构。

2.3 从传感器到大屏的完整链路

用一个公式概括整套系统：传感器采集 → 边缘网关汇聚 → 服务层处理存储 → 告警联动 →大屏展示。

传感器层负责采集温湿度原始值，部署位置是关键。我的习惯是在每个机柜的前门下方（进风口）和后门上方（出风口）各装一个探头。进风口温度代表设备实际进风温度，这是设备可靠性的直接衡量标准；出风口温度能反映设备发热量，两者对比还能判断空调风流是否短路、机柜散热是否正常。

边缘网关层主要由串口服务器、交换机、继电器模块组成。串口服务器把RS485信号转成IP报文；交换机把所有网络信号汇聚到一起；继电器模块用于联动外部设备，比如温度异常时远程开关排风机或备用空调。

服务层是整套系统的大脑。通常是一台Linux服务器，部署Python数据采集服务、MySQL数据库、Redis缓存、Node-RED联动引擎和WebSocket推送服务。这里不追求高配置，机房监控数据量不大，一台4核8G的旧服务器跑起来完全没问题。

展示层是可视化大屏，前端使用Vue3加ECharts，通过WebSocket接收实时数据，绘制平面热力图、实时曲线、告警列表和统计面板。大屏终端可以是55寸一体机、拼接屏，甚至普通会议室大电视，只要浏览器能跑就行。

整个链路看着长，但每一层职责非常单一，出问题容易排查。我也见过有人想一步到位，传感器直连大屏数据库，结果安全性和扩展性都一塌糊涂。分层设计在这个场景里不是过度设计，是后续维护省心的基础。

3. 数据采集与联动逻辑实现

3.1 点位规划与Modbus地址表管理

数据采集这件事，90%的坑都出在地址管理上。机房传感器数量一多，如果没有一张清晰的地址台账，调试就是在打地鼠，处理完一个又冒出来一个。

我的做法是开工前先建一张点位规划表，把物理位置、逻辑地址、链路类型全部对应好。表格大概长这样：

后期新增点位就按表格往下一行加，采集程序启动时读取这张表的配置，不用改代码。Modbus地址在同一个串口服务器下必须唯一，跨串口服务器可以重复，因为上层是通过“串口服务器IP+从站地址”双重定位的。我踩过一次地址重复的坑：两台传感器被配置成了同一个从站地址，结果串口服务器收到两条响应报文，采集程序拿到的数据时对时错，排查了一整天才发现是地址冲突。

寄存器地址这一块要特别提醒。不同厂家的传感器，寄存器映射完全不一样。有的把温度和湿度放在连续地址，有的中间隔着状态字，有的数据是int16，有的是float。最保险的做法是接入前用Modbus Poll或者厂家提供的调试工具，把每个功能码对应的寄存器读一遍，确认了温度、湿度的真实地址和数据类型再写采集逻辑。这块省下来的功夫，后面会百倍奉还。

3.2 采集频率、数据轮询和数据格式换算

温湿度变化不是高频信号，采样频率没有必要追求极致。我实际用的配置是：常规点位10秒采集一次，关键点位（空调出风口、核心机柜）提高到3到5秒。再高的频率意义不大，只是白白增加数据库写入压力和网络流量。

轮询策略上，用后台调度线程遍历所有点位，串行请求会受单个点位响应时间的拖累。点位多的时候按串口服务器分组并发轮询，每个组一个线程，明显能缩短一轮完整采集的总时间。实测一百多个点位，分组并发下完成一轮采集只需要2到3秒，完全满足大屏的实时刷新需求。

数据格式换算是新手最容易忽略的点。Modbus寄存器读出来的是原始值，需要按厂家文档里的缩放系数换算成真实物理值。举个例子，某传感器温度寄存器原始值是235，文档写明缩放10倍，那实际温度就是23.5℃。湿度同理，原始值除以10得到百分比。这个细节如果不注意，大屏上会出现235℃这种荒唐的数据，每次看到都能吓出一身冷汗。

采集服务我用Python的pymodbus库实现，核心逻辑大概是这样的：

from pymodbus.client import ModbusTcpClient client = ModbusTcpClient("192.168.10.100", port=502) client.connect() # 读取温度寄存器，功能码03，起始地址0x0001，长度1 rr = client.read_holding_registers(0x0001, 1, slave=1) if not rr.isError(): raw_value = rr.registers[0] temperature = raw_value / 10.0 # 缩放系数10

采集到的数据双写：MySQL里存全量历史，用于报表和回溯；Redis里存最新值，供大屏和告警逻辑快速读取。MySQL表设计时一定要给“采集时间”字段建索引，数据积累几个月后，查历史曲线才会快，不然全表扫描会越来越卡。

3.3 阈值告警与联动规则设计

告警不是温度超过某个值就报，那样误报率会让人崩溃。我把告警拆成两级设计。

第一级是阈值判定。参考GB50174机房设计规范并结合设备厂商要求，我常用这组阈值：

• 温度：26℃黄色预警，30℃橙色告警，35℃红色告警；
• 湿度：低于40%或高于70%视为异常；
• 传感器连续3个采集周期超阈值，才判定为真实告警，避免偶发尖峰造成误报。

第二级是联动动作。告警事件产生后，通过MQTT推送到Node-RED联动引擎，Node-RED按预先配置的规则执行动作：

• 大屏红色区域闪烁并弹窗提示；
• 通过微信或短信接口通知值班人员；
• 通过继电器模块远程开启排风机或备用空调。

用Node-RED做联动引擎，最大的好处是规则可视化，改阈值、换联系人、调动作，都不需要改代码重新发布。做这个项目的后期，空调厂家要调整联动温度阈值，直接在Node-RED界面上拖个节点改个数字就生效了，省去了重新走一遍开发流程的成本。

3.4 大屏实时数据推送的WebSocket方案

大屏对实时性要求高，我全程用WebSocket做服务端推送。采集服务每轮采集完成后，就把所有点位的最新值组装成一个JSON数据包，通过WebSocket连接直接推送到大屏前端。

推送的数据包结构大致是这样的：

{ "timestamp": "2025-06-12T09:30:00", "points": [ {"id": "T01", "name": "机柜A进风口", "temperature": 24.3, "humidity": 52, "alert": 0, "online": true}, {"id": "T02", "name": "机柜A出风口", "temperature": 31.2, "humidity": 48, "alert": 1, "online": true} ] }

用WebSocket而不是HTTP轮询，好处非常明显。第一是低延迟，数据从采集完成到出现在大屏上，只有网络传输的几十毫秒延迟。第二是省资源，机房几百个点位数据一秒推一次，一个WebSocket连接就能搞定，HTTP轮询的流量和数据库压力是它的好几倍。第三是实现简单，前端监听一个onmessage事件，收到数据直接更新图表即可。

这里有个经验：WebSocket连接一定要做心跳检测和断线重连。机房网络偶尔会有抖动，连接断了如果前端不自知，大屏就会“冻住”，值班人员还以为环境数据没变化。我在前端加了一个30秒心跳机制，超过阈值没收到服务端心跳就自动重连，并把断线时间显示在页面角落，方便运维判断数据是否可能中断过。

4. 可视化大屏设计与落地

4.1 大屏布局的原则和常规方案

大屏设计的首要原则是信息层级清楚。最重要的数据放在视觉中心，辅助信息放四周。我通常会按照这样的布局来规划：

顶部是全局状态横条，显示机房平均温度、平均湿度、在线传感器数量、当前告警数量。这是值班人员扫一眼就能确认“机房目前整体是否正常”的地方。

中间大面积部分放机房平面热力图。这是整个大屏的核心视图，每个机柜映射成平面图上的一个色块，颜色从深蓝到深红渐变，对应温度从低到高。值班人员目光落在大屏上，首先看的就是这片热力图。

右侧放实时告警列表，按严重程度倒序排列，每条告警显示点位名称、当前值、阈值、发生时间。列表最多显示最近20条，太久的告警让人看了也记不住，不如清掉。

左侧放今日温度/湿度变化曲线和设备在线率统计图。曲线用于观察整体趋势，比如空调是否间歇性工作、机房温度是否有周期性波动。

大屏尺寸按1920x1080设计即可，如果要上拼接屏，客户采购的通常是55寸或65寸的2x2、3x3拼法，实际分辨率能到3840x2160甚至更高。页面布局要用栅格系统而不是固定像素，避免不同分辨率下变形。我用CSS Grid按12列栅格去划分，配到任何分辨率的大屏上都不会出大问题。

4.2 机柜热力图和点位下钻怎么做

热力图是整个大屏信息量最大的部分，也是技术上最容易出问题的部分。ECharts的heatmap要求传入网格坐标(x, y, value)，但机房机柜并不是均匀排列的，有高有矮，还有承重柱、通道、配电柜。把这套空间逻辑映射到热力图上，需要两步：

第一步，用机房平面图作底图，按实际位置在图上手动标出每个机柜的坐标。这一步没有捷径，只能拿着CAD图或者现场量尺寸一点点标，标得越准，热力图呈现的失真越小。

第二步，把传感器的读数映射到对应机柜坐标上。没部署传感器的机柜，用相邻点位的均值给它填充一个估算值，避免热力图出现大片空洞影响判断。

热力图色阶有一个重要细节：色阶范围要按照机房温度实际区间来设置，千万别用默认的全区间渐变。机房正常温度在20到27℃之间，如果色阶从0℃开始，所有格子都会偏向同一种颜色，热度差异完全看不出来。我通常把色阶设置在20℃到40℃之间，低于20℃的统一显示深蓝，高于40℃的统一显示深红。这样温度差异才能通过颜色敏感地体现出来。

点击热力图上某个机柜时，我实现了“下钻弹窗”交互：点击机柜色块，前端向服务端发起请求，从MySQL查该点位最近24小时的温湿度数据，弹出曲线图，同时显示当前值、告警等级和最近状态变更时间。这个交互看起来简单，实际对性能优化有要求。24小时的数据按5秒一条存储，单点位就有超过17000条记录，全部画出来曲线会糊成一团，浏览器也扛不住。我的方案是在SQL里按时间窗口聚合，每10分钟取第一个值和平均值，曲线趋势保留完整，数据量缩小到144个点，用ECharts平滑渲染毫无压力。

4.3 告警弹窗与声光联动融合

温湿度异常时，大屏只是数字变化远远不够，值班人员不可能永远盯着屏幕。所以告警提醒做了两级。

页面内提醒：告警点位上浮一个半透明的红色呼吸灯标记，右侧告警列表自动把新告警置顶，顶部额外弹出一个横条提示，显示告警点位名称、当前数值和告警等级。呼吸灯动画用CSS的animation实现，不用JavaScript不停操作DOM，性能损耗可以忽略。

外部联动提醒：前端用Web Audio API在值班室喇叭上播放短促提示音，这个纯前端就能实现，不需要额外硬件。如果机房本身有声光报警器，通过继电器模块在告警时拉高电平触发报警器，这一步是Node-RED联动规则配置的内容。

这里有个容易忽略的产品逻辑问题：告警必须支持“确认”和“消音”，不然告警一直响，值班人员烦不胜烦，最后可能直接把声音线路拔掉。告警状态我设计为三类：未确认、已确认未恢复、已恢复。只有“未确认”状态才触发声音，点确认后立刻静音。等数据恢复到阈值以下，告警状态自动变成已恢复。这样既不会漏报，也不会过度打扰。

4.4 大屏性能优化几个实操技巧

大屏页面上同时跑十几张ECharts图表，加上实时数据推送，分辨率高的拼接屏上很容易卡顿。有几个优化经验非常实用：

第一，生产环境关闭动画。ECharts的setOption默认带动画效果，在上百个点位实时更新时，动画会造成渲染压力。可以在第一次载入时播放入场动画，之后所有更新都设置animation: false。

第二，曲线数据用滑动窗口。图表只保留最近1小时的数据点，新数据进来时从数组尾部追加，头部弹出旧数据，避免内存无限增长。这是最简单也最有效的防卡顿手段。

第三，热力图更新用setData而不是整体setOption。ECharts支持只更新数据数组，局部刷新比全量重绘快几个数量级。实测同样的页面，改成setData之后刷新率从2秒一次提升到1秒一次不卡顿。

第四，不可见的区域暂停更新。大屏如果有多个标签页或弹窗，把显示区域之外的图表设成暂停数据更新状态，等它重新可见时再恢复。这个优化对多图表页面效果非常明显。

实测做完这些优化，一台55寸4K拼接屏跑完整套大屏，数据1秒刷新一次，CPU占用能控制在20%以下，流畅度是够用的。

5. 部署过程中踩过的坑和排查实录

5.1 RS485通信失败，终端电阻和地址冲突

项目刚上电调试的时候，机房某个区域的所有传感器都读不到数据。排查过程从接线开始，测量了A/B脚电压，检查了串口服务器参数，最后发现是RS485总线末端没有加终端电阻。RS485是差分信号，长距离传输时信号在末端会发生反射，造成波形畸变，通信就废了。解决办法是在总线最远端的两个终端之间并联一个120欧姆电阻。接上之后，通信立刻稳定，数据正常上报。

另一类问题就是之前提到的Modbus地址重复。两台传感器地址都是1，串口服务器同时收到两条响应报文后数据错乱，一会儿显示A点位的数据，一会儿显示B点位的数据，极其迷惑。后来我规定：每一台传感器安装完，当场用调试工具读一次地址，确认全局唯一后做标签贴纸记录，杜绝“先装上再说”。

5.2 网络型传感器IP冲突导致数据掉线

以太网直连的传感器，上电后如果IP冲突，数据就会出现间歇性丢失。机房网络里有大量设备在用DHCP，IP被占用的概率比你想象的高很多。这个问题通常发生在夜间某个设备重新申请IP的瞬间，白天可能完全看不出来。

我的解决思路是给所有传感器分配静态IP，并在交换机上做IP-MAC绑定。这样即使网络中还有其他DHCP服务，传感器也不会被分配到冲突地址；就算有人手动改掉传感器IP，交换机也会拒绝非绑定MAC地址的IP访问。另外，传感器的管理口和业务口如果支持分离，尽量开启，避免配置数据干扰采集数据。

5.3 大屏数值延迟和曲线时间漂移

联调阶段，值班人员反馈大屏上的数值总比现场仪表慢半拍，而且趋势曲线的时间轴对不上。排查之后发现两个原因：

第一个是时间基准不统一。传感器内部时钟、服务器系统时间、前端浏览器时间三个基准不同步，导致打点时间偏差。解决方法是在服务端统一用NTP校时，数据入库时统一打服务端时间戳，前端不做任何时间换算，只负责展示。

第二个是数据链路上的延迟。最开始的设计是采集服务更新Redis，前端定时从Redis读数据，中间有轮询间隔，给人“慢半拍”的感觉。改成WebSocket主动推送后，端到端延迟从秒级降到几十毫秒级别，曲线时间轴严丝合缝。

5.4 告警误报压测实战与处置逻辑

联调阶段最头疼的是误报。空调检修会带来温度波动，传感器通信偶发超时会带回几个异常值，如果这些都被当成告警，系统很快就会失去可信度。我的处理思路是三维叠加判断：

第一，时间维度。温湿度值必须连续3个采集周期都超过阈值，才算有效告警。偶发尖峰自动过滤。

第二，空间维度。相邻点位是否同时异常。如果一个点的温度飙升，但旁边的点正常，大概率是传感器故障或者局部遮挡，不是真实环境恶化。多点同时异常，才说明是空调或整个机柜的问题。

第三，状态维度。传感器通信超时或设备离线时，直接判为数据无效而不是告警。等恢复在线后再评估。

这三个条件都满足才会触发告警。虽然响应时间多等了几个采集周期，但误报率大幅下降，值班人员对系统信任度明显上升。这个逻辑我建议在规划阶段就写清楚，别等上线后天天被误报骚扰再补。

6. 复盘与个人心得

这个项目整体做下来，我的体会可以用三句话概括：点位台账是命根子，双协议是灵活性的基石，可视化大屏做出价值靠的是人机交互而不是花哨效果。

点位台账这个事怎么说都不为过。传感器装得再多，如果地址表、位置标签、校准记录一塌糊涂，后面运维就是灾难。一次半夜告警，值班人员想快速定位是哪个机柜，如果台账不给力，分分钟变成全机房排查。我在这个项目里把台账做成了在线表格，每次新增点位或者变更配置都实时更新，排障效率高出不少。

双协议方案在前期确实多花了一点调试时间，但后期的扩展性太舒服了。这周加一个机柜，传感器支持以太网直连，插网线配好IP，在配置表里加一行就行，采集服务自动接入。那种后期扩容还要改架构、改采集逻辑的方案，做一次就怕一次。

可视化大屏的具体技巧可以复刻，但关键是理解它服务的场景。大屏的最终使用者是值班员和运维主管，不是参观的领导和来访客户。所以信息层级、告警提示、操作流畅度，都比视觉效果重要。我把热力图放在正中间、把告警做成两级提醒、给每张图加了操作反馈，都是为了让真实使用者能更快做决策。

最后再分享一个实用小技巧：传感器部署时一定要在机柜进风口和出风口各装一个探头。进风口温度代表设备实际进风温度，直接影响设备稳定性和寿命；出风口温度能判断设备发热程度、散热是否正常。只在一个位置安装，数据就是片面的，温度异常往往要到很严重的时候才能被发现。这个细节，装的时候多一根线，用的时候少几场事故。