简体中文
驳回功能增强
约 1197 字大约 4 分钟
2026-04-16
在审批流场景中，当默认「驳回」交互（驳回方式、可驳回节点、弹窗文案、跳转说明等）无法满足业务诉求时，可以通过审批详情插件在「驳回」渲染前/后挂载逻辑，对展示与行为做增强。
典型场景例如：
- 驳回前拉取流程数据并判断是否允许直接完成任务
- 驳回后对弹窗标题、意见框标题、驳回至指定节点/结束流程等选项区做自定义
- 移动端在驳回方式列表、可驳回任务列表渲染前，隐藏或补充驳回方式与节点；自定义「处理后跳转至当前节点」等标题文案
适用场景
适用于「审批详情页已存在，但驳回链路中的方式选择、节点范围、弹窗与说明文案需要按业务规则定制」的场景；具体事件参数与示例以参考手册为准。
适用页面
- 审批详情页-驳回操作触发的弹窗
- 待处理的审批流程-驳回操作触发的弹窗
什么时候适合做驳回功能增强
如果你遇到下面这些需求，通常都适合优先考虑驳回功能增强：
- 需要在用户点击「驳回」后、弹窗或列表渲染前插入业务判断（如能否直接完成任务）
- 需要改写驳回弹窗标题、意见标题、驳回类型选项区或「指定节点处理/重新提交」相关说明
- 需要在移动端控制驳回方式显隐、可驳回节点列表，或自定义「跳转至当前节点」类标题
开发思路
驳回功能增强通常可以拆成三步理解：
- 明确要增强的是「渲染前」还是「渲染后」行为，以及运行端（Web / 移动端）
- 在审批详情插件中注册对应事件（Web）或 Hook（移动端），在回调里调用 API 或改写列表数据完成定制
- 发布插件并在目标审批详情场景中完成配置与验证
开发流程
明确场景与接入点
在开始之前，先确认以下问题：
- 逻辑需要在驳回 UI 绘制之前还是之后执行（Web 对应
approval.reject.render.before/approval.reject.render.after；移动端对应下文各 Hook） - 是否涉及直接完成任务、驳回方式列表、可驳回任务列表、标题文案等能力
- 移动端操作列表时是否遵守参考手册要求（如透传
id不可随意更改）
- 逻辑需要在驳回 UI 绘制之前还是之后执行（Web 对应
创建审批详情插件
在后台创建 审批详情 类插件（Web / 移动端按实际终端选择），与 Web端审批详情插件说明或移动端审批详情插件说明文档对齐。
选择事件或 Hook 并编写逻辑
Web 端：在插件
apply中注册事件，在回调内使用文档提供的api方法（如获取流程数据、设置弹窗标题、自定义驳回选项区与可驳回节点列表等）。移动端：注册与场景匹配的 Hook，在
functional中处理rejectWayList、taskList或返回自定义标题文案等。联调与验证
- 覆盖「驳回至指定节点」「驳回并结束流程」等不同驳回路径
- 对照参考手册核对列表筛选、样式定制与返回值
发布与上线
开发完成后发布插件，在对应审批详情场景中启用，并在真实流程任务上回归驳回路径。
推荐入口
Web 端
approval.reject.render.before— 驳回渲染之前approval.reject.render.after— 驳回渲染之后
移动端
flow.approval.reject.mode.list.render.before— 驳回方式列表渲染之前flow.approval.reject.processingmovetocurrent.title.render.before— 驳回后跳转至当前节点标题渲染之前flow.approval.reject.task.list.render.before— 可驳回至任务列表渲染之前
常见问题
Q：Web 的 before 和 after 应该选哪个？
before 更适合在驳回界面尚未最终呈现前做分支与拦截类逻辑；after 更适合在驳回 UI 已就绪后做展示类定制（标题、各驳回选项区、可驳回节点列表等）。二者可组合使用，以参考手册中的能力划分为准。
Q：移动端操作驳回方式 / 任务列表时要注意什么？
参考手册中强调：透传的 id 不可随意更改，否则可能无效；对列表做 splice、push 等操作时需保留数据契约。