消息设计

在流程中传递的消息是普通的 JavaScript 对象，可以在其上设置属性。

它们通常有一个 payload 属性 - 这是大多数节点会使用的默认属性。

有关 Node-RED 中消息的更多信息，您应该阅读用户指南的使用消息部分。

本节探讨了在决定如何在流程中构建消息时需要做出的一些选择。

创建流程时，消息上使用的属性很大程度上将由流程中节点的需求决定。

大多数节点都期望使用 msg.payload，这将指导您做出的大部分选择。

例如，考虑一个流程，它在 MQTT 消息的 payload 中接收一个 id。然后它使用这个 id 查询数据库以找到匹配的记录。

MQTT 到数据库查询

数据库节点会将其结果放入它发送的消息的 payload 中 - 覆盖了原始的 id 值。如果流程稍后需要引用该 id 值，它可以使用 Change 节点将该值复制到另一个不会被覆盖的属性中。

使用 Change 节点将 payload 复制到 msg.id

这突显了一个重要原则：节点不应修改或删除与自身功能无关的消息属性。

例如，在大多数情况下，Function 节点应该转发它收到的同一个消息对象，而不是创建一个新的消息对象。

调试侧边栏消息中显示的msg.topic

许多节点也将 msg.topic 视为具有特殊含义。它可能用于识别消息的来源，或用于识别同一流程上的不同消息“流”。它也会与每条消息一起显示在调试侧边栏中。

例如，MQTT In 节点会将 msg.topic 设置为接收消息的主题。然后 Delay 节点可以配置为根据消息的主题进行速率限制。

虽然您的流程可能不会直接使用依赖于 msg.topic 的节点，但它可以用来提供有关消息的额外上下文信息。但是，如果您稍后在流程中引入依赖于其值的节点，则应多加注意。

在设计可重用的节点或子流程时，它使用的消息属性和它设置的属性都是其暴露的 API 的一部分。与所有 API 一样，它需要精心设计。这也同样适用于流程。

一种方法是将所有内容都放在 payload 下。例如：

{
    "payload": {
        "temperature": 123,
        "humidity": 50,
        "pressure": 900
    }
}

这样做可能便于将数据放在一起，但也可能导致需要频繁移动属性，因为后续节点期望操作的是 msg.payload，而不是其下的某个属性。

另一种不同的方法，如 Twitter 节点所示，是将最“有趣”的信息放入 payload 中，在本例中是推文的文本，并将 API 提供的完整元数据放入一个单独的 msg.tweet 属性中。

如何构建消息没有唯一的正确答案，但应该专注于在最常见的情况下如何使用该节点或流程。

与一般编程一样，选择好的属性名称也很重要。它们应该是自描述的，以帮助后续的调试和对流程的理解。例如，msg.temperature 比 msg.t 更容易理解。

它们还应避免使用常用属性，如 reset 和 parts，这些属性在某些节点中具有特殊含义。