物联网中的 Node-RED（2）：核心概念 flow / node / msg / context

物联网中的 Node-RED（2）：核心概念 flow / node / msg / context

上一篇讲完 Node-RED 是什么、怎么上手。这一篇把四个最核心的概念掰开：flow（流）、node（节点）、msg（消息）、context（上下文）——这是看懂任何一条流的地基，也直接对应你双服务端推送、地灾平台里的那些变量怎么存的。

一、是什么

• flow（流 / 标签页）：一块画布，由若干节点+连线组成，对应 flows.json 里的一段。复杂系统按业务域拆成多个 flow（比如"设备采集流""报警转发流"分开）。
• node（节点）：最小功能单元，有输入/输出端口；由"类型+ID"唯一确定（同一个类型可拖多个实例，靠 ID 区分）。
• msg（消息）：节点之间流动的 JSON 对象，主数据挂在 msg.payload，可夹带 msg.topic、自定义字段。它是"数据流的血液"。
• context（上下文）：节点之间跨消息保存状态的地方，分三级作用域：node（单节点）、flow（同一画布内共享）、global（全局共享）。

二、怎么用

• 画 flow：拖节点→连线；一个 tab 一条 flow，别把不相关的堆一起。
• 读/改 msg：function 节点里用 msg.payload，改完必须 return msg 才往下传。
• 存状态：context.set('k', v) / context.get('k')（节点级）；flow、global 同理 flow.set / global.set。
• 防串改克隆：多分支下游都要改 payload 时，用 RED.util.cloneMessage(msg) 或 JSON 深拷贝，避免互相污染。

三、用在哪里

• 双服务端推送：用 flow 级 context 暂存设备最新值、global 存连接配置；msg 携带设备 ID/时间戳贯穿整条流。
• 地灾平台 P03：用 msg.topic 区分设备/测点，flow.context 缓存上一次数值做"变化才上报"判断。
• AI 摄像头报警：一条 flow 里 msg 从"接收→识别→转发"一路传递，context 记"已报警"状态防重复推送。

四、怎么能用好（避坑）

• msg 是引用传递：多下游各自改 payload 会互相污染，必要时克隆。
• context 是内存态、重启清零：global/flow 里别存"设备长期在线""累计计数"这种要持久的状态，落文件/数据库才稳。
• 别滥用 global：全局变量难追踪、易冲突，能用 msg 传递或 flow 级就别上 global。
• msg 别塞太大：整包二进制、超大数组塞进 msg 会拖慢流、吃内存，大文件走路径/流，不塞 payload。
• 节点 ID 别撞：复制节点易撞 ID，改参数前确认 ID 唯一，否则配置串台。

五、原理

运行时按 flows.json 构建节点图：消息从输入类节点（inject、mqtt in、http in…）出发，沿 output→input 端口逐节点传递。context 底层是 JS 对象（内存），可配置成文件/数据库后端实现持久化。节点若返回 Promise，运行时等待其完成再发下游，这就是"异步必须 await"的底层原因。

六、背景（来龙去脉）

Node-RED 2013 年 IBM 发起，msg/context 的"数据流 + 状态"模型借鉴了 LabVIEW、积木式流式编程的思想；context 三级作用域是后来为支持"有状态流"（如计数、去重、缓存）补上的关键能力。

误区澄清

1. "msg 随便改不影响别人" —— 错。msg 是引用共享，多下游分支要克隆，否则你改的字段别人也跟着变。
2. "global 里存啥都行" —— 错。重启即丢、难维护，长期态别放内存，该落库的落库。
3. "flow 越多越清楚" —— 错。过度拆分反而难追踪数据流，按业务域适中拆分即可。