查审批流当前状态不能只取最新记录，因多级审批存在驳回返工、条件跳过等非线性流转，需结合step_order、is_rejected及前序步骤完成状态逐层校验生效节点，否则易误判待办环节。
查审批流当前状态时，为什么不能只查最新一条记录
因为多级审批流的状态不是线性覆盖的，比如“财务驳回”后流程回到“部门负责人审批”，此时最新记录是驳回，但当前待办节点其实是上一级。直接 ORDER BY created_at DESC LIMIT 1 会误判状态。
必须结合状态机定义和审批层级顺序，从“未被否决且未跳过”的最近有效节点中找当前激活态。常见错误是把 status 字段当孤立值查，忽略了 step_order 和 is_rejected 的联合约束。
- 状态机里每个
step_code（如'dept_approve'、'finance_review'）有预设顺序和允许转移条件 - 一条审批记录只有在
is_rejected = false且其前序所有步骤都已通过时，才算“生效” - 数据库里可能存着“财务已通过”但“法务还没发起”的中间态，此时当前状态应是法务待办，而非财务已通过
用相关子查询定位每个步骤是否“真正完成”
核心思路：对每个审批步骤，检查它是否满足“已提交 + 未被拒 + 前序步骤全部完成”。这需要逐层向上验证，不能靠单表聚合。
示例：查某 approval_id = 123 的当前状态
NOT EXISTS
- 递归起点是初始步骤（
step_code = 'init'） - 每次 JOIN 都要动态计算
condition_sql是否成立（PostgreSQL 可用EXECUTE format(...)，MySQL 则需提前展开为 CASE） - 最终结果集中，最后一个
to_step对应的实例记录，才是当前应处节点
实际执行中，condition_sql 字段不能直接执行，必须预编译成布尔表达式字段或用应用层拼接——否则 SQL 注入风险极高，且多数数据库不支持运行时动态条件求值。
性能陷阱：嵌套太深导致全表扫描
三层以上嵌套子查询在 MySQL 5.7 或早期 PostgreSQL 中极易触发临时表 + filesort，尤其当 approval_steps 表超 10 万行时，响应可能从毫秒级升到秒级。
- 务必给组合索引：
(approval_id, step_order, status, is_rejected) - 避免在子查询 WHERE 中用函数包裹字段，例如
DATE(created_at) = '2024-01-01'会让索引失效 - 如果业务允许，把“当前有效步骤”缓存到主表
approvals.current_step_code字段，用触发器或应用层维护，查状态就退化为单行查询
最易被忽略的是状态机规则变更后的数据一致性——比如新增一个步骤，旧审批流不会自动补记录，查询时可能因找不到对应行而返回空，而不是降级到上一步。这个边界必须由业务代码兜底，SQL 层做不到智能 fallback。
