流程停在中间状态时，先别急着重推。判断根因的关键在于三类现场证据：触发环节有没有产生执行记录、执行记录是否出现开始与结束时间、对象当前状态是否与流程节点一致。据此可以把异常归入触发失败、执行超时、对象状态冲突或人工处理中断四类，再按“先触发、后执行、再对象状态与人工节点”的顺序逐项排除，避免在根因未明时重复执行造成数据错乱。
要点总览（TL;DR）
- 流程停在中间状态时，先用三类证据定位：触发环节有无执行记录、执行记录有无开始与结束时间、对象当前状态是否与流程节点一致。
- 触发失败看触发日志与规则命中记录；执行超时看执行开始时间、下游耗时与超时阈值；对象状态冲突看对象变更历史与状态机规则；人工处理中断看待办记录与节点停留时长。
- 排查顺序是先确认触发是否发生，再确认执行是否完成，最后核对对象状态与人工节点，每一步都能缩小范围。
- 重推、回滚、手工改状态前需备份对象状态与流程实例记录、确认无重复执行风险、明确恢复后的验证方式，缺一项就先停止并保留现场证据。
- 恢复后验证流程实例走到预期节点、对象状态与流程一致、无重复执行记录，再针对本次根因补充超时提醒、并发控制与状态机校验。
卡在中间状态时先分清是哪一类异常
“卡在中间状态”是一个笼统描述，落到现场通常有三种表现：流程实例停在某个节点不再流转；对象已经进入下一环节，但流程实例仍显示上一节点；流程实例与对象状态各自推进，彼此对不上。这三种表现指向的根因并不相同，因此第一步不是修流程，而是用少量现场信息做初步归类。
归类时优先看三个信号。第一，触发环节有没有留下记录：如果规则应当触发却没有任何执行记录，问题大概率在触发之前。第二，执行记录有没有开始时间和结束时间：有开始无结束，说明动作已经发起但未完成；有开始有结束却无后续流转，问题更可能出在对象状态或流转条件上。第三，对象当前状态是否被其他操作改写：如果对象状态与流程期望状态不一致，需要先确认是谁改的、什么时候改的。
此外还要看节点本身是否在等待人工处理。审批、确认、填写类节点天然会停留一段时间，若没有超时策略，停留时长可能被误判为“卡死”。区分方法是查看待办记录：有明确待办人且节点停留时长在合理范围内，属于正常等待；待办长期无人处理且无提醒机制，则归入人工处理中断。
| 现场信号 | 初步判断 | 下一步取证方向 |
|---|---|---|
| 规则应触发，但无任何执行记录 | 触发失败 | 触发日志、规则命中记录、事件是否产生 |
| 有执行开始时间，长时间无结束标记 | 执行超时 | 下游调用耗时、排队情况、超时阈值配置 |
| 执行已结束，对象状态未推进或与节点不一致 | 对象状态冲突 | 对象变更历史、状态机规则、并发修改记录 |
| 节点停留在人工待办，无超时提醒 | 人工处理中断 | 待办记录、处理人响应情况、节点停留时长 |
这张表只用于初判，不能直接当作结论。初判之后仍需按下一节的证据逐项验证，并且在取证完成前避免重推流程、手工改状态等操作，否则可能掩盖原始现场，甚至产生重复执行。
触发失败、执行超时、状态冲突的成因与排除证据
四类根因各自对应一组成因假设，验证时要让证据说话：假设说明“可能是什么”，证据回答“是否确实如此”。下面按类别列出常见假设、可验证证据，以及哪些条件可以排除、哪些条件不能排除。
触发失败
常见假设有三类：触发条件未满足，例如字段值、状态或时间条件与规则定义不符；事件未产生，例如上游操作没有发出流程依赖的事件；权限或配置导致规则未命中，例如规则被停用、作用范围不包含该对象。验证证据是触发日志与规则命中记录，重点看规则是否被评估、评估结果是否命中、命中后是否生成执行实例。
可以排除触发失败的条件：触发日志中存在该对象的命中记录，且已生成执行实例。不能排除的情况：日志只显示规则被评估但未命中，此时仍需核对条件配置与对象当时的字段值，不能直接认定是配置错误。
执行超时
常见假设包括下游动作响应慢、批量任务排队导致等待、超时阈值设置过短。验证证据是执行开始时间、各下游调用的耗时分布，以及超时配置的实际值。判断时要区分“仍在执行”和“已经失败但未回写状态”：前者表现为无结束标记且下游仍有活动，后者表现为下游已返回错误但流程实例未更新。
可以排除执行超时的条件：执行记录已有正常结束标记，且结束时间在阈值之内。不能排除的情况：执行记录缺失结束标记，但下游系统也无响应记录，此时需要先确认调用是否真正发出，再判断是超时还是调用链路中断。
对象状态冲突
常见假设有三类：同一对象被并发修改，两个操作互相覆盖；状态机不允许当前跳转，例如从待评审直接跳到已完成；字段校验未通过，导致流转被拦截但未给出明显提示。验证证据是对象变更历史与状态机规则：变更历史能看出谁在什么时间改了状态，状态机规则能确认该跳转是否被允许。
可以排除状态冲突的条件：对象变更历史显示状态由流程自身写入，且与流程节点一致。不能排除的情况：变更历史缺失或时间精度不足，此时应结合流程实例记录交叉比对，不能仅凭当前状态下结论。
人工处理中断
常见假设是审批人或处理人未响应、节点缺少超时提醒、待办被转交后无人接手。验证证据是待办记录与节点停留时长：待办是否已送达、是否被查看、停留时长是否明显超出同类节点的常规处理时间。
可以排除人工中断的条件：待办已处理并产生流转记录。不能排除的情况：待办显示已处理但流程未流转，此时问题可能已转为对象状态冲突，需要回到上一类继续核对。
按排查顺序处置：从触发到执行再到对象状态
排查顺序遵循“先确认是否发生，再确认是否完成，最后核对结果是否被接受”。这个顺序的价值在于每一步都能缩小范围，避免在多个环节同时改动。
第一步，核对触发记录。确认规则是否被评估、是否命中、是否生成执行实例。若没有执行实例，处置重点在触发条件、事件来源与规则作用范围，暂不涉及流程内部操作。
第二步，查看执行记录。确认动作是否开始、卡在哪个下游调用、耗时是否接近或超过阈值。若执行仍在进行，优先等待或联系下游确认，不重复发起同一动作。
第三步，比对对象当前状态与流程期望状态。检查对象变更历史中是否存在并发修改，核对状态机是否允许该跳转、字段校验是否通过。这一步的结论决定后续是修正数据还是调整规则。
第四步，检查人工节点与超时策略。确认待办是否送达、处理人是否明确、是否存在超时提醒。若属于人工中断，处置方式是催办或转交，并补充超时策略。
重推、回滚、手工改状态属于有破坏风险的操作，执行前需要满足三个前置条件：已备份对象当前状态与流程实例记录；已确认不存在重复执行风险，例如同一动作没有正在进行的实例；已明确恢复后的期望状态与验证方式。三者缺一，应先停止操作并保留现场证据，包括异常发生时间、相关日志片段、对象状态快照与已尝试的操作记录。若排查到某一步仍无法确认根因，同样应停止改动，把证据交给流程维护方或平台管理员处理。
在团队日常协作中，这类排查依赖流程实例记录、对象变更历史与待办状态能够被同一处查看。以 ONES 为例，工作项的状态变更与流程流转记录可以在工作项详情中追溯，排查时据此比对“流程期望状态”和“对象实际状态”，能把上面第三步的核对落到具体记录上；涉及人工节点时，待办与处理记录也可作为判断停留时长的依据。具体入口与字段口径以团队实际配置为准。
恢复后如何验证并减少再次卡住
流程恢复流转不等于问题解决，需要完成三项验证。第一，流程实例已走到预期节点，且后续节点能正常触发。第二，对象状态与流程节点一致，变更历史中没有异常写入。第三，没有产生重复执行记录，同一动作只有一条有效实例。三项都通过，才能确认恢复有效。
复发预防从本次根因出发，针对性补充控制措施：
- 为关键节点设置超时与提醒，尤其是审批、确认类人工节点，明确超时后的催办或转交规则。
- 对可能被并发修改的对象加锁或串行化处理，减少两个操作互相覆盖状态的机会。
- 补充触发条件与状态机的校验，让不满足条件的流转在发起时就被拦截并给出明确提示，而不是停在中间状态。
- 把本次异常的发生时间、根因类别、取证结论与处置动作留档，作为同类问题的排查参照。
留档时建议记录到可直接比对的程度：异常发生与发现的时间点、流程实例标识、对象标识、初判类别与最终确认的根因、执行过的操作及其结果。下次遇到相似症状，可以先查留档中是否有同类根因，再决定从哪一步开始取证，缩短定位时间。
常见问题
流程实例显示停在某节点，但对象状态已经推进到下一环节，这算哪类异常？
这种情况更接近对象状态冲突，而不是流程没有执行。执行记录通常已有结束标记，问题出在流程实例与对象状态的写入不同步：可能是对象被其他操作并发修改，也可能是状态机允许了流程未预期的跳转。核对对象变更历史中状态由谁、在什么时间写入，再与流程实例记录比对，能确认是并发覆盖还是流转条件放行。在确认前不要手工把流程实例改到下一节点，否则会掩盖原始记录。
执行记录有开始时间但一直没有结束标记，怎么区分是仍在执行还是已经失败？
看下游是否仍有活动。下游调用仍在处理、耗时接近阈值，属于仍在执行，优先等待或联系下游确认，不重复发起同一动作。下游已返回错误但流程实例未更新，属于执行失败但状态未回写，需要按执行超时或调用链路中断继续排查。若下游也没有响应记录，先确认调用是否真正发出，再判断是超时还是链路中断。两种情况的处置方式不同，取证时把下游返回结果与流程实例记录一并留存。
人工审批节点停留很久，怎么判断是正常等待还是人工处理中断？
看待办记录与停留时长。待办已送达、处理人明确、停留时长在同类节点的常规处理时间内，属于正常等待。待办长期无人处理、缺少超时提醒，或转交后无人接手，则归入人工处理中断。还有一种情况需要留意：待办显示已处理但流程未流转，此时问题可能已转为对象状态冲突，应回到对象变更历史继续核对，而不是继续催办。
根因还没确认，可以先重推流程让业务先跑起来吗？
不建议在根因未明时重推。重推可能产生重复执行记录，覆盖原始现场，后续再排查时缺少可比对的证据。若业务确实紧急，至少先满足三个条件：备份对象当前状态与流程实例记录；确认同一动作没有正在进行的实例；明确恢复后的期望状态与验证方式。三者缺一，应先保留现场证据，包括异常发生时间、相关日志片段、对象状态快照与已尝试的操作记录，再交由流程维护方处理。
流程恢复流转后，还需要做哪些确认才算处理完成？
完成三项验证：流程实例已走到预期节点且后续节点能正常触发；对象状态与流程节点一致，变更历史中没有异常写入；同一动作只有一条有效执行实例，没有重复执行记录。三项都通过，才确认恢复有效。随后把本次异常的发生时间、根因类别、取证结论与处置动作留档，下次遇到相似症状可先查留档，缩短定位时间。
