很多人把审批请求理解成“用户提交一个单据，审批人依次点通过”。但 approvals 的后端实现真正要解决的是：请求怎么继承分类定义、审批人怎么展开、顺序审批怎么卡住后续动作、状态怎么向前推进。
一、审批请求不是孤立表单，而是分类规则的实例化结果
审批请求创建时，并不是只写 title、owner、amount 这些值。它背后通常还要把分类上的字段模板、审批人配置、是否经理必审、是否顺序审批等规则一起带下来。也就是说，请求是 category 规则在某次业务提交上的“展开体”。
二、审批人不是手填名单，而是会随着规则生成审批链
从 request/category 两个模型一起看，审批人链路至少包含：谁是固定审批人、谁来自经理关系、哪些角色只在特定条件下出现，以及顺序审批时谁当前可操作。真正的复杂度不在“审批人有几位”，而在当前这一位到底能不能批。
三、顺序审批本质上是一个闸门系统
一旦分类启用顺序审批，后面的 approver 不是简单地“状态 waiting”，而是整个请求推进逻辑都要以“前序是否完成”为前提。这也是为什么顺序审批最常见的问题，不是按钮坏了，而是前序状态没被正确推进。
四、新手误区
- 以为审批请求只是 request 表的一条记录；
- 以为 approver 列表是纯展示数据；
- 以为顺序审批只是前端把后面按钮禁用。
五、实战注意事项
- 定制 request 创建时，先想清楚 category 规则应在哪一层展开；
- 排查“后续审批人不能批”时，优先看前序审批状态而不是 UI；
- 如果要做条件审批，别破坏已有 approver 展开和状态推进链。
结语
企业版审批请求真正难的，不是“建一条申请”，而是把分类规则稳定地展开成一次可推进的审批链。只有理解 request 和 category 的联动，顺序闸门才不会变成线上迷宫。
DISCUSSION
评论区