企业官网建设流程全解析

聊聊最近刚收尾的这个项目：上海某制造工厂的三块车间大屏，做一套可视化电子看板系统。以前车间数据全靠班组长手动报数，产量、设备状态、不良率都滞后半天，这次一次性部署了三块1.8米大屏，分布在三个不同楼层，要求每块屏侧重点不一样，但又必须保证数据实时同步显示。说实话，画图表本身不难，真正卡人的是"多块大屏同步"这六个字——时间基准、推送机制、断线重连、分辨率适配，全是坑。这篇全指南我不讲虚的，从硬件接线、网络规划，到前端大屏可视化、同步数据调试，把整个落地过程完整摊开。你在做工厂可视化、电子看板，或者任何需要多屏同步显示的项目，这篇可以直接抄作业。

1. 项目整体设计与同步方案选型

1.1 需求还原：同源不同屏

先还原一下现场需求。工厂一共三层，每层一块竖装大屏：

• 一楼大厅：面向访客和领导，展示总产量、设备综合效率（OEE）、订单完成率这类宏观指标。
• 二楼车间：面向班组长，展示产线实时节拍、当前工单进度、设备运行/停机状态。
• 三楼质检区：面向质检员，展示不良率趋势、缺陷TOP排行榜、抽检合格率。

三块屏信息侧重完全不同，但底层数据必须来自同一套生产系统——这就是"同源不同屏"。很多工厂项目在这里就掉坑了：每块屏单独对接数采接口，结果二楼和三楼看到的不良率都不一样，因为两个接口的查询时间差了十分钟。

我的设计原则很简单：所有屏只连一个数据出口，不各自对接底层设备。每块屏配一台迷你工控机，大屏本身只是显示器，真正的"电子看板"跑在工控机里。这也是目前工厂可视化看板项目的主流玩法：屏是显示屏，脑子是工控机，后端只维护一套数据服务。

1.2 同步机制选型：轮询、WebSocket还是MQTT？

这是整个项目最核心的技术决策。我当时对比了三条路：

最后选了 WebSocket + Redis 方案，原因有三点：

1. 工厂数据来源不止一个——PLC、MES接口、人工录入Excel导入，不同来源写入时间不一致。中间加一个 Redis 做统一状态存储，相当于一个"数据汇总缓冲区"，避免多数据源直接怼到前端，导致同一时刻各屏读到的值不一致。
2. WebSocket 是浏览器原生支持的协议，前端不用额外引库，Vue项目里封装一个连接管理器就能用，省去维护 MQTT broker 的负担。
3. 三块屏加上后续可能加的移动端，撑死几十个连接，WebSocket 长连接在这个规模下实测非常稳，没有必要上更重的消息队列。

这里的核心知识点是：多屏同步的本质不是"同时刷新"，而是"同一时刻看到的快照必须一致"。服务端先把所有客户端拿到的数据写成同一个 Redis key，再整体推送给所有大屏，而不是各屏自己查数据库。这一步做好了，同步问题就解决了一大半。

1.3 可视化设计：图表是给人看的，不是给机器看的

可视化电子看板最容易犯的毛病，是把所有图表塞进一块屏里，五颜六色什么都想展示，结果现场工人根本找不到关键信息。这个项目的可视化设计我遵循了三个原则：

• 一屏一主题：每块屏只回答3-5个核心问题，一楼回答"今天卖了多少"，二楼回答"现在哪里停了"，三楼回答"质量行不行"。
• 大数字优先：核心指标直接用超大数字展示，次要信息才用图表，人站在三米外也能一眼看到产量数据。
• 配色克制冷静：深蓝底 + 高亮色点缀，避免红绿黄满天飞，看久了眼睛不累。

前端图表用的 ECharts，它是目前做可视化大屏最成熟的开源库，各种企业大屏可视化项目里几乎都是标配。像我这种场景，一个折线图加两个环形图加数字翻牌器，ECharts 全都能覆盖，而且性能稳定。需要提醒的是，ECharts 版本升级很快，老项目升级要小心配置项不兼容，锁定版本号是个好习惯。

2. 核心细节解析与实操要点

2.1 数据链路怎么搭：五层架构

一套典型的工厂可视化大屏数据链路长这样：

设备层 → 采集层 → 汇聚层 → 推送层 → 渲染层

