企业官网建设流程全解析

1. 项目概述：FUXA 是什么，为什么你的下一个 HMI 项目可以选它

先说结论：FUXA 是一个开源的可视化组态工具，简单理解就是一套跑在浏览器里的 SCADA / HMI 系统。过去做工业监控界面，一般绕不开 WinCC、组态王、InTouch 这类传统上位机软件，不仅授权贵，而且部署和远程访问都有不少限制。FUXA 这类基于 Web 的方案出现后，情况变了不少：你只要打开浏览器，就能看到设备实时数据、操作画面、历史趋势，甚至在手机上也能盯现场。

它本身支持通过 Modbus TCP、OPC UA、MQTT、Siemens S7 等协议采集数据，也能把 Redis、MySQL 之类的系统数据接进来展示。换句话说，它不只是画界面，还能真正和设备通信，做数据采集、报警、存储，算是一套轻量级的 Web SCADA 平台。

那为什么偏偏选 Docker 部署？我自己在几个小项目里折腾过手工装 Node.js 环境、配数据库、处理依赖冲突，说实话挺痛苦的。Docker 方案把运行环境、依赖、启动命令全部封装好，一条命令起来，换机器迁移也方便，对工业现场或者个人实验来说都友好很多。这篇内容适合三类人看：一是刚接触组态软件、想低成本验证 Web HMI 方案的工程师，二是需要快速搭建演示系统的售前或实施人员，三是自己在家里折腾物联网项目、想搞个可视化面板的开发者。整篇内容会从部署思路讲到实际操作，最后把踩过的坑一起列出来，照着做基本上半小时内能跑起来。

2. 部署前的准备工作与整体思路拆解

2.1 为什么用 Docker 而不是直接装软件

任何一个组态软件要真正跑起来，后端运行环境、前端静态资源、数据存储这些模块一个都少不了。FUXA 基于 Node.js，手工部署需要先装 Node、装 npm 依赖、配置环境变量、再用进程守护工具管理启动，中间只要某个依赖版本不对，启动时就是一堆报错。而用 Docker 之后，这些环节全被镜像固化掉了，你不需要关心宿主机上有没有 Node，也不用担心污染现有环境。

更重要的是版本管理。FUXA 官方在 Docker Hub 上持续发布新版镜像，旧版本的配置、画面工程文件可以导出备份，升级时换一个镜像 tag 重新启动，回滚也方便。这在工业现场是刚需，毕竟生产环境最怕"升级升出问题又回不去"。

2.2 部署前需要先想清楚的几个问题

部署之前，先花两分钟想清楚三个问题，能少走弯路。

第一个是数据怎么来。FUXA 本身支持直接连接 PLC、传感器网关或者 MQTT Broker，如果你的场景里还没有真实设备，也可以用 Modbus 模拟器生成数据，先把界面流程跑通。建议第一版先别接真实设备，用一个模拟数据源调试画布、变量、控件的联动关系，等逻辑没问题了再切真实采集。

第二个是网络规划。Web SCADA 一个典型优势就是远程访问，但千万别一上来就把端口暴露到公网。稳妥的做法是先在内网跑通，外网访问时通过网关或者跳板机做一层转发，再配上认证。FUXA 自带登录账号体系，默认密码一定要改，这个后面实操部分我会专门提。

第三个是数据持久化。Docker 容器本身是"一次性"的，删掉重建数据就没了。FUXA 的画面工程、用户配置、历史数据都存在工作目录下，所以部署时必须把目录挂载出来。这一步做好了，后续升级、备份、迁移都非常轻松。

2.3 我选择的镜像与版本策略

FUXA 官方镜像在 Docker Hub 上的名字是fuxa/fuxa，长期维护，发布节奏也比较稳。我习惯优先用带具体版本号的 tag，比如fuxa/fuxa:1.1.0，而不是直接用latest，因为生产环境里镜像一旦更新，不经过测试就直接pull可能会引入未知变化。

这里多说一句，如果你在国内服务器上拉镜像慢，可以给 Docker 配置一个镜像加速器。具体怎么配这边不展开，核心是确认docker pull fuxa/fuxa能顺利把镜像拉下来，部署就算成功了一半。

3. Docker Compose 部署 FUXA 完整实操

3.1 编写 docker-compose.yml 并理解每个参数

我建议直接用 Docker Compose 部署，因为相比裸docker run，Compose 文件把端口、存储卷、重启策略、环境变量都集中在一份文件里，方便版本管理和团队协作。先看一个最精简的docker-compose.yml：

version: "3.8" services: fuxa: image: fuxa/fuxa:latest container_name: fuxa restart: unless-stopped ports: - "1881:1881" volumes: - ./fuxa-data:/usr/src/app/data environment: - FUXA_PORT=1881

这个文件里每个配置都有实际意义：

