1. 为什么我最终选了 Node-Red 做本地物联网中枢

搞物联网项目的人大概都有过这种纠结：传感器数据上来了，想做个联动逻辑，写代码吧，改一行就得重新烧录或者重启服务；用现成的平台吧，又担心数据不在自己手里，或者设备一多就要加钱。我前后折腾过几种方案，最后把本地这套东西稳定跑起来的核心工具，是 Node-Red。

Node-Red 是什么？一句话讲，它是一个基于浏览器的可视化编程工具，用拖拽节点、连线的方式来实现数据流转和逻辑控制。你打开浏览器访问本地的 1880 端口，就能看到一个画布，左边是各种节点，中间是工作区，右边是调试输出。把“传感器输入”节点拖进来，再拖一个“判断阈值”节点，再接一个“控制开关”节点，连上线，点部署，一套物联网联动逻辑就跑起来了。整个过程不需要你写一行 if-else，当然你想写也完全可以。

这个东西最早是 IBM 的团队做出来的，后来交给了 OpenJS 基金会维护，在智能家居、工业数据采集、边缘计算这些场景里用得非常多。它的核心价值在于三点：降低编程门槛、加速原型验证、数据完全本地化。你不需要懂 JavaScript 也能做出可用的逻辑，你只需要理解“数据从哪来、经过什么处理、到哪去”这条链路。

我见过很多做物联网毕业设计或者公司内部 demo 的人，卡住的地方往往不是硬件不会接，而是“数据上来了，我怎么快速让它有点用”。比如温湿度传感器读数上来了，想超过 30 度就打开风扇，低于 20 度就发个提醒。纯写代码，你需要搭一个后端服务，写接口，写判断逻辑，再写控制指令的下发。用 Node-Red，拖四五个节点，十分钟内就能跑通。

这篇文章适合谁看？如果你是刚接触物联网、想快速搭一个本地可视化控制中心的人，照着做就行。如果你是有经验的开发者，想找一个轻量的本地编排工具来串联 MQTT、HTTP、串口这些协议，Node-Red 也会让你觉得顺手。接下来我会从环境准备、安装、核心配置、实操流搭建、常见坑排查这几个层面，把我自己踩过的路完整拆一遍。

2. 搭建前的环境准备与安装方式选型

2.1 硬件和操作系统的选择建议

Node-Red 本体对硬件要求很低，这是它很大的一个优势。我自己在一台闲置的树莓派 4B（2GB 内存）上跑过，也在一台老旧的笔记本装了 Ubuntu Server 跑过，甚至还试过在 Windows 11 的 WSL2 里跑，体验都还行。如果你手头有树莓派、旧电脑、迷你主机、甚至 NAS，都可以拿来当本地物联网中枢。

操作系统方面，我给的建议是：长期运行优先选 Linux，尤其是 Debian 系或者 Ubuntu。原因是 Node-Red 本身是 Node.js 应用，在 Linux 下的进程管理、开机自启、后台运行都更顺手。Windows 当然也能跑，但如果你打算让它 7×24 小时挂着，偶尔重启或者系统更新会打断服务，这一点要有心理准备。

内存方面，512MB 能跑起来，但建议至少 1GB。因为除了 Node-Red 本体，你可能还会跑一个 MQTT Broker（比如 Mosquitto），这些加起来会占一些内存。存储的话，16GB 以上的空间足够，Node-Red 本身加上节点包不会太大，但你后面装的扩展节点多了，体积会涨。

提示：如果你打算用树莓派，建议把系统装在质量好一点的 SD 卡或者 SSD 上。我遇到过 SD 卡因为频繁写入日志导致损坏的情况，后来换成 USB SSD 启动就稳定多了。

2.2 安装 Node.js 运行环境

Node-Red 跑在 Node.js 上，所以第一步是把 Node.js 装好。这里有一个很多人会踩的坑：直接用系统自带的包管理器安装的 Node.js 版本往往太老。Node-Red 官方建议使用 Node.js 的 LTS 版本（目前是 18.x 或 20.x），版本太低会出现节点装不上、启动报错的情况。

在 Ubuntu 或 Debian 上，我习惯用 NodeSource 的源来装，过程很直接。先更新一下系统包列表，然后添加源、安装。更稳妥的做法是用 nvm（Node Version Manager）来管理版本，这样以后切换 Node.js 版本不会影响系统其他依赖。

