名词术语表（新手必读）
2026/8/21大约 14 分钟
名词术语表（新手必读）
本文用大白话 + 场景举例 + 对比表格解释工作流里最容易让人犯晕的名词。 如果你第一次接触本模块，建议先读完本文，再去看《操作手册》和《模块说明》。 所有术语均与后端枚举（
ZR.Workflow/Enum/*）严格对应，括号里标注了对应的代码枚举值。
一、一句话理解核心概念
把一条工作流想象成一次"审批接力赛"：
- 流程定义 = 画好的赛道图纸（谁跑第几棒、什么条件下换道）。
- 流程实例 = 真实开跑的一场比赛（张三提交的那次请假）。
- 节点 = 赛道上的关卡（"部门经理审批"这一关）。
- 任务 = 某个具体的人要在这个关卡上做的事（"李四，请你审批"）。
- 记录 = 比赛过程的全程录像（谁、何时、做了什么）。
二、签类型（多人审批怎么定结果）
当一个审批节点配置了多人（比如一个角色、一个部门、或加签了多人）时，需要决定"这几个人怎么算通过"。这就是签类型（WfSignType），是新手最容易混淆的概念。
1. 或签（Or = 0）
一人通过 = 整节点通过。
- 含义：多个人里任意一个人处理了（通过），这个节点就算过了，其余人的待办自动作废（置为"已跳过"，不会重复流转）。
- 适用场景：只关心"有没有人拍板"，不关心是谁。例如「分管副总审批」——几位副总里任何一位点通过即可。
- 例子：节点审批人是「张总, 王总, 李总」三人或签。张总先看到并点了通过 → 流程继续，王总/李总的待办自动消失。
2. 会签（And = 1）
必须全部人通过 = 整节点通过。
- 含义：节点上配置的每一个审批人都要分别通过，缺一不可。只要还有一人没审，流程就卡在这一关（等待）。
- 适用场景：需要集体一致同意的事项。例如「合同会签」——法务、财务、业务三方都必须签字。
- 例子：节点审批人是「法务, 财务」两会签。法务通过 → 流程不前进，继续等财务；财务也通过后 → 节点才完成，进入下一关。任一人驳回 → 整节点驳回（打回发起人）。
3. 依次审批 / 顺序会签（Sequential = 2）
按设置的顺序，一个接一个审；前一人审完才轮到下一人；全部通过才过，任一驳回则整节点驳回。
- 含义：多人按先后顺序排队审批，同一时刻只有排到的人有"待审"任务，其余人处于"排队中（Waiting）"。前一人处理完，下一位才拿到待办。
- 适用场景：有层级递进关系、或想控制并发压力的审批。例如「先主管审 → 再总监审 → 最后总裁审」。
- 与"会签"的区别：会签是大家同时收到待办、谁先点都行；依次审批是强迫按顺序、前面不审后面看不到。
- 例子：节点审批人顺序为「主管, 总监」。主管先收到待办，总监此时状态为"排队中"看不到；主管通过 → 总监收到待办；总监通过 → 节点完成。若主管驳回 → 整节点直接驳回，总监无需也无权再审。
4. 比例会签（Percent = 3）
多人同时激活（与会签一样），达到设定比例（如 50%）的审批人通过即推进节点；未达比例继续等待。
- 含义：节点上配置的每一个审批人同时收到待办，但不要求全部通过——只要通过人数达到节点设定的
PassRatio（如0.5表示 50%、0.6表示 60%）即算节点通过并推进；达到比例前，未审的人继续等待，已驳回不影响"达到比例即过"的判定（具体以"通过人数 / 应审人数 ≥ 比例"为准）。 - 适用场景：人数较多的理事会 / 委员会表决，或想"大多数人同意即可、不苛求全员一致"的场景。例如「工会投票」5 人审批、过半（≥50%）即生效。
- 与"会签"的区别：会签要求100% 通过；比例会签只需达到阈值比例即可推进，容错更灵活。
- 例子：节点审批人「甲, 乙, 丙, 丁, 戊」5 人、
PassRatio=0.6。甲、乙、丙 3 人通过即达 60% → 节点完成推进；若只 2 人通过则继续等待剩余人，直到累计达到 3 人通过。
四种签类型对比速查
| 签类型 | 代码值 | 通过条件 | 待办是否同时出现 | 一人驳回后果 | 典型场景 |
|---|---|---|---|---|---|
| 或签 | Or=0 | 任一通过 | 是（同时） | 整节点驳回 | 多位领导任选其一拍板 |
| 会签 | And=1 | 全部通过 | 是（同时） | 整节点驳回 | 多部门必须一致同意 |
| 依次审批 | Sequential=2 | 全部通过（按序） | 否（排队） | 整节点驳回 | 层级逐级上报 |
| 比例会签 | Percent=3 | 通过人数 ≥ 设定比例（如 60%） | 是（同时） | 不影响"达比例即过"判定 | 委员会/多人表决过半即生效 |
⚠️ 注意：单人审批的节点没有签类型之分（只有一个人，谈不上"或/会/比例"），此时签类型配置不生效。比例会签需节点另设
PassRatio（通过比例）参数，缺省按 100% 等同会签。
三、节点类型（WfNodeType）
流程由不同类型的"节点"串起来，每个节点决定引擎要做什么。
| 类型 | 代码值 | 大白话 | 是否生成待办 | 是否阻塞流程 |
|---|---|---|---|---|
| 开始 Start | 0 | 流程起点，由"提交申请"触发 | 否 | — |
| 审批 Audit | 1 | 某某人来拍板（通过/驳回） | 是 | 是（要等人审） |
| 抄送 Cc | 2 | 只是"知会"某人，不让他审批 | 仅抄送任务 | 否（看完就继续） |
| 结束 End | 3 | 流程终点，实例标记"通过" | 否 | — |
| 条件网关 Condition | 4 | 菱形分叉口，按表单数据自动选一条路走 | 否 | 否（自动选路） |
| 并行分叉 ParallelFork | 7 | 一分为多，同时跑多条分支 | 否 | 否（激活分支） |
| 并行汇聚 ParallelJoin | 8 | 多路汇合，等所有分支都到齐才继续 | 否 | 是（等最慢的） |
几个容易混的节点解释
- 审批节点 vs 抄送节点
- 审批 = 必须处理（通过/驳回）才会往下走，处理人才是"责任方"。
- 抄送 = 仅通知，对方看了也不会推进流程，纯粹"备个案"。抄送人即便一直不点开，流程也照常继续。
- 条件网关（菱形）vs 并行分叉
- 条件网关 = 多选一（满足金额>5000走A，否则走B），同一时刻只走一条路。
- 并行分叉 = 全都要（A、B、C 三条分支同时激活、各自独立推进），常用于"几个部门同时审"。
- 开始/结束节点是隐式的：设计器里你拖"开始/结束"只是图形标记，引擎真正串联流程靠的是节点之间的连线（wf_node_link），而不是开始/结束图标本身。
四、审批人来源（WfApproverType）
一个审批节点"该谁来审"有 6 种指定方式，对应 WfApproverType：
| 来源 | 代码值 | 大白话 | 例子 |
|---|---|---|---|
| 指定用户 User | 0 | 直接点名某几个具体人 | 选「李四」 |
| 指定角色 Role | 1 | 选一个角色，角色下所有成员都能审（通常配合或签） | 选「部门经理」角色 |
| 指定部门 Dept | 2 | 选一个部门，部门下所有人 | 选「财务部」 |
| 表单字段 Field | 3 | 运行时从申请人填的表单里动态取人（字段值必须是 userId） | 表单有「审批人」字段，提交时填谁谁来审 |
| 部门负责人 DeptLeader | 4 | 系统自动找该部门的 Leader | 选「技术部」→ 自动找技术部负责人 |
| 发起人主管 ApplyLeader | 5 | 系统自动找发起人的直属上级 | 张三提交 → 自动找张三的 Leader |
兜底策略（EmptyApproverStrategy）：以上 6 种来源最终可能一个人都解析不到（例如选了"部门负责人"但该部门没配 Leader）。此时节点不会卡死，而是按配置二选一：
0自动通过（节点自动跳过，留痕"审批人为空，节点自动跳过"）；1指定默认审批人（用节点上配的DefaultApproverId/Name兜底）。
⚠️ 表单里的
user类型字段（如"同行人"）存的是昵称字符串，仅供展示，不能配置成 Field 节点的审批人（引擎 Field 分支只认 userId）。
五、流转动作与状态名词
5.1 实例状态（WfFlowInstance.Status）
| 状态 | 值 | 含义 |
|---|---|---|
| 审批中 | 0 | 流程正在跑，等待某节点处理 |
| 通过 | 1 | 走到结束节点，全部审完 |
| 驳回 | 2 | 被某节点驳回，回到发起人 |
| 撤回 | 3 | 申请人主动撤回（未结束前） |
5.2 任务状态（WfFlowTask.Status）
| 状态 | 值 | 含义 |
|---|---|---|
| 待审 Pending | 0 | 轮到我了，还没处理 |
| 已审 Done | 1 | 我已通过/驳回 |
| 跳过 Skipped | 2 | 或签别人先过点了 / 审批人为空自动跳过，我的待办作废 |
| 排队中 Waiting | 3 | 依次审批里还没轮到我（前面的人还没审） |
5.3 常见动作名词（操作按钮里会见到）
| 名词 | 谁操作 | 大白话 | 对应枚举 WfAction |
|---|---|---|---|
| 提交/发起 | 申请人 | 填上表单，把流程跑起来 | Submit=0 |
| 通过 Approve | 审批人 | 我同意，往下走 | Approve=1 |
| 驳回 Reject | 审批人 | 不同意，打回发起人 | Reject=2 |
| 转办 Transfer | 审批人 | 这活我不合适干，换另一个人来负责这个节点 | Transfer=3 |
| 撤回 Withdraw | 申请人 | 还没审完，我反悔撤回 | Withdraw=4 |
| 加签 AddSign | 审批人 | 临时拉额外的人进来一起审（如会签再添一人） | AddSign=5 |
| 重新提交 Resubmit | 申请人 | 被驳回后改好，再提交一次（回首节点重审） | Resubmit=6 |
| 抄送 Cc | 引擎/节点 | 系统自动知会某人 | Cc=7 |
| 自动跳过 AutoSkip | 引擎 | 审批人解析为空，按兜底自动放行 | AutoSkip=8 |
| 减签 RemoveSign | 审批人 | 把加签/会签里不合适的人去掉 | RemoveSign=9 |
| 委托代审 Delegate | 审批人 | 任务仍挂在我名下，但请别人代为通过/驳回 | Delegate=10 |
| 挂起/恢复 Suspend/Resume | 管理员 | 临时冻结/解冻整条流程 | Suspend=11/Resume=12 |
| 终止 Terminate | 管理员 | 强制作废这条流程 | Terminate=13 |
| 改派 Reassign | 管理员 | 把某未完成任务换人 | Reassign=14 |
| 跳转 Jump | 管理员 | 强行把流程跳到指定节点 | Jump=15 |
| 催办 Urge | 申请人 | 提醒当前审批人快点（24h 同条限一次） | Urge=16 |
5.4 最容易混的两组操作
- 转办 vs 委托代审
- 转办：任务彻底移交给对方，对方成为新的责任审批人，与你无关了。
- 委托代审：任务仍挂在你名下，只是代审人帮你点通过/驳回；记录上会注明"（代 X 审批）"。适合你短期不在、但责任还得你背的场景。
- 加签 vs 减签
- 加签：审批中途增加审批人（如觉得还该让总监也看看）。
- 减签：把已加进来 / 会签里不合适的人移除（只有本节点审批人能操作）。
六、驳回策略（RejectStrategy）
审批人点「驳回」后，流程退回哪里，由节点的驳回策略决定（前端 NpApprove 配置，后端 WfFlowNode.RejectStrategy）：
| 策略 | 值 | 大白话 | 退回后状态 |
|---|---|---|---|
| 驳回发起人 | 0（默认） | 直接打回给申请人，流程结束（实例置"驳回"），申请人改完可重新提交 | 实例=驳回，回到申请人 |
| 驳回到上一节点 | 1 | 退回上一个审批节点重新审，流程保持"审批中"，不回申请人 | 实例=审批中，回到上一审批人 |
区别速记：策略 0 = 退回给提申请的人；策略 1 = 退回给上一个签字的人。 例：流程「主管 → 经理 → 总监」，经理驳回：
- 策略 0：整条打回给申请人张三，张三改完重新提交、从主管开始重走。
- 策略 1：退回给主管重新审，总监的待办取消，主管再审一遍。
进阶：源码还预留了「驳回到指定节点」（
RejectStrategy=2+rejectTargetNodeId），可精确驳回到任意历史审批节点，但前端当前仅暴露 0/1，历史存量数据若带 2 仍可正常流转。
七、设计器模式（DesignType）
流程定义有两种可视化设计器，效果等价、只是画法不同，由「设计类型」字段选择（后端 WfFlowDefinition.DesignType）：
| 模式 | 值 | 形态 | 适合人群 |
|---|---|---|---|
| LogicFlow | 1 | 自由画布：拖节点、拉连线、菱形网关、dagre 自动布局，接近"画流程图" | 熟悉流程图画法的管理员 |
| Simple（简单式） | 2 | 纵向卡片流：从上到下叠卡片，节点间点「+」插入，无需画连线 | 新手、只想快速配审批链 |
两种模式保存的数据结构完全一致（都是节点 + 连线），可互相切换不丢配置。示例模板（见《操作手册》§二.7）对两种模式都适用。
六、分支与并行名词
- 条件分支（条件网关）：根据表单数据自动选路。比如「报销金额 > 5000 走总监审批，否则走主管审批」。条件都不满足时走默认分支（连线上不配条件的那条）。
- 并行分支（并行分叉+汇聚）：同一关拆成多条线同时跑，比如「技术评审」和「安全评审」同时进行，两边都过了再汇合继续。汇聚节点会等最慢的那条完成。
- 包容网关 / 并行组（ParallelGroup）：把多个审批节点设成同一组号，运行时整组同时激活；组里某个分支因条件不满足会自动视为"已完成"，不卡住整组。可以理解为"宽松版并行"——能跑的跑，跑不了的自动放过。
七、版本管理名词
| 名词 | 大白话 |
|---|---|
| 草稿 IsDraft | 设计中的版本，员工不能发起，需"发布"后才生效 |
| 现行版本 IsCurrent | 同一条流程（同 FlowCode）里当前生效的那一版（唯一） |
| 另存新版本 | 在旧版基础上改一版，版本号 +1，旧版冻结保留 |
| 复制 | 整体复制成另一个独立流程（编码加 _copy），互不影响 |
| 回滚 | 把某个历史版本"复制"成新的最高版本，快速回到旧逻辑 |
| 版本对比 diff | 选两版并排比较节点的增减/改动（类型、审批人、签类型、并行组），标色展示 |
八、其他高频名词
- Webhook（出站回调）：节点进入/离开时，系统自动向外部系统（如你的业务系统、钉钉机器人）发一个 HTTP 请求，把事件通知出去。失败会自动重试，多次失败进"死信"不阻断主流程。
- 站内信 + 实时推送：待办到达、被审批等事件通过站内消息 + SignalR 实时推送给相关人。
- 超时自动处理：给审批节点设"超过 N 小时未审就自动通过/驳回/转交某人"，由后台定时任务扫描执行（详见《模块说明》§3 第 9 条）。
- FormItems（动态表单）：流程里内嵌的轻量表单定义（JSON），申请人填的字段。无需单独开发页面即可发起申请。
- 多租户：不同租户的数据相互隔离，工作流表在租户初始化时自动建表。
九、流转示意图（Mermaid）
下面用流程图直观展示几种最容易混的流转形态。节点框含义：
([开始])/[结束]：流程起止[审批]：阻塞型审批节点{{条件}}：条件网关（菱形，按数据自动选路）- 并排的
[审批]+ 虚线包裹：并行分支
9.1 或签（一人过即过）
9.2 会签（全部过才过）
9.3 依次审批（按序排队）
9.4 条件分支（多选一）
9.5 并行分支（同时跑，汇合才继续）
看完还有不懂的名词？欢迎在《操作手册》的"常见问题"里找答案，或反馈补充到本文。