请假、报销、用章等申请常常共享“提交—审批—结束”的外观，但审批节点、金额规则和撤回条件各不相同。若把所有业务塞进一套写死的 if/else，后续新增流程会牵动大量代码；若只做可任意配置的流程引擎，又会提高维护门槛。
从明确的业务状态开始
为每种申请类型定义必要状态和合法迁移，例如草稿、审批中、已通过、已拒绝、已撤回。审批记录应保存节点、审批人、意见、时间和当时的申请内容快照。申请正文变化后，不能让既有审批记录失去对应依据。
处理多人和并发操作
- 多人会签应明确“全部通过”还是“任一通过”；或签则明确谁先处理生效。
- 审批提交时检查记录版本或当前状态，避免两个并发请求重复完成同一节点。
- 业务状态、审批日志和待办更新尽可能在事务中保持一致。
- 通知可异步发送，但失败重试不能重复推进审批状态。
撤回、转交、加签、补审等功能要明确可用节点和权限，并记录原因。不要通过直接修改申请表状态来代替审批操作，否则审计链会断开。
把规则和界面分开
审批规则由服务端决定，页面负责展示当前节点和可执行动作。针对金额阈值、部门负责人、申请人本人审批等边界，建立表格化测试案例。先让常用流程稳定，再逐步抽取通用节点配置，避免一开始追求过度通用的流程设计。