安装完成后用node -v和npm -v确认一下版本号，两个命令都能正常输出就说明环境没问题。如果node -v显示的版本低于 18，建议先处理掉再往下走。

注意：不建议用sudo去全局安装 Node-Red 的 npm 包，因为后面安装节点包时容易出现权限问题。我自己的做法是用普通用户安装，需要开机自启的时候再用系统服务来管理。

2.3 三种安装方式的对比与选择

Node-Red 的安装大致有三种路子，我做了个对比，你可以根据自己的情况选：

我个人最推荐npm 全局安装，因为后期装扩展节点、升级版本都是最顺的。Docker 方案适合你已经有一套容器管理体系的情况，不然为了 Node-Red 单独去学 Docker 有点绕。树莓派官方脚本虽然方便，但它是把 Node-Red 作为一个系统服务来装的，后面想改配置文件的路径会和 npm 安装的不太一样，新手容易找不着文件。

npm 安装的核心命令就是在终端里执行安装指令，等它跑完，输入启动命令，看到终端输出访问地址，就说明装好了。默认情况下它会监听 1880 端口，你在浏览器里输入本机地址加端口号就能打开编辑器界面。

2.4 初次启动与界面认识

第一次启动 Node-Red，浏览器打开对应地址后，你会看到整个编辑器的布局。我简单说一下每个区域的作用，后面实操会反复用到。

左侧是节点面板，按类别折叠，包括输入、输出、功能、网络、序列化、解析、存储等。你需要的节点大部分都能在这里找到，找不到就说明要装扩展。中间是工作区，也就是你拖拽节点、连线的画布。右侧上方是侧边栏，默认显示信息选项卡，还有调试输出、帮助、配置节点等标签。右上角是部署按钮，你每次修改完流之后，必须点一下部署，改动才会生效。

这里有个细节值得注意：Node-Red 的流是保存在一个叫flows.json的文件里的，默认路径在用户目录下的.node-red文件夹中。如果你后面要迁移或者备份，直接拷这个文件夹就够了。我第一次用的时候不知道这一点，重装系统把流弄丢了，后来养成了定期导出流的习惯。

3. 十分钟快速上手的核心配置改动

3.1 设置管理员账号密码

刚装好的 Node-Red 是没有任何登录验证的，任何人只要访问到 1880 端口就能改你的流。如果你只是在本地测试，问题不大；但只要这东西接入局域网，就一定要把管理员密码设上。

具体怎么做？打开.node-red目录下的settings.js文件，找到adminAuth那一段，它默认是被注释掉的。你需要把它取消注释，然后填入用户名和密码的哈希值。这个哈希值不是明文密码，需要通过 Node-Red 自带的命令来生成。在终端里执行密码哈希命令，按照提示输入你的密码，它会输出一串加密后的字符串，把这串字符串填到adminAuth的password字段里，用户名自己定。

改完之后重启 Node-Red，再打开界面就会弹出登录框。这一步看起来简单，但我见过太多人部署完之后忘了设，结果局域网里谁都能进去改逻辑，挺危险的。

提示：改settings.js之后一定要完整重启服务，不是只刷新浏览器。我试过改完配置直接刷新页面，发现没生效，折腾了半天才发现是没重启。

3.2 调整时区和日志输出

Node-Red 默认用的是系统时区，但如果你在容器里跑，时区可能是 UTC。这会导致你调试输出里的时间戳和实际时间对不上，排查问题时很误导人。解决办法是在启动命令前加一个环境变量把时区设成 Asia/Shanghai，或者在settings.js里配置。

另外一个是日志级别。默认情况下 Node-Red 会输出不少信息到控制台，如果你把它当后台服务跑，日志会一直往文件里写。我建议根据你的需要调整日志级别，或者配置日志轮转，不然长期跑下来日志文件会把磁盘占满。我自己就遇到过日志写了几百兆的情况，后来配了 logrotate 才解决。

3.3 让 Node-Red 开机自启

如果你打算把它当常驻服务，那开机自启是必须的。在 Linux 上，最简单的方式是用 systemd 写一个服务单元。你需要创建一个 service 文件，指定启动命令、工作目录、运行用户、重启策略。

这里有一个实操细节：运行用户最好和当初安装 Node-Red 的用户一致。如果你用 A 用户装的，却用 root 或者另一个用户来启动服务，会出现权限问题，导致流文件读写失败。我踩过这个坑，当时流能打开但保存不了，排查了半天才发现是文件属主不对。

