VM0 工作流执行失败时，日志页面是定位问题的第一现场。通过请求 ID 和节点状态码，可以快速判断失败发生在哪一步，再结合输入输出摘要确认是数据问题还是逻辑问题。以下方法围绕 VM0 自带日志功能展开，适用于工作流运行时报错或返回空结果的排查。

排查 VM0 工作流失败时，应先用请求 ID 串联日志，确定失败节点；再根据状态码区分网络错误与逻辑错误；随后检查该节点的输入 JSON 是否符合格式要求；修改后重跑并对比日志差异。此方法适用于 VM0 日志功能可用的场景，风险在于日志保留时长和字段完整性，需要结合环境确认。

理解 VM0 日志页面中的关键字段

VM0 的日志页面通常以表格或列表形式展示每次执行记录。需要关注以下几个字段：

• 请求 ID：每次工作流执行的唯一标识，格式可能是 UUID 或时间戳加随机数。同一请求 ID 下的所有日志都属于同一次调用。
• 节点名称：显示当前日志属于工作流中的哪个步骤，例如“HTTP 请求”“数据清洗”“条件判断”。
• 状态码：区分执行结果，例如 0 表示成功，非 0 或特定错误码表示失败。此处的状态码可能是 HTTP 状态码，也可能是 VM0 内部错误标识。
• 输入输出摘要：记录节点接收和返回的数据片段，通常截断到一定长度，用于快速判断数据流向。
• 时间戳：精确到毫秒，帮助判断耗时和先后顺序。

日志页面可能还有错误信息、重试次数等字段，但以上几个是定位失败的基础。

用请求 ID 串联一次完整调用

当工作流涉及多个节点或外部调用时，单条日志无法反映全貌。先用请求 ID 把散落的日志串起来。

在 VM0 日志页面中，通常有一个搜索框，可以直接输入请求 ID 过滤出该次执行的全部日志。如果日志导出为文件，可以使用命令行检索：

grep <request_id> app.log

如果日志文件较大，可以加上上下文行数：

grep -C 5 <request_id> app.log

这样能看到请求 ID 附近的关键信息，例如节点切换和状态变化。如果发现某些节点没有日志，说明执行可能未到达该节点，或者该节点被跳过。

区分网络错误与工作流逻辑错误的常见表现

网络错误和工作流逻辑错误的处理方式不同，混淆两者会浪费排查时间。

• 网络错误通常表现在连接外部服务时，例如 HTTP 调用超时、DNS 解析失败、连接被重置。日志中可能包含超时码或连接类错误信息，状态码常为 504、408 或连接错误标识。
• 工作流逻辑错误通常发生在数据处理或条件判断阶段，例如字段为空、类型不匹配、计算异常。日志会显示节点内部的错误字段，比如“input is null”“casting error”，而状态码可能是 VM0 内部的错误编号。

判断技巧：先看失败节点的类型。如果是 HTTP 请求节点，优先怀疑网络；如果是数据转换或条件节点，优先检查输入数据。同时看日志中错误提示的上下文，网络错误往往包含 URL 或超时时长，逻辑错误往往指向具体字段名。

检查输入数据格式是否满足节点要求

很多失败源于节点输入数据不符合预期。在日志页面点击失败节点，可以查看该节点的输入 JSON 快照。需要确认字段是否存在、类型是否正确、是否为空。

例如，一个字符串处理节点要求输入 JSON 结构如下：

{
  "text": "hello",
  "max_length": 10
}

若输入中“text”字段缺失，或者“max_length”为字符串“10”，都会导致校验失败。可以在日志面板中检查原始 JSON，如果日志没有完整显示，可以使用导出功能或编写一个小脚本验证。

常用的校验思路：

• 长度：检查字符串是否超过节点限制，或数组是否为空。
• 类型：确认数字字段是 number 而不是 string，布尔值是否为 true/false。
• 必填项：根据节点文档确认哪些字段不可省略。

如果输入数据来自上游节点，可以结合上个节点的输出摘要对比，看数据在传递过程中是否被截断或转换。

修改配置后重跑并对比前后日志

修改配置后，在 VM0 日志页面或工作流编辑页面找到“重跑”或“重新执行”按钮，通常位于执行记录行或节点详情页。建议重跑前先记录当前失败日志的请求 ID。

重跑后，再次搜索新的请求 ID，对比前后日志的差异：

• 状态码是否从非 0 变为 0，或错误信息是否消失。
• 输入输出摘要是否发生了变化，特别是之前报错的字段是否有值。
• 执行耗时和走到的节点是否不同，例如之前卡在某个节点，现在通过了。

如果重跑后新的错误出现在后续节点，说明前一个问题被修复，但引入了新问题或暴露了下一个问题。此时继续使用新的请求 ID 重复上述排查流程。

注意，重跑可能产生外部副作用（如发送重复请求），需要结合实际环境确认是否允许重跑。