今天在设计「逐级审批」节点时，重新思考了复杂业务系统中灵活性的平衡。人事系统经常面对所谓「灵活的业务需求」，平台也确实需要通过解耦来适配变化。但灵活性并不等于无限开放：架构可以解耦，产品能力仍然需要清晰的场景约束。没有边界的灵活，最终往往会转化为概念、配置、交互和维护成本。
逐级审批中的具体问题
逐级审批目前包含汇报线、部门线和岗位线三种逐级路由模式。它们表面上都是「逐级找人」，背后的组织关系、终止条件和适用范围却不同，因此不应该为了形式统一而抹平各自的约束。
汇报线为什么先约束为单链
按汇报线逐级审批，隐含前提是每一级都能找到唯一的直属上级，整条审批链是一条直线。如果同一个人存在多个直属上级，汇报线就会发生分叉，审批链也会从线性结构变成树形结构。
树形结构并非不能实现，真正需要评估的是：为支持它所增加的产品成本是否值得。一旦允许分叉，就必须继续定义多个新问题：
- 多个上级是任意一人通过，还是全部通过？
- 不同分支在更高层遇到同一个人时，是否需要合并和去重？
- 某个分支提前结束、驳回或异常时，其他分支如何处理？
- 审批记录、流程图和配置界面如何让用户准确理解这棵树？
这些问题增加的不只是开发量，更重要的是用户理解成本和产品设计复杂度。是否支持树形审批，本质上是产品决策，而不是单纯的技术可行性判断。
产品决策的两个判断
- 主流竞品是否支持。竞品不是答案，但可以帮助判断这是否是一个普遍且成熟的业务场景。如果行业中的主流产品普遍没有提供，通常意味着需求频率、收益或复杂度之间尚未形成划算的平衡。
- 原始诉求到底是什么。不能把用户提出的方案直接当成需求。需要继续追问：用户真正要解决的是多汇报线，还是代理审批、会签、加签、跨部门协同等其他问题？只有确认了原始问题，才能判断是否真的需要引入树形模型。
设计原则
- 架构上预留扩展性：将不同逐级路由模式解耦，保留未来增加新策略或扩展树形路由的空间。
- 产品上明确当前边界：只支持已经验证的主流场景，并把单链约束、校验规则和异常提示说清楚。
- 实现上保持克制：预留不等于提前建设。没有被真实需求验证的能力，不提前实现，也不提前暴露给用户。