• restart: unless-stopped是工业场景里非常关键的策略。现场设备断电重启后，Docker 服务会自动把 FUXA 容器拉起来，不用人工干预。
• ports: "1881:1881"是 FUXA 的默认 Web 服务端口，左侧是宿主机端口，右侧是容器内端口，如果 1881 被占用，可以把左侧改成任意空闲端口。
• volumes: ./fuxa-data:/usr/src/app/data把容器内的数据目录映射到宿主机当前目录下的fuxa-data文件夹。FUXA 的画面、用户、配置都写在这个目录，后期备份只拷这个文件夹就够。

还有一个常见需求是 HTTPS。直接让 FUXA 处理证书比较麻烦，更推荐的组合是用 Nginx 反向代理对外提供 443 端口，证书管理放在 Nginx 这一层。这个模式等画面做完之后再配也不迟，第一版先保证内网能流畅访问。

3.2 启动、验证与初始登录

文件写好后，在同目录执行：

docker compose up -d

-d参数是后台运行，启动完成后看日志：

docker logs -f fuxa

第一次启动会看到服务初始化、数据库准备相关的日志，等到出现类似服务监听端口的信息，就说明起来了。浏览器访问http://服务器IP:1881，会进入登录页。

FUXA 第一次启动时会自动创建管理员账号，默认通常是admin，初始密码也是admin。这里强烈建议登录后第一时间改掉，因为这类系统一旦暴露在网络里，默认口令被扫描到就是分分钟的事。

登录进去之后，你会看到左边一栏的工程树、上方的菜单栏和中间的空白编辑区。第一次进可能会觉得界面工具挺多，其实核心概念就三个：工程、画面、变量。工程是容器，画面是你画的监控界面，变量是设备和界面之间的"数据通道"。后面的操作基本围绕这三样展开。

3.3 关于数据目录和备份的实操习惯

部署好之后，我习惯把整个项目目录固定下来，比如放在/opt/fuxa/app下，每天定时把fuxa-data目录压缩备份到另一台机器或者对象存储里。组态最值钱的东西从来不是软件本身，而是你花时间一点点画出来的画面和配置好的变量。备份做得好，哪怕整台服务器出问题，新机器上部署容器再把数据目录一恢复，画面和配置就全回来了。

4. 创建第一个 SCADA 画面与核心功能配置

4.1 新建画面：从空白画布到第一个监控界面

登录后先新建画面。在左侧工程树里找到对应位置，右键或者点菜单里的新建画面，会生成一张空白画布。FUXA 的操作方式和大部分组态软件类似，画布左侧是控件库，右边是属性配置区域。

画布第一步是设置尺寸。建议先想清楚这个界面主要用在什么屏幕上，是 1920 宽的工业大屏，还是普通的 1366 笔记本，又或者是手机竖屏。每种场景的布局逻辑完全不同。大屏适合放总览图、实时趋势，手机端则要突出关键报警和核心参数，交互按钮要够大。

控件放置直接拖拽就行。常用的有文本显示框、数值显示、开关按钮、仪表盘、实时曲线、报警列表。初始阶段别追求花哨，优先把"数据能不能显示出来"跑通，再考虑美观。我用 FUXA 的第一个正式画面就是从三块组成的：顶部是产线名称和当前时间，中间是设备运行状态和关键参数，底部是报警列表。

4.2 变量配置：画面和数据的桥接

画面是"壳"，变量是"魂"。在 FUXA 里，变量管理是核心中的核心。创建变量时，你需要设置变量名、数据类型、采集方式，以及在选择了通信协议后对应的地址参数。举个例子，如果你用 Modbus TCP 连接一个 PLC，需要填从站 IP、端口、寄存器地址、寄存器类型和数据格式；如果你用 MQTT，则需要配置订阅的主题和消息解析规则。

这里特别想聊一下我踩过的一个坑：数据类型一定要和实际设备保持一致。PLC 里一个 32 位浮点数寄存器和两个 16 位整数寄存器在 FUXA 里的解析方式完全不同，如果选错类型，画面上显示的数值就会变成一堆莫名其妙的天文数字。我最早调试变频器频率时，明明读取到 50.00 Hz，界面上却显示 0x4248 对应的整数，后来排查出来就是数据格式配置错了。

变量配置完之后，画面上的控件绑定变量就能"活"起来。比如拖一个数值显示控件，在属性里关联刚才创建的变量，运行时它就会自动刷新显示实时值；拖一个开关按钮，关联一个写类型的变量，就能实现远程启停操作。注意区分读变量和写变量，有些变量用于显示，有些用于控制，权限划分在正式项目里也要提前规划。

4.3 Select Value 控件的使用心得

之前看到很多人在搜索框里找 "FUXA Select Value 控件怎么用"，正好这个控件我研究过一阵子。它的作用是让一个控件在多个值之间切换，常用于操作员手动输入设定值，或者切换不同的工作模式。

使用步骤其实不难。先把控件拖到画布上，然后在属性里配置关联变量，以及设置一组"显示值-实际值"的映射，比如显示"手动"对应数值 0，显示"自动"对应数值 1，显示"远程"对应数值 2。实际运行中操作员选择"自动"，写入变量的就是 1，PLC 拿到这个整型值去控制逻辑。

