视岗精承数据全流程服务开发复盘：3个阻断Bug拖垮2个阶段，我们踩过的决策坑

上周做视岗精承数据全流程服务项目四阶段验收时，我盯着验收报告上的两个60%通过率愣了好久：开坯阶段已经做到98%可验收，连轧、锯切两个阶段却直接卡壳，收集阶段还因为双规则没启用只有75%的通过率。同一个项目，三个阶段的完成度差距为什么这么大？我们花了3天时间交叉排查，最后发现3个跨阶段的共性Bug拖垮了进度，还有几个关键业务决策差点让我们走偏。

一、3个跨阶段阻断性Bug：1处修改解锁2个阶段

排查连轧阶段的问题时，我们一开始盯着业务逻辑查了两天：为什么mill_group字段一直拿不到值？为什么连轧的轧制参数总是缺数据？直到连轧、锯切两个模块的开发同学坐在一起交叉排查，才发现问题出在最底层的ProcessSignalSnapshotMapper.xml映射文件里——Base_Column_List整整漏了11个列：包括连轧需要的mill_1到mill_8共8个轧辊参数、锯切需要的double_cut_signal双剪信号，还有sizing_machine_2/3_low两个定尺机低位信号。改完这一处配置，连轧、锯切两个阶段的基础数据读取直接恢复正常，原本卡了两天的两个阶段，半小时就通了基础流程。这个教训特别深刻：跨模块的共性问题，优先查底层配置和映射，别上来就改上层业务逻辑。

除此之外还有两个全项目共性问题：一是validateSawingStatus存在时序冲突，当轧件状态sts=2时调用handleXxxSawing方法会直接抛异常，导致锯切判定完全跑不通，架构师最终决策用方案B新增不校验方法绕开了时序冲突，目前已经验证通过；二是全项目5个实体都有is_auto_judged字段，但从来没有setter调用，导致自动判定的结果根本写不回库，我们挨个实体补了setIsAutoJudged("Y")的调用，才把自动判定的链路打通。

二、关键业务决策复盘：差点把人工操作做成自动判定

这次开发我们踩过最大的坑不是技术问题，是业务决策差点走偏。一开始收到需求时，我们默认认为“炉甩”“分段轧制”这类操作都要支持自动判定，花了2天时间做了自动判定的逻辑，结果用户确认后才发现：炉甩、is_post_segment（分段标记）都是页面人工操作，自动判定器根本不需要支持。

这里有个典型的决策失误：我们一开始把is_post_segment加在FpStepBlooming（开坯步骤）实体里，后来才发现业务逻辑里“轧后分段”是锻坯的属性，字段位置是对的，但我们之前还给自动判定器加了赋值逻辑，相当于同一个字段被两处修改，差点导致数据冲突。后来用户明确确认：is_post_segment由页面人工操作，自动判定器不赋值，SawingJudge模块直接读取该字段判定场景2，我们才把自动赋值的逻辑删掉，避免了后续的数据混乱。

还有个决策差点让我们白忙活3天：用户提的GAP-01（开坯边沿方向）和GAP-02（锯切开始/完成信号）和测试库的数据不一致，我们一开始想对齐测试库的数据，改了两天逻辑，结果用户明确说“需求是唯一标准，哪怕测试库数据错了也要严格对齐需求”，我们立刻回滚了改好的逻辑，对齐需求描述后，这两个问题也升级为P0级必须修复的Bug。

三、验收之外：两个流程优化点落地

除了Bug修复，这次我们还落地了两个用户确认的流程优化：一个是工艺衔接触发的逻辑，原来是对账间隔10s兜底，现在改成当前工艺结束一支后主动触发后续工艺对账，间隔缩短为5s兜底，新增了P1-7和P2-1两个优先级的需求；另一个是收集阶段的双规则，用户确认启用后我们把dual-rule-enabled改成true，同时高温床的collect_bed值固定为3（1号冷床是1，2号冷床是2，高温床是3），容量数值按交接方案2/8配置，目前收集阶段的通过率已经提升到可验收区间。

结尾：3条可带走的核心经验

这次复盘下来，有3条可复用的经验可以直接用到后续项目里：

1. 跨模块共性问题优先排查底层：遇到跨模块的异常，先查公共依赖、配置、映射，再改上层逻辑，能省至少一半的排查时间；
2. 业务决策一定要找最终用户确认，不要脑补需求：哪怕测试库的数据是对的，只要和需求描述不一致，就要先找用户确认，不要自己改逻辑，不然只会白忙活；
3. 验收前先做共性Bug扫描：把全项目的公共配置、公共字段、公共方法先拉通检查一遍，能解决至少30%的跨阶段问题，不用等验收的时候才逐个排查。