创建好 service 文件之后，执行启用命令，然后启动服务，再用状态查询命令确认它是不是在正常运行。如果状态显示 active (running)，那就说明配置成功了。

4. 拖拽式编程的核心逻辑与节点使用

4.1 理解消息对象 msg 的结构

Node-Red 里流动的数据叫消息，用msg表示。你拖的每一个节点，本质上都是在处理这个msg对象。它默认有几个属性：msg.payload是消息的主体内容，msg.topic是主题，msg._msgid是消息 ID。除此之外，你可以在节点里给它加任意自定义属性。

理解这一点非常关键，因为很多人刚开始用的时候，搞不清楚为什么这个节点输出的数据下一个节点读不到。原因往往是上一个节点把数据放在了msg.payload，而下一个节点期待的字段名不一样。比如 MQTT 输入节点收到的数据默认在msg.payload，如果你想在后面用msg.temperature，就得先用一个 function 节点做转换。

我用一个生活化的类比来解释：msg就像是一个快递包裹，payload是包裹里的物品，topic是包裹上的标签。每个处理节点就是分拣员，有的只看标签，有的只看物品，有的会往包裹里塞一张新纸条。你连线就是在决定包裹走哪条传送带。

4.2 常用节点类型与适用场景

我把经常用的几类节点列一下，方便你有个全局认识：

输入类节点包括 inject（手动触发）、mqtt in（订阅 MQTT 主题）、http in（接收 HTTP 请求）、serial in（读串口数据）。输出类节点包括 debug（调试输出）、mqtt out（发布 MQTT 消息）、http response（返回 HTTP 响应）、serial out（写串口）。

功能类节点是逻辑核心，change 节点用来修改、删除、移动消息属性，switch 节点用来做条件判断分流，function 节点用来写自定义 JavaScript，template 节点用来做文本模板渲染。这些节点是你搭建逻辑的主要工具。

网络类节点里 mqtt 相关的最常用，尤其是做物联网。解析类节点里 json 节点可以把 JSON 字符串转成对象，或者反过来。存储类节点可以把数据写到文件或者读出来。

刚开始用的时候不需要记全，知道大概有这几类，用的时候去左侧面板找就行。装扩展节点也很简单，在菜单里打开节点管理，搜索你要的功能，点安装。但我建议不要一上来就装一堆，先用内置节点把基础流跑通再说。

4.3 一个最小可运行流的搭建过程

我现在带你搭一个最简单的流，让你感受一下拖拽编程是怎么回事。这个流的功能是：手动点一下按钮，生成一个随机温度值，如果超过阈值就在调试窗口输出警告，否则输出正常。

第一步，从输入分类里拖一个 inject 节点到工作区。双击它，把 payload 类型改成数字，随便填一个值，比如 25。这个节点就是触发器。

第二步，从功能分类里拖一个 function 节点。双击打开代码编辑区，写几行逻辑：读取msg.payload，判断它是否大于 28，如果大于就把msg.warning设为 true，否则设为 false，最后return msg。这里的return msg是必须的，不写的话消息就断了。

第三步，从功能分类里拖一个 switch 节点。配置它根据msg.warning属性来判断，等于 true 走一路，否则走另一路。

第四步，从输出分类里拖两个 debug 节点，分别接到 switch 的两个输出上，把它们的输出标签改成“警告”和“正常”。

最后，把 inject 连到 function，function 连到 switch，switch 的两个出口分别连到两个 debug。点右上角部署，再点 inject 节点左边的小按钮，看右侧调试窗口的输出。

我实测这个流程，从打开界面到看到输出，大概三分钟。你如果跟着做一遍，对“节点、连线、部署、调试”这套流程就有感觉了。后面更复杂的流无非是节点更多、逻辑更长，底层机制是一样的。

5. 物联网实战：接入传感器与 MQTT 数据流

5.1 本地 MQTT Broker 的搭建与配置

做物联网离不开 MQTT，因为它轻量、省电、适合低带宽环境。Node-Red 只是一个数据处理和编排工具，它本身不是 MQTT 服务器。你需要一个 Broker 来中转消息。在本地搭建的话，Mosquitto 是最常见的选择。

在 Linux 上安装 Mosquitto 很直接，装完之后它默认监听 1883 端口。但默认配置只允许本地访问，如果你要用局域网内其他设备（比如 ESP32）发数据过来，需要改配置文件，允许匿名连接或者配置用户名密码。我建议是配置用户名密码，然后新建一个密码文件，用工具生成加密后的密码写入。