• 设备层：PLC、传感器、MES系统、人工录入表。
• 采集层：通过串口、网口、Modbus TCP、OPC UA 等方式把设备数据取出来。这一步最杂，各家设备协议不一样。
• 汇聚层：采集到的数据清洗后写入 MySQL 做持久化，同时把最新状态写入 Redis。Redis 存的不是历史明细，而是"当前快照"。
• 推送层：Node.js 写的长连接服务，监听 Redis 的变更，一旦有更新就把最新快照通过 WebSocket 广播给所有客户端。
• 渲染层：Vue + ECharts 的大屏页面，接收推送后刷新图表。

这个架构最关键的巧思在汇聚层：MySQL 管历史，Redis 管现在。大屏显示的是"现在"，所以前端查询接口一律走 Redis，查询速度毫秒级，而且因为大家读同一个 key，天然保证一致。如果前端直接查 MySQL，不仅要面对慢查询问题，还容易出现"二楼刚查到的是旧数据，一楼刚查到的是新数据"的尴尬。

2.2 多屏同步的三个关键点：时间、状态、连接

多屏同步不止是推送消息那么简单，实操中要抠三个细节：

时间基准统一。如果每块屏的工控机时间不一致，就算显示的是同一份数据，看板的更新时间戳也会互相矛盾。这一步看起来小，但实际现场很容易被忽略——工控机重启后 CMOS 电池失效，时间回到出厂值，所有看板的时间戳全乱了。解决办法是部署 NTP 时间同步，让所有工控机和服务器对同一台 NTP 服务器校时。

状态一致性。服务端推送的不只是数值，还要带一个"批次号"或"快照ID"。比如每次数据更新生成一个自增ID，客户端收到推送后如果发现批次号小于当前值，就丢弃旧消息。这个方法在 WebSocket 网络抖动时有奇效，能避免旧消息覆盖新数据导致画面闪烁回跳。

连接心跳与断线重连。大屏的工控机长期通电运行，网络设备偶尔重启，WebSocket 连接很容易静默断开。前端必须实现心跳检测（每30秒发一个 ping，服务端回 pong），以及指数退避的重连机制。实测下来，不加心跳的看板，运行一周后总有一两块屏"静默失联"，页面也不报错就是数据不动了，加上心跳和自动重连后，这个问题彻底消失。

注意：断线重连后一定要主动拉一次最新快照，不能光等推送。因为断线期间可能错过了多条增量信息，只靠重连后的第一条推送，数据会缺一段时间。

2.3 大屏适配与分辨率处理

三块屏虽然尺寸一样，但工控机显卡输出分辨率不完全相同，有的设成了 1920x1080，有的被系统改成了 1366x768。如果前端页面写死像素，会出现图表拉伸、字被截断。

我的做法是用比例缩放适配：前端页面按 1920x1080 设计，然后通过 JS 获取实际屏幕宽高，计算出缩放比例，用 CSS transform: scale() 整体缩放根容器。这种方法比写响应式布局简单得多——复杂图表密集的大屏页面，逐个做响应式太费时间，整体缩放虽然左右会有黑边，但胜在稳定可控。

如果项目预算允许，更推荐的做法是用可编程的 HDMI 分配器或者带缩放功能的拼接控制器，但这属于硬件方案，成本高出不少。软件缩放对于工厂车间场景已经完全够用。

3. 实操部署与调试全流程

3.1 硬件环境与网络规划

这个项目用到的硬件：

• 3台迷你工控机（i3处理器、8GB内存、128GB SSD），分别驱动三块大屏。
• 1台服务器/工控机，跑数据采集、Redis、Node.js 推送服务。
• 1台千兆交换机，把服务器和所有工控机组成局域网。
• 若干六类网线，全走有线，不用WiFi——车间里电焊、变频器干扰多，WiFi 在大屏这种持续占用带宽的场景下不稳定。

网络规划直接在交换机上做静态 IP：

这里建议所有设备关掉 DHCP，全走固定IP。因为看板系统依赖工控机自动启动浏览器并访问固定地址，如果IP变了，页面就白屏了，现场没有人天天去改配置。

3.2 服务端推送与前端渲染核心代码

推送服务用 Node.js 实现，核心逻辑分三块：WebSocket 服务、Redis 读取、定时广播。贴一段简化但可直接运行的代码：

// server.js const WebSocket = require('ws'); const Redis = require('ioredis'); const redis = new Redis({ host: '192.168.1.20', port: 6379 }); const wss = new WebSocket.Server({ port: 8080 }); // 客户端连上后，先推一次最新快照 wss.on('connection', async (ws) => { const snapshot = await redis.get('dashboard:snapshot'); if (snapshot) { ws.send(JSON.stringify({ type: 'snapshot', data: JSON.parse(snapshot) })); } }); // 每5秒从Redis取最新快照，广播给所有客户端 setInterval(async () => { const snapshot = await redis.get('dashboard:snapshot'); if (!snapshot) return; const message = JSON.stringify({ type: 'update', ts: Date.now(), data: JSON.parse(snapshot) }); wss.clients.forEach((client) => { if (client.readyState === WebSocket.OPEN) { client.send(message); } }); }, 5000);

