状态机驱动按钮显隐
B端系统中一种将页面按钮的可见性和可操作性交由后端状态枚举驱动的设计模式。核心思路是：在后端定义”当前状态+当前角色=可操作动作集合”，前端按集合渲染按钮，而非在前端用 if-else 硬编码按钮逻辑。这种模式确保任何角色在任何节点看到的操作入口都是正确的。
简介
状态机驱动按钮显隐是B端产品设计中解决”什么状态能做什么操作”问题的一种系统化方案。在传统B端系统中，按钮的显示/隐藏逻辑通常散落在前端代码的各个 if-else 分支中——随着业务状态和角色组合的增加，if-else 分支呈指数级增长，维护成本极高且容易出错。
首席道歉官在 2026-06-22-woshipm-hr-task-automation-design 的HR外包入转调离系统设计中，将这种模式应用于用工任务的状态管理。每个任务的状态节点（待录入/待审核/审核中/已驳回/已通过/已下达/已撤销）直接控制页面上按钮的可见性和可操作性。后端状态枚举中定义可操作动作集合，前端按集合渲染按钮——这保证了”审核员看到提交按钮”或”已撤销的任务仍显示编辑按钮”这类逻辑错误不会发生。
关键信息
- 类型：设计模式 / 前端架构
- 领域：B端SaaS / 业务系统 / 状态管理
- 核心问题：按钮显隐逻辑散落在前端 if-else 中，随状态和角色组合增加而指数级膨胀
- 解决思路：后端状态枚举定义可操作动作集合，前端按集合渲染
- 关键优势：逻辑集中、不易出错、易于维护、支持动态扩展
- 关联概念：入转调离任务自动化、子任务联动机制
核心特性
设计原理
后端状态枚举:
待录入 → [提交, 保存草稿]
待审核 → [审核, 驳回, 查看]
审核中 → [通过, 驳回, 查看]
已驳回 → [重新提交, 查看]
已通过 → [下达, 查看]
已下达 → [撤销, 查看]
已撤销 → [查看]
前端渲染逻辑:
getButtons(currentState, currentRole) → 可操作按钮列表
按列表渲染按钮，不在列表中的按钮不渲染
与 if-else 驱动的对比
| 维度 | if-else 驱动（传统） | 状态机驱动 |
|---|---|---|
| 逻辑位置 | 散落在前端各组件 | 集中在后端状态枚举 |
| 状态×角色组合 | 每个组合写一个分支 | 枚举定义集合，前端按集合渲染 |
| 新增状态 | 修改所有相关组件 | 只修改状态枚举 |
| 新增角色 | 修改所有相关组件 | 只修改角色权限映射 |
| 出错概率 | 高（遗漏分支） | 低（枚举穷举） |
| 可测试性 | 难（需覆盖所有分支） | 易（枚举可单元测试） |
在HR外包系统中的应用
入转调离任务的状态节点和对应的可操作动作：
| 状态 | 服务主管 | 服务专员 | 资料审核员 | 审核主管 | HR客户方 |
|---|---|---|---|---|---|
| 待录入 | 查看 | 提交、保存、导入 | 查看 | 查看 | — |
| 待审核 | 查看 | 查看 | 审核、驳回 | 查看 | — |
| 审核中 | 查看 | 查看 | 通过、驳回 | 复核、驳回 | 查看 |
| 已驳回 | 查看 | 重新提交 | 查看 | 查看 | — |
| 已通过 | 下达 | 查看 | 查看 | 下达 | 查看 |
| 已下达 | 撤销 | 查看 | 查看 | 撤销 | 查看 |
| 已撤销 | 查看 | 查看 | 查看 | 查看 | 查看 |
每个单元格中的操作就是该状态+角色组合下的”可操作动作集合”，前端只渲染集合中的按钮。
扩展维度
状态机驱动不仅适用于按钮，还可以扩展到：
- 字段可编辑性：某些字段在”待录入”状态可编辑，在”已提交”后只读
- 页面可见性：某些页面（如审核工作台）只对特定角色可见
- 操作提示：不同状态下展示不同的操作提示文案
- 数据脱敏：敏感字段按角色决定是否脱敏展示
不同素材中的观点
- 2026-06-22-woshipm-hr-task-automation-design（首席道歉官）：在HR外包入转调离系统中应用状态机驱动按钮显隐。核心洞察是”不是靠前端if-else硬编码，而是在后端状态枚举中定义可操作动作集合，前端按集合渲染按钮”。这种设计保证了任何角色在任何节点看到的操作入口都是正确的——不会出现”审核员看到不该看到的提交按钮”或”已撤销的任务仍显示编辑按钮”的逻辑错误。在实际使用中，这种设计也降低了新功能上线时的回归测试成本——新增状态或角色只需修改枚举，不需要遍历所有前端组件。
实用信息
适用场景
- B端审批系统：多角色、多状态的审批流程中按钮的显隐控制
- 任务管理系统：任务在不同状态下需要展示不同操作入口
- 表单系统：表单在不同编辑阶段（草稿/已提交/已审核）的字段可编辑性控制
- 权限敏感系统：需要按角色精细控制操作入口的系统
实现要点
- 状态枚举定义在后端：前端不维护状态到按钮的映射关系，所有映射由后端接口返回
- 角色权限与状态解耦：权限控制和状态控制是两个独立维度，组合决定最终的按钮列表
- 前端只做渲染：前端拿到”可操作按钮列表”后只负责渲染，不负责判断”该不该显示”
- 支持动态扩展：新增状态或角色时只需修改后端枚举，不需要修改前端代码
注意事项
- 状态枚举需要穷举：遗漏的状态组合会导致按钮不显示或错误显示，需要单元测试覆盖所有状态×角色组合
- 状态迁移需要约束：不是所有状态都能迁移到所有状态，需要定义合法的状态迁移路径（如”已撤销”不能回到”待录入”）
- 并发场景需要考虑：多人同时操作同一任务时，状态可能在操作过程中发生变化，需要乐观锁或状态版本校验
- 前端缓存需要同步：如果前端缓存了状态枚举，后端更新枚举后需要通知前端刷新
与其他设计模式的关系
- 与 入转调离任务自动化 的关系：状态机驱动按钮显隐是入转调离系统的核心设计模式之一，与子任务联动机制并列为方案的两大技术支柱
- 与 子任务联动机制 的关系：子任务联动决定了”任务拆分和回退”的逻辑，状态机驱动决定了”每个状态下能做什么操作”的逻辑。两者配合实现了入转调离全链路的自动化管控
- 与 B端产品经理 的关系：状态机驱动是B端PM”流程解构能力”的具体实践——识别一个业务对象的完整生命周期，并为每个状态定义可操作动作集合
- 与 业务设计 的关系：状态机图是业务设计四步法中”描现状”和”设计未来”的核心工具之一