配置改完之后重启 Mosquitto 服务，用mosquitto_sub和mosquitto_pub两个命令行工具测一下，一个订阅主题，另一个往这个主题发消息，看看能不能收到。这一步通了，说明 Broker 没问题。

然后回到 Node-Red，拖一个 mqtt in 节点，双击配置。服务器地址填 localhost，端口 1883，主题填你测试用的那个主题，QoS 默认 0 就行。再拖一个 debug 节点接在后面，部署。这时候你用命令行往那个主题发一条消息，Node-Red 的调试窗口应该就能看到。

5.2 ESP32 传感器数据上报的格式设计

假设你手头有一块 ESP32，接了一个 DHT11 温湿度传感器。它通过 MQTT 往 Broker 发数据。这里有一个设计决策：数据格式用什么。我见过有人直接发一个数字字符串，也有人发 JSON 对象。我强烈建议用 JSON，因为后面处理起来方便，可读性也好。

一个典型的温湿度数据可以设计成这样：{"device_id":"esp32_01","temperature":26.5,"humidity":58,"ts":1712345678}。设备 ID 用来区分多个设备，时间戳用 Unix 时间戳，方便后面做数据存储和展示。

为什么强调格式设计？因为如果你有多个传感器，格式不统一的话，后面每接一个设备就要改一次流。我一开始就是每个设备单独接，后来设备多了之后流乱得没法看。后来我统一了格式，用一个流就能处理所有设备，通过msg.payload.device_id来区分是谁发的。

在 Node-Red 里，mqtt in 节点收到的 payload 默认是 Buffer 或者字符串。你需要接一个 json 节点把它解析成对象。解析之后，你就可以用 switch 节点根据设备 ID 分流，或者用 change 节点把温度值提取到msg.temperature里。

5.3 阈值告警与控制指令下发的实现

数据上来了，接下来就是让它有用。我举一个我自己做的场景：温度超过 30 度就通过 MQTT 发一条指令给一个继电器节点，让它打开风扇；温度低于 25 度就发指令关闭。

实现这个逻辑，核心是一个 switch 节点加两个 mqtt out 节点。switch 节点判断msg.payload.temperature大于 30 走一路，小于 25 走另一路。两路各自接一个 change 节点，把 payload 改成"on"或者"off"，再接到 mqtt out 节点，发布到控制主题上。

这里有一个容易忽略的细节：防止指令重复发送。如果温度一直在 30 度上下波动，你的流会不停地发 on、off、on、off，设备会频繁开关。我的做法是用一个 flow 变量记录当前状态，只有当状态发生变化时才发送指令。这个逻辑用 function 节点实现，读一下flow.get("fan_state")，判断后再flow.set，然后决定是否放行消息。

提示：flow 变量在 Node-Red 重启后会丢失，如果你需要持久化状态，可以用 context 存储或者写文件。我自己的做法是重启后默认关状态，然后等第一条数据上来再判断。

5.4 用 dashboard 节点做可视化面板

Node-Red 有一个很受欢迎的扩展叫 node-red-dashboard，装上之后你可以在编辑器里拖拽图表、开关、文本框，生成一个网页版的监控面板。这对于展示数据特别方便，尤其是做毕业设计或者给客户演示的时候。

安装方式就是在节点管理里搜索这个包名，点安装。装完之后左侧会多出一组 dashboard 节点。你把 gauge 节点拖进来，配置绑定到温度字段，设置量程和单位，再拖一个 chart 节点记录历史曲线。部署之后，dashboard 默认在/ui路径下，你访问那个地址就能看到面板。

我自己的经验是，dashboard 适合做“看一眼”的监控，不适合做复杂交互。它的样式定制能力有限，如果你想做很漂亮的界面，可以考虑把数据通过 Node-Red 的 HTTP 节点暴露成接口，然后自己写前端页面。但对于快速查看和演示，dashboard 完全够用。

6. 常见问题排查与实操避坑记录

6.1 启动报错与端口占用的处理

Node-Red 启动失败最常见的原因是端口被占用。1880 端口如果已经被别的程序用了，它会报错退出。你可以换一个端口，在启动命令里加参数指定，或者在 settings.js 里改uiPort的值。

另一个常见报错是 Node.js 版本不兼容。有些节点包要求 Node.js 18 以上，你如果用的是 16，安装时就会报错。解决办法就是升级 Node.js，用 nvm 切换版本是最省事的，切完版本重新全局装一下 Node-Red 就行。