要注意的是映射值和实际值必须匹配设备端定义的协议。有些国产 PLC 或者仪表，内部是用字符串表示模式，那就得先把字符串转成数字再映射。另外一个细节是面对操作员的画面，选项文案用中文或者行业术语会比裸数字直观得多，这也是 Select Value 控件存在的意义。

4.4 报警、趋势与历史数据的个性化补充

一个基本合格的 SCADA 画面，除了实时数据，还得有报警和历史趋势。FUXA 支持在变量上配置报警上下限，触发之后报警列表控件会显示出来。报警阈值怎么设，要结合工艺要求来，不能只看默认值。比如测的是电机绕组温度，上限 85 度、高高限 95 度这种设置就比随便填一个 100 更有工程意义。

历史趋势方面，FUXA 可以把采集的数据存到内置数据库中，趋势控件按时间范围查询。我习惯在画面上放一个"近 1 小时""近 24 小时"的快捷切换按钮，方便现场人员快速定位波动情况。数据存储的精度和周期也可以在配置里调整，如果采集频率太高且数据量大，建议适当降低存储频率，避免长时间运行后数据库膨胀严重。

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

5.1 容器起不来怎么办

最典型的错误就是端口被占用，启动日志会直接告诉你监听失败。排查顺序是：先用docker compose ps看容器状态，再用docker logs fuxa看日志，最后用netstat -tlnp | grep 1881检查端口占用。解决方案就是改宿主机端口映射，比如"1882:1881"。

另一个常见问题是数据目录权限异常。如果挂载的宿主机目录访问权限不对，容器内进程可能无法写入文件，表现就是启动看似正常，但一保存工程就报错。解决方法是给目录设置合适的属主，chown -R 1000:1000 ./fuxa-data或者直接chmod -R 777（内网环境图省事可以，生产环境不建议）。

5.2 页面能打开但看不到实时数据

这个问题大概率出在变量采集配置上。先确认设备通信是否正常：Modbus 设备能不能 ping 通、端口通不通、MQTT Broker 是否有消息流入。一个巧妙的排查方法是，在 FUXA 的运行时画面按 F12，打开浏览器开发者工具，看网络请求里有没有定时获取数据的请求，如果有但数据为空，那就是变量配置的问题；如果连请求都没有，那就是画面控件绑定或者服务配置的问题。

还有一次我碰到过更隐蔽的：服务正常、变量配置也没问题，但就是某些变量不刷新。后来发现是变量地址填错了一位，和另一组变量冲突了。FUXA 对重复地址不一定会给明确报错，但数据会互相覆盖，这种问题要亲自对照设备端寄存器表逐项核对。

5.3 操作无响应或控制指令发不出去

控制类操作无响应，先分清是界面问题还是通信问题。界面上按钮能点击、状态有反馈，但设备没动作，多半是写变量的地址、功能码或数据类型不对。另一种情况是有反应但被设备拒绝，这就要检查设备的写权限设置，有些 PLC 程序里故意锁定了某些寄存器的写操作，FUXA 这边再对也没用。

控制指令还有一个安全习惯：涉及启动、急停、写设定值这类操作，务必在设备端做好权限确认和硬件急停兜底，软件只做界面层控制，安全回路不能依赖 SCADA 一层。这个不只是 FUXA 特有的问题，是所有 Web HMI 项目都通用的原则。

5.4 一个排查速查表

5.5 几个值得养成的操作习惯

第一，每次改完工程要做备份导出。FUXA 支持将工程导出成文件，放到版本管理里，画面改动有迹可循，出问题可以随时回退。第二，定期检查 Docker 日志大小，长时间运行后日志文件容易膨胀，可以在 compose 里加上日志轮转配置，比如限制单个日志文件大小和保留份数。第三，对容器做资源限制，避免异常情况下进程吃满服务器 CPU 内存影响同机其他服务。

6. 一点我在实际项目里的经验

前阵子帮一个朋友做小型产线监控，从确认需求到 FUXA 跑出第一版完整画面，包含 20 多个变量、报警和趋势，总共只花了一个周末的晚上。这在以前用传统组态软件根本不敢想，光授权申请和软件破解就够折腾好几天。FUXA 加 Docker 的组合让整个交付过程轻量化了太多，后续现场要加新设备、新画面，远程连上服务器改配置就能完成，不用专门跑一趟现场。

最后分享一个小技巧：调试阶段不要直接在正式画面上改，多建几个测试画面或者直接用独立的测试工程，等逻辑确认没问题了再合并进正式工程。我就因为贪方便在正式画面上反复实验，结果忘记删掉测试按钮，差点让现场操作工点了不该点的东西。卡在这个点上吃过一次亏之后，我现在所有组态项目都坚持先测试后发布，这不仅是对自己负责，也是对现场负责。