Start（开始）
每次运行开始的地方。
用途
标记流程的入口。运行时把当前节点设为 Start 节点，并从那里开始执行循环。
每个流程恰有一个 Start。
何时用
总是——它随流程创建。你不添加也不移除它。
何时不用
没有任何情况需要删除 Start 节点。没有它的流程无法运行。
前提
无。Start 不需设备即可运行，也不接受配置。
如何运行
运行时初始化执行上下文——所有声明变量置 null，然后应用默认值、再应用初始值、再做类型检查——并把当前节点设为 Start 节点的 id。
Start 随即路由 Success。
它计入流程的 maxNodeExecutions 护栏，算作一个已执行节点。
设置
Start 没有设置。它的 params 对象按设计为空。
你以为要在这里配置的一切，都住在流程设置里：
| 你想要 | 它住在哪 |
|---|---|
| 默认超时与阈值 | 流程设置 → Defaults |
护栏（maxNodeExecutions 等） | 流程设置 → Runtime |
| 流程期望哪个实例 | 流程设置 → Target |
| OCR 与输入功能开关 | 流程设置 → Features |
| 变量声明与默认值 | Variables 对话框 |
| 按次提供的值 | Flow Input 参数 |
端口
| 端口 | 走它的时机 | 必接 |
|---|---|---|
| Success | 总是，立即 | 是 |
| Fatal | 系统错误 | 否——永不被走 |
基础示例
实际示例——前置检查
紧跟 Start 之后最有价值的东西，是检查你确实在你以为的地方：
假设起始状态的流程，是无法解释的失败的最常见来源。Start 后一个检测节点消除整类问题。
高级示例——播种运行状态
当流程需要在声明默认值之外初始化计数器或旗标时，紧跟 Start 做一次：
可能时优先用声明默认值——它们在运行启动时自动应用，任何分支都绕不过。
最佳实践
- 紧跟 Start 放前置检查。 动作前先验证屏幕状态。
- 初始值用声明默认值而非 Variable 节点，这样分支无法绕过它们。
- 让 Start 只接一个节点。 从 Start 出多条连线让入口路径难读。
- 别把 Start 当配置节点——它没有配置。
性能笔记
- Start 运行时零成本。
- 它消耗
maxNodeExecutions的一次执行，只对接近上限的流程有影响。 - 所有真正的启动成本——schema 校验、规范化、图校验、表达式检查、素材校验、编译、会话创建——都发生在 Start 运行之前的 preflight。
内存笔记
- 执行上下文（变量、
nodeResults、lastResult）在 Start 运行前创建。每个会话有自己的一份。 - Start 本身不分配任何东西。
常见错误
| 错误 | 后果 | 修复 |
|---|---|---|
| 假设起始界面 | 流程在错的界面上动作 | 加前置检查 |
| 在 Start 上找设置 | 没有 | 用流程设置 |
| 从 Start 出多条连线 | 入口路径混乱 | 只接一条 |
| 在分支里初始化变量 | 该分支不走就被跳过 | 用声明默认值 |
故障排查
运行根本没启动 。
Preflight 在 Start 之前失败——schema、图校验、表达式、素材、功能开关或实例会话。错误由 runtime.start 报告，且不会发出 runtime.started 事件。
运行启动了但立刻做错事。 起始界面不是流程假设的。加前置检查。
运行被 TYPE_MISMATCH 拒绝。
某个声明变量的默认或初始值违反类型。修声明。
FAQ
流程能有多个 Start 吗？ 不能——恰好一个入口。
能删掉 Start 节点吗？ 不能。没有它的流程无法运行。
Start 计入 maxNodeExecutions 吗？
计入。Stop 也计入。
在哪设流程超时？ 流程设置 → Defaults，不在 Start 上。