还有一种情况是权限问题导致的无法写入流文件。前面提过，运行用户和安装用户不一致就容易出这个问题。排查方法是看日志里的错误信息，如果提到 EACCES 或者 EPERM，基本就是权限问题。把.node-red目录的属主改成实际运行用户就能解决。

6.2 节点安装失败的排查思路

在节点管理里装扩展节点时，偶尔会遇到安装失败。原因可能有很多：网络问题、npm 源太慢、依赖编译失败、Node.js 版本不匹配。我的排查顺序是这样的：

先看错误信息，如果卡在下载阶段，八成是网络问题，可以换一个 npm 镜像源试试。如果报错里有 node-gyp 或者编译相关的字眼，说明这个节点包含需要编译的原生模块，可能缺少系统编译工具，需要装 build-essential 和 python3。如果是版本不匹配，那就对照节点包的文档看看它支持哪个 Node.js 版本。

我印象比较深的一次是装一个串口节点，一直编译失败，后来发现是缺少 libudev 开发库。装上对应的系统包之后，重新安装就成功了。所以遇到编译类错误，不要急着重装，先去查这个节点依赖什么系统库。

6.3 消息丢失与流不触发的检查清单

有时候你会觉得流明明搭好了，但就是不触发，或者偶尔丢消息。我整理了一个检查清单，按顺序排查基本都能找到原因：

• 节点有没有正确连线？连线断开的情况下什么都不发生。
• 修改之后有没有点部署？没部署的改动只在编辑器里，不生效。
• MQTT 主题是否匹配？大小写、层级符号都算，差一个字符都收不到。
• switch 节点的判断条件是否写对？属性名和数据类型都要对。
• 消息的 payload 类型是否正确？字符串"26.5"和数字26.5在比较时结果可能不同。
• debug 节点是否配置了输出完整消息？默认只输出 payload，看不到其他属性。

我最常犯的错误就是改完忘了点部署，然后对着画布纳闷为什么没反应。后来养成了习惯，改完先点部署再看调试。

6.4 长期运行的稳定性与备份建议

如果你打算让 Node-Red 长期跑，有几个维护习惯建议养起来。第一，定期导出流文件备份，导出的 JSON 文件很小，存几个版本不占空间。第二，关注内存占用，如果流特别多或者处理的数据量很大，内存会慢慢涨，必要时重启一下服务。第三，系统更新之后检查一下 Node-Red 是否正常，尤其是 Node.js 大版本升级后，有些节点包可能需要重新安装。

我自己还有一个习惯，就是在做比较大的改动之前，先把当前的流导出一份，命名加上日期。这样万一改崩了，直接导入备份就能恢复，不用一行行去改回来。这个习惯帮我省了好几次重搭的时间。

6.5 安全加固的补充要点

除了前面说的设管理员密码，还有几个安全点值得注意。如果你的 Node-Red 要暴露到公网（不建议这么做，但如果确实需要），一定要启用 HTTPS，可以用反向代理来做。另外，不要用默认的 1880 端口对外，改一个不常见的端口能减少被扫描到的概率。

MQTT 那边也要注意，不要允许匿名连接。Mosquitto 配置里把匿名访问关掉，只允许认证用户连接。密码不要用弱密码，设备端的凭据也要定期更换。

还有一点，Node-Red 的 function 节点可以执行任意 JavaScript，如果你安装了来路不明的第三方节点，理论上存在安全风险。所以装节点之前，尽量看一眼它的下载量、维护状态和开源仓库，不要随便装一个名字都没听过的包。

7. 一些让流更好维护的进阶技巧

7.1 用子流组织复杂逻辑

当你的流越来越大，画布上节点连线密密麻麻的时候，找一个节点要拖半天。这时候可以用子流功能，把一组相关的节点打包成一个子流节点，在主画布上只显示一个入口。子流可以有自己的输入输出，复用性很好。

举个例子，你可以把“解析传感器数据并判断告警”这一整套逻辑做成一个子流，每个设备的流都调用这个子流。修改的时候只改子流内部，所有调用处都生效。这个技巧在设备数量多的时候特别有用，能省掉大量重复工作。

7.2 用环境变量管理配置差异

如果你有多个环境（比如测试和正式），服务器地址、端口、主题前缀可能不一样。硬编码在节点里的话，迁移的时候要一个个改。更优雅的做法是用环境变量，在 settings.js 里定义，然后在节点里用${}语法引用。

