等待节点
等待节点用于在工作流中暂停执行指定时间。它允许你控制工作流的执行节奏，实现延迟执行、定时任务、重试间隔等功能。
使用场景
典型应用
- 延迟执行 - 在操作后等待一段时间再继续
- API 速率限制 - 在调用 API 后等待，避免触发速率限制
- 重试间隔 - 在失败重试之间添加延迟
- 定时任务 - 创建定时执行的工作流
- 轮询间隔 - 在轮询操作之间添加等待时间
- 缓冲处理 - 在批量操作之间添加间隔，避免系统负载过高
- 人工审核延迟 - 等待人工处理完成后再继续
节点配置
基础设置（参数面板）
等待时长 (amount)
需要等待的时间数值。
字段属性:
- 必填字段
- 数字类型
- 最小值：0
- 支持表达式
默认值: 0
配置示例:
// 1. 固定时长（秒）
5
// 2. 固定时长（分钟）
30
// 3. 使用表达式计算时长
$('HTTP Request').body.retryDelay
// 4. 根据条件动态设置
$('AI 分类器').class === "urgent" ? 0 : 60
// 5. 从配置节点读取
$('配置').defaultWaitTime时间单位 (unit)
等待时长的时间单位。
可选值:
seconds- 秒minutes- 分钟（默认）hours- 小时days- 天
默认值: minutes
单位换算:
1 天 = 24 小时 = 1440 分钟 = 86400 秒
1 小时 = 60 分钟 = 3600 秒
1 分钟 = 60 秒使用建议:
短延迟（< 1 分钟）: 使用 seconds
中等延迟（1-60 分钟）: 使用 minutes（推荐）
长延迟（1-24 小时）: 使用 hours
超长延迟（> 1 天）: 使用 days高级设置（设置面板）
总是输出 (alwaysOutput)
当输出为空时，是否输出一个空项。
默认值: false
用途: 防止工作流在此节点终止。
仅执行一次 (executeOnce)
是否仅使用第一个输入项执行一次。
默认值: false
用途:
- 当上游节点返回多个项时，默认会对每个项执行等待
- 启用此选项后，只对第一个项执行，后续项会跳过等待直接输出
失败重试 (retryOnFail)
等待失败时是否自动重试。
默认值: false
注意: 等待节点通常不会失败，但在特殊情况下（如系统中断）可能需要重试。
最大重试次数 (maxTries)
失败后的最大重试次数。
默认值: 3
前置条件: retryOnFail 必须为 true
重试等待时间 (waitBetweenTries)
每次重试之间的等待时间（毫秒）。
默认值: 1000 (1秒)
前置条件: retryOnFail 必须为 true
错误处理 (onError)
等待失败时的处理方式。
可选值:
stopWorkflow- 停止整个工作流（默认）continueRegularOutput- 继续执行，使用常规输出continueErrorOutput- 继续执行，使用错误输出
节点描述 (nodeDescription)
为节点添加自定义描述。
nodeDescription: "等待 5 分钟后继续处理"输出数据
等待节点会保持输入数据不变，在等待指定时间后原样输出。
// 输入数据
{
userId: "user123",
message: "Hello"
}
// 等待后输出（相同数据）
{
userId: "user123",
message: "Hello"
}访问输出:
// 获取等待后的数据
$('等待').userId
$('等待').message
// 数据与输入节点相同
$('等待') === $('HTTP Request') // 值相同工作流示例
示例 1: API 速率限制
HTTP Request 节点 A
→ 等待节点
时长: 1
单位: seconds
→ HTTP Request 节点 B
→ 等待节点
时长: 1
单位: seconds
→ HTTP Request 节点 C说明: 在每个 API 请求之间等待 1 秒，避免触发速率限制。
示例 2: 重试间隔
HTTP Request 节点
→ 条件分支
条件: $('HTTP Request').statusCode !== 200
→ [True] → 等待节点
时长: 5
单位: seconds
→ HTTP Request 节点（重试）
→ [False] → 回答节点说明: 如果请求失败，等待 5 秒后重试。
示例 3: 定时任务
Webhook 触发器
→ 代码节点（计算下次执行时间）
→ 等待节点
时长: $('代码').minutesUntilNextRun
单位: minutes
→ 定时任务节点说明: 根据计算出的时间等待，然后执行定时任务。
示例 4: 批量处理间隔
循环迭代节点
→ HTTP Request 节点（处理单个项）
→ 等待节点
时长: 2
单位: seconds
→ 下一个迭代说明: 在处理每个批次之间等待 2 秒，避免对系统造成过大负载。
示例 5: 动态等待时长
HTTP Request 节点（获取配置）
→ 等待节点
时长: $('HTTP Request').body.retryDelay
单位: seconds
→ HTTP Request 节点（重试）说明: 根据 API 返回的配置动态设置等待时长。
示例 6: 多级延迟
操作节点 A
→ 等待节点（短延迟）
时长: 1
单位: seconds
→ 操作节点 B
→ 等待节点（中延迟）
时长: 30
单位: seconds
→ 操作节点 C
→ 等待节点（长延迟）
时长: 5
单位: minutes
→ 操作节点 D说明: 在不同操作之间使用不同长度的延迟。
示例 7: 条件延迟
AI 分类器
→ 条件分支
条件: $('AI 分类器').class === "urgent"
→ [True] → 等待节点
时长: 0
单位: seconds
→ 立即处理
→ [False] → 等待节点
时长: 60
单位: seconds
→ 延迟处理说明: 根据分类结果决定是否延迟处理。
示例 8: 轮询等待
HTTP Request 节点（检查状态）
→ 条件分支
条件: $('HTTP Request').body.status === "processing"
→ [True] → 等待节点
时长: 10
单位: seconds
→ HTTP Request 节点（再次检查）
→ [False] → 处理完成节点说明: 如果任务仍在处理中，等待 10 秒后再次检查状态。
最佳实践
1. 合理设置等待时长
API 速率限制
# 检查 API 文档中的速率限制
# 例如：每分钟 60 次请求
时长: 1
单位: seconds # 每次请求后等待 1 秒系统负载控制
# 批量操作之间
时长: 2-5
单位: seconds重试间隔
# 指数退避策略
第一次重试: 1 秒
第二次重试: 2 秒
第三次重试: 4 秒2. 使用表达式动态设置时长
根据响应动态调整
// 根据 API 返回的 retry-after 头设置
$('HTTP Request').headers['retry-after'] || 60
// 根据错误类型设置不同延迟
$('HTTP Request').statusCode === 429 ? 60 : 5时间计算
// 等待到下一个整点
代码节点: 计算分钟数
等待节点: 使用计算结果3. 避免过长的等待时间
不推荐:
时长: 10080 # 7 天（过长）
单位: minutes推荐: 使用定时触发器或外部调度系统处理长时间等待。
4. 结合条件分支使用
智能等待
条件分支
→ [需要等待] → 等待节点 → 处理
→ [不需要等待] → 直接处理5. 测试和调试
测试不同时长
开发环境: 1-5 秒
测试环境: 10-30 秒
生产环境: 根据实际需求监控等待时间
等待节点
→ 代码节点（记录等待开始时间）
→ ...等待...
→ 代码节点（记录等待结束时间，计算实际等待时长）6. 性能考虑
避免不必要的等待
// 只在需要时等待
$('条件').needsWait ? 30 : 0批量处理优化
# 使用 executeOnce 避免重复等待
executeOnce: true常见问题
Q1: 等待节点会阻塞整个工作流吗？
A: 是的，等待节点会暂停当前执行路径，但不会影响其他并行分支。等待完成后会继续执行后续节点。
Q2: 可以使用表达式动态设置等待时长吗？
A: 可以，amount 字段支持表达式：
// 动态计算等待时长
$('HTTP Request').body.waitTime
// 条件判断
$('条件').isUrgent ? 0 : 60
// 数学计算
$('配置').baseWaitTime * 2Q3: 最长可以等待多长时间？
A: 技术上没有上限，但建议：
- 短延迟（< 1 小时）：使用等待节点
- 长延迟（> 1 小时）：考虑使用定时触发器或外部调度系统
Q4: 等待期间工作流会消耗资源吗？
A: 等待期间工作流执行会暂停，不消耗计算资源。等待是在服务端实现的，不会占用客户端资源。
Q5: 如何在等待后获取当前时间？
A: 在等待节点后使用代码节点获取时间：
等待节点
→ 代码节点
代码:
function main() {
return {
waitedUntil: new Date().toISOString()
}
}Q6: 等待节点会影响工作流的执行时间统计吗？
A: 是的，等待时间会计算在工作流的总执行时间内。
Q7: 可以取消正在等待的工作流吗？
A: 可以通过工作流管理界面取消正在执行的工作流，包括正在等待的工作流。
Q8: 多个等待节点可以串联使用吗？
A: 可以，多个等待节点会依次执行：
节点 A → 等待 1 秒 → 节点 B → 等待 2 秒 → 节点 C总等待时间 = 1 秒 + 2 秒 = 3 秒。
Q9: 等待节点可以用于实现定时任务吗？
A: 可以用于简单的定时任务，但对于复杂的定时需求（如每天固定时间执行），建议使用定时触发器或外部调度系统。
Q10: 如何实现指数退避重试？
A: 结合代码节点和等待节点：
代码节点（计算退避时间）
代码:
function main({retryCount}) {
return {
waitTime: Math.pow(2, retryCount) // 1, 2, 4, 8...
}
}
→ 等待节点
时长: $('代码').waitTime
单位: seconds
→ HTTP Request 节点（重试）