前端页面用 Vue + ECharts，核心是封装一个 WebSocket 管理器：

// useDashboardSocket.js export function useDashboardSocket(url) { const socket = new WebSocket(url); let heartbeatTimer = null; function connect() { socket.onopen = () => { // 连接建立后，每30s发心跳 heartbeatTimer = setInterval(() => socket.send('ping'), 30000); }; socket.onmessage = (event) => { const msg = JSON.parse(event.data); if (msg.type === 'update' || msg.type === 'snapshot') { // 更新Vue响应式数据 updateCharts(msg.data); } }; socket.onclose = () => { clearInterval(heartbeatTimer); // 指数退避重连，5s起步，最多60s setTimeout(connect, Math.min(60000, 5000 * Math.pow(2, retryCount++))); }; } connect(); }

一定要在后端写入 Redis 的位置加一个日志输出，调试期间这是最直接的排查依据。实际项目中，数据写入 Redis 用的是 Python 脚本，从 PLC 采集到数据后组装成 JSON，再redis.set('dashboard:snapshot', json.dumps(payload))。这个脚本我会在下文调试章节详细说。

3.3 调试工具实战：串口/网口助手与浏览器调试

工厂里的设备调试，离不开两样工具——串口调试助手和网口调试助手。这两样是这个项目的调试主力。

串口调试助手用在与 PLC 通过 RS485 对接的场景。当时调试一台老型号 PLC，通信参数设为 9600 波特率、8 数据位、1 停止位，用串口助手发 Modbus RTU 报文，直接能看到 PLC 返回的原始字节：

发送: 01 03 00 00 00 02 C4 0B 接收: 01 03 04 00 00 02 58 3B 44

如果接收到的数据是乱码，先从波形和字节流排查：波特率对不对，校验位是不是无校验，线是不是 A/B 接反了。串口调试里 90% 的问题出在这三点，而不是程序逻辑。

网口调试助手用来测支持 Modbus TCP 的设备。当时一台新设备的通信地址不确定，用网口调试助手直接建 TCP 连接发 Modbus 报文探路，比写程序调试快得多。网口调试助手的另一个妙用是本地起一个假的 TCP 服务，验证采集脚本连接逻辑，不用每次都跑到车间设备跟前。

浏览器开发者工具在前端阶段非常好用。WebSocket 的帧在 Network 面板里能看到，断线重连、消息间隔一目了然。前端有任何报错，Console 面板立刻能看到。多块大屏联调的时候，我习惯在每台工控机上打开同一个监控页面，三台工控机并排开三个浏览器窗口，同时盯着数据变化判断同步是否正常。

3.4 Redis 状态验证与可视化工具

前面提到 Redis 存的是"当前快照"，调试期间必须确认这个 key 在实时更新。直接用命令行比较原始：

redis-cli -h 192.168.1.20 GET dashboard:snapshot

但现场用命令行不够直观，我用了一个 Redis 可视化管理工具，能看到所有 key 的列表和 TTL，还能直接编辑 JSON 结构。这个工具在处理复杂嵌套数据时特别好用——前端报读不到字段，打开工具看一眼 Redis 里存的结构，立刻知道是 key 打错了还是层级不对，省掉了来回打印日志的功夫。

经验分享：工厂项目上线初期，一定要保留数据回放的"后悔药"能力。我在推送服务里加了一个简单的文件日志，每5秒记录一次快照内容。一旦现场反馈看板数据不对，翻日志就能定位是采集错了、Redis 里写错了，还是前端渲染错了，三个环节十分钟内就能分清责任。

4. 常见问题与排查技巧实录

4.1 屏与屏数据差了几秒

上线第一天就遇到这个问题：一楼和二楼的数据总差五六秒，三楼有时候干脆停更。排查过程走了不少弯路，最终定位是浏览器标签页后台限流——工控机的浏览器因为长期无操作被系统判定为后台标签页，JS 定时器被降频，WebSocket 心跳其实还在，但渲染节流导致页面不刷新。

解决办法很粗暴：给工控机装了一个让浏览器保持前台模式的工具，或者直接把页面做成 Kiosk 模式全屏运行。另外，数据推送间隔从 5 秒改成 3 秒，减小每次推送的数据量，双管齐下后，三块屏的数据偏差降到了 1 秒以内。

