锯切工艺页点了开始却无法结束？一次MES前端流程映射错误的排查

上周国内某钢铁企业的 MES（制造执行系统）迭代上线，一线车间操作员反馈了一个很影响效率的怪问题：在锯切工艺页面正常选参数点「开始」后，「结束」按钮全程灰置不可点，工序卡在「进行中」状态没法归档，后续的报工、物料追溯流程全中断了。

团队第一反应是后端状态同步异常，但查接口日志后发现：开始报工的请求返回正常，后端工序状态也正确更新为「进行中」，权限校验也没有拦截结束操作的逻辑。问题显然出在前端展示层。

复现与初步定位

我们按操作员的路径复现：进锯切工艺配置页，填加工参数、选原材料后点「开始」，页面跳到执行页，底部「结束」按钮直接处于 disabled 状态，没有任何 hover 提示或错误说明。

先排了三个方向：接口返回的权限字段 has_end_btn 为 true，排除后端数据问题；状态管理库里工序状态确实是「进行中」，符合可结束条件；最后顺着按钮渲染条件这个方向查代码，很快找到异常点。

硬编码导致的流程映射偏差

结束按钮的渲染逻辑非常直接：

// 原渲染逻辑
<button 
  v-if="props.type !== '5'" 
  :disabled="processStatus !== 'running'"
>
  结束
</button>

逻辑是：只要工序类型的 type 值为 5，就直接不渲染结束按钮。原因是早期开发时，团队把 type=5 的锯切工艺归类为「单步完成」类型，默认点开始后自动完成，不需要手动点结束。

问题在于，业务迭代后锯切的实际流程已经改成「分步报工」：操作员点开始后，要记录锯切开始时间、填加工参数，待锯切完成再手动点结束，上传加工时长、材料损耗等数据才能完成归档。前端的硬编码判断完全没适配这次调整，而当前的提交逻辑还保留着分步操作，所以根本不是后端阻断，是前端对工序类型的流程映射偏差。更麻烦的是，这个判断是硬编码的，以后新工序类型要调整流程，只要没改这行代码，都会出现类似按钮异常。

两层修复加三轮验证

针对这个问题做了两个层面的修复：一是调整按钮渲染逻辑，不再按 type===5 硬编码禁用结束按钮，而是新增工序配置字段 need_end_step，由后端按当前工艺配置返回是否需要结束步骤，前端直接读配置判断；二是补充流程校验，工序开始后前端先校验当前工序是否需要结束步骤，不需要就自动触发完成流程，需要则正常展示结束按钮。

修复后做了三轮验证：第一轮走锯切工艺流程，点开始后结束按钮正常可点，填完数据点结束，状态正确更新为「已完成」，报工数据正常同步；第二轮验证原有单步工序（焊接、打磨）的 need_end_step 为 false，点开始后自动完成，逻辑符合预期；第三轮做边界测试，把工序配置改成需要结束步骤，前端按钮正常显示。

这类工业互联网系统的流程类按钮异常，排查思路其实固定：先看接口返回的状态、权限字段是否符合预期，确认不是后端问题；再查前端按钮渲染条件、状态判断有没有硬编码的类型或状态值；最后确认当前流程设计是不是和业务实际一致，优先用可配置字段替代硬编码判断，从根源避免。这次问题不大，但直接卡住了一线生产效率，也提醒我们：工业制造类业务系统迭代时，前端流程逻辑一定要和业务规则同步更新，尽量少用硬编码判断，否则就是埋下隐形维护成本。

---

做自动化这几年，最耗时间的从来不是写代码，是摸清每个平台的脾气。

这篇里提到的坑，都是真金白银踩出来的。
如果你手上也有重复度很高的活儿——批量发布、数据搬运、有固定规则的机械操作
——可以在评论区说说你的场景，我看看能不能自动化掉。