Node-RED 踩坑：第三方节点导致的 “No response object”

Posted by backup@lfo.cc; tagged with none

在使用 Node-RED 搭建一个简单的股票实时行情查询服务时，我遇到了一个让人困惑的问题。我设计的流程非常直观：

[HTTP IN] -> [新浪股票实时行情接口 (第三方节点)] ->[ HTTP RESPONSE]

然而，这个简单的流程却一直报错：“No response object”。经过一番排查，我发现问题出在 HTTP RESPONSE 节点无法找到 msg.res 对象。

我起初以为是第三方节点的问题，但深入研究后才发现，根源在于 Node-RED 的消息流机制。

  1. Node-RED 的核心机制：当 HTTP IN 节点接收到请求时，它会自动在 msg 对象中创建 msg.req 和 msg.res 这两个关键对象，它们承载着请求和响应的上下文信息。
  2. 第三方节点的“粗暴”处理：我使用的第三方节点，在处理数据时，采取了一种简单粗暴的方式——它直接创建一个全新的 msg 对象来存放处理结果，例如：msg = {payload: '新数据'}。
  3. 关键信息的丢失：这种操作直接覆盖了原有的 msg 对象，导致 msg.req 和 msg.res 信息丢失。当流程走到 HTTP RESPONSE 节点时，它自然就找不到 msg.res 对象，从而抛出错误。

解决方案：备份与恢复 msg 对象

知道了问题的根源，解决方案也就清晰了：在调用第三方节点之前，我们需要备份 msg.req 和 msg.res；等第三方节点处理完毕后，再将它们恢复回来。

具体的做法是：

  1. 在 新浪股票实时行情接口 节点之前，添加一个 Change 节点。
  2. 在这个 Change 节点中，将 msg.req 和 msg.res 备份到新的变量中，例如 msg.backup.req 和 msg.backup.res。
  3. 在 新浪股票实时行情接口 节点之后，再添加一个 Change 节点。
  4. 在这个 Change 节点中，将 msg.backup.req 和 msg.backup.res 的值分别恢复到 msg.req 和 msg.res。

调整后的流程图如下：

HTTP IN -> Change (备份) -> 新浪股票实时行情接口 -> Change (恢复) -> HTTP RESPONSE