4.2 大屏白屏和闪电断连

第二周三楼看板出现白屏，重启浏览器又恢复，但过几小时又白屏。排查时先看了推送服务日志，发现三楼工控机的 WebSocket 连接在反复断开重连，但其他屏正常。

后来去现场看工控机，发现它接的是车间同一个插线板，旁边有台大功率设备一启动，电压浪涌就导致网卡短暂掉线。换成 UPS 供电并加装了一个工业级交换机后，问题再没出现。工厂现场的硬件环境，永远比你想的恶劣，电磁干扰、电压不稳都是隐形杀手。

4.3 设备数据乱码与"幽灵数据"

对接到一台变频器数据时，串口调试助手收到的报文时而正常时而乱码。用网口调试助手做对比测试，发现故障只在现场那根 20 米长的 RS485 线路上出现。这属于典型的信号反射问题——没有加终端电阻，而且屏蔽层没有单端接地。

加了 120Ω 终端电阻后，乱码消失。另外提醒一句，RS485 的屏蔽层只能一端接地，两端接地反而会形成地环路干扰，这是新手很容易踩的坑。

4.4 排查速查表

把这次调试遇到的坑整理成表，方便现场快速对照：

5. 扩展应用与落地心得

5.1 从看板到数据库同步：对接更多业务系统

看板上线后，工厂发现这套同步机制不仅能显示设备数据，还能把 MES 系统的工单进度、ERP 的订单信息一起同步展示。这就需要把业务系统的数据库同步到可视化服务的数据库中来。

最开始我试过定时任务直接跨库查询，但业务库压力大，查询一多就锁表。后来改用了数据库同步工具，把业务库里的关键表增量同步到看板系统的本地库，再做二次加工。这样看板系统完全不依赖业务系统的实时接口，业务库也不会被看板查询拖垮。如果你要对接的系统和看板系统不在同一个网段，数据库同步软件几乎是必选项。

5.2 移动端与"领导驾驶舱"扩展

三块大屏稳定运行后，工厂提出新需求：领导在外面出差也想看数据。方案很现成——同一个 Node.js 推送服务，再加一个移动端适配的页面，手机浏览器访问同一个地址就有简化版的看板。因为底层数据源完全一样，移动端和大屏端天然同步，不用再做任何额外工作。

很多可视化项目走到这一步，都会顺理成章扩展成"领导驾驶舱"——用手机、平板、办公室电脑都能访问的一整套数据可视化系统。核心就是：把数据源和服务端做强，换前端皮肤只是工作量问题。

5.3 车间跑了半年后的一些维护建议

项目交付半年，我回访过两次，总结几条落地后的维护要点：

• 工控机硬盘是易耗品，建议 SSD 选工业级或至少带掉电保护，车间意外断电频繁，普通固态容易掉盘。
• 大屏长期显示静态画面会有烧屏风险，建议设置屏保或者每半小时切换一次背景图，LED屏这个问题少，但普通液晶拼接屏很常见。
• Redis 的 key 建议加过期时间，比如快照 key 设24小时过期，防止数据写入脚本停了之后前端还在展示昨天的假数据。这次项目就遇到过脚本挂了三天没人发现，大屏上的产量数字一直停在三天前，管理人员还以为数据是真的。
• 把调试工具都留一套在现场工控机上，包括串口调试助手、网口调试助手、Redis可视化管理工具和浏览器控制台快捷方式——现场维护的人不一定是你，但工具齐全能帮他们少走很多弯路。

我个人在实际操作中最深的体会是：多块大屏可视化的技术难度并不高，真正的复杂度全部来自工厂现场的不确定性。网络忽好忽坏、电压忽高忽低、浏览器自动更新、Windows 半夜自动重启——这些日常开发中根本不会注意的细节，在车间环境里全都会变成事故。所以做这类项目，别只顾着写代码和画图表，多花时间在硬件稳定性、断线重连、异常自恢复这些"不起眼"的地方。看板系统能百分之九十的时间在线稳定运行，比任何炫酷的可视化效果都重要。

最后再分享一个小技巧：所有工控机的浏览器主页锁定为看板地址，并设置开机自启浏览器。配合 Windows 计划任务，每天早上打卡前页面已经自动加载好。对于工厂用户来说，他们不需要知道什么是 WebSocket，也不用学怎么打开浏览器，他们要的就是"走到大屏前，数据就在那"——这才是电子看板项目落地的最终标准。