Node-Red 支持在节点配置里直接写环境变量表达式，比如 MQTT 服务器地址写${MQTT_HOST}。这样你只要改环境变量文件或者启动参数，不用动流本身。我自从用了这个方式，把流从测试环境搬到正式环境只需要改一个配置文件。

7.3 用 link 节点减少连线混乱

link 节点分为 link out 和 link in 两种，可以在画布上建立虚拟连线。这对于跨区域连接特别有用，比如你的输入节点在左上角，输出节点在右下角，直接拉一条长线会穿过整个画布，很难看。用 link out 打个标记，在输出端用 link in 接上，逻辑关系一目了然。

我现在的习惯是，按功能把画布分成几个区域，区域之间用 link 节点连接，而不是直接拉线。这样即使流很大，看起来也不会太乱，后面维护的时候找起来快很多。

7.4 调试节点的正确使用姿势

debug 节点看起来简单，但用好了能省很多时间。默认的 debug 节点只输出msg.payload，你可以把它改成输出完整消息对象，这样能看到所有属性。还可以给 debug 节点设置一个名称，在调试窗口里就能知道是哪条消息打出来的。

如果流里有多个 debug 节点，建议用不同的名称区分，不然调试窗口里一堆输出分不清哪个是哪个。另外，调试完之后记得把不需要的 debug 节点禁用掉，不然它们会一直消耗资源，消息量大的时候会影响性能。

8. 我在这套东西上踩过的真实坑

说几个我实际遇到的问题，你大概率也会遇到。

第一个坑是流循环。我曾经不小心把输出连回了输入，导致消息无限循环，CPU 直接跑满，整个 Node-Red 卡死。后来才明白，连线的时候要顺着数据流方向走，不要形成回路。如果确实需要循环处理，要用 delay 节点控制节奏，不然就是灾难。

第二个坑是消息属性覆盖。我在一个 function 节点里把msg.payload改成了字符串，后面一个节点却还在按数字处理，结果比较永远不成立。排查了很久才发现是类型变了。所以我现在的习惯是，在 function 节点里改 payload 类型的时候，一定在注释里写明改成什么类型了。

第三个坑是MQTT 重连导致的消息重复。网络不稳定的时候，MQTT 客户端会重连，如果 QoS 设的是 1 或 2，可能会收到重复消息。我的处理方式是在消息里带一个唯一 ID 或者时间戳，在流里做一个简单的去重判断，短时间内收到相同 ID 的消息就丢弃。

第四个坑是树莓派 SD 卡写坏。前面提过，日志频繁写入把卡写坏了，系统都起不来。后来我关了不必要的日志，并且把 Node-Red 的流文件目录设到了外接存储上，才稳定下来。如果你也用 SD 卡，建议少写日志，多备份。

9. 从本地原型到实际部署的扩展方向

本地这套跑通之后，如果你想把它用在实际场景里，有几个方向可以扩展。

一是多设备接入。把 MQTT 主题按设备 ID 分层，比如home/sensor/esp32_01/data，然后在 Node-Red 里用通配符订阅home/sensor/+/data，一个输入节点就能收所有设备的数据。再配合子流做统一处理，扩展起来很快。

二是数据持久化。Node-Red 本身可以把数据写到文件或者数据库，你可以接一个时序数据库比如 InfluxDB，把传感器数据存起来，然后用 dashboard 或者 Grafana 做长期趋势分析。这个组合在物联网项目里非常常见，我自己的数据已经存了一年多，回头看趋势很有价值。

三是远程访问。如果你不在家的时候也想看数据，可以配一个内网穿透或者用云服务器做中转。但这一步一定要做好安全加固，别为了图方便把整个本地网络暴露出去。我自己的做法是用一个轻量的反向代理加认证，只暴露 dashboard 页面，编辑器界面只在内网访问。

说到底，Node-Red 最大的好处是让你把精力花在“逻辑和场景”上，而不是花在“写代码和调接口”上。十分钟搭起来不是夸张，我第一次装的时候从零到跑通一个 MQTT 流，确实没超过十五分钟。真正花时间的是后面根据需求不断调整逻辑、优化流结构、处理各种异常情况。但只要基础跑通了，后面的每一步都是在已有画布上加节点，门槛低了很多。

如果你也在折腾本地物联网，不妨先按这篇的路径走一遍，把最小可用的流跑起来，然后再逐步往里加东西。遇到坑不用怕，大部分问题前面的人都踩过，社区里搜一下基本都有答案。