Row 27：实际并网容量信息页面必填字段填写完之后点击提交报错

严重已关闭 · 复测通过生物质模块：实际并网信息 / 实际并网容量信息　处理人：何佳星

1基本信息

问题描述	实际并网容量信息页面必填字段填写完之后点击提交报错。
所属模块	实际并网信息 / 实际并网容量信息
严重程度	严重（阻断流程：是）
涉及类型	生物质
提出人	刘向诚
处理人 / 状态	何佳星 / 5.1.已关闭（复测通过）

2问题截图

生物质场站实际并网容量信息提交报错 — 图1：生物质场站"实际并网容量信息"页，发电单元信息填写完整后提交，顶部弹出两条"运行时异常，请联系管理员!"及一条"获取数据失败"

3代码定位（backup730 / 730backup 分支）

前端提交入口：src/views/projectNew/components/actualInfo/components/tabItem.vue 第 560-606 行 saveInfo()，最终调用 projectActualApi.updatePlant(this.station)，对应后端接口 /newenergy/sjbw/updatePlant。

后端：src/main/java/cn/csg/so/oms/in/newenergy/project/appservice/SjbwAppService.java 第 968-1072 行 updatePlant(Map map)，生物质属于"非新型储能"分支（第1007-1041行）：

} else {   // 1007行：生物质/风电/光伏等均走这个通用分支（与"电源侧/电网侧/新型储能"分支相对）
    NeDpArcVO arcEntity = BeanUtil.toBean(map, NeDpArcVO.class);
    arcEntity.setUpdateTime(DateUtil.date().toTimestamp());
    getCapBaseCommonDAO().update("cn.csg.so.oms.in.newenergy.project.model.NeDpArcVO_updateById", arcEntity);
    List<NePwrPlProcVO> powerPlant = arcEntity.getPowerList();
    ...
    if (ObjectUtil.isNotEmpty(powerPlant)) {
        prepareWindTurbineManufacturer(type, powerPlant);          // 1016行：风机厂家字段处理（内部对生物质类型已做类型判断防护）
        restoreUnsupportedWindTurbineManufacturer(type, powerPlant); // 1017行：同上
        for (NePwrPlProcVO val : powerPlant) {
            val.setSortNum(getSortNum(val.getCode()));
            ...
        }
        gridTimeResult = evaluateFdgfGridTimeChanges(powerPlant, getGdFdgfPower(implId, plantId1), type);
        batchOperationUtils.saveOrUpdateBatch(powerPlant, ...);
        ids = isFdgfSendFlow(arcEntity);
    }
}

如实说明：受限于本轮排查时间，未能在 updatePlant() 及其调用链（evaluateFdgfGridTimeChanges / getSortNum / isFdgfSendFlow 等方法内部逐行核实）中精确定位到导致"运行时异常"的具体崩溃代码行。已确认 prepareWindTurbineManufacturer()/restoreUnsupportedWindTurbineManufacturer()（第176-220行）对生物质等非风电类型已做了 ProjectTypeConstant.isWindPower(type) 的类型判断防护，暂未发现明显空指针风险；不排除报错来自 getSortNum()、evaluateFdgfGridTimeChanges() 内部对生物质场站特有字段（如机组编号、上网情况等）做数值/日期解析时缺少空值防护，或数据库唯一约束冲突等场景。该问题在 xlsx 记录中状态已为"5.1.已关闭/复测通过"，即后续版本已修复，此处按 backup730 快照如实说明"未能定位到明确崩溃代码行"，不做猜测性归因。

4修复方向建议

① 补充异常兜底与日志：在 SjbwAppService.java updatePlant() 方法体外层（或其 Controller 入口 SjbwController.java 第 125 行 updatePlant）补充针对性的 try-catch，捕获异常后记录完整堆栈日志（含 implId/plantId/type 等关键字段），并向前端返回更具体的错误信息，替代目前笼统的"运行时异常，请联系管理员!"，以便后续同类问题能够第一时间定位到具体触发字段。

② 复核数值/日期字段转换：重点复核 evaluateFdgfGridTimeChanges、getSortNum 等方法中涉及的日期解析、数字格式转换是否对生物质场站的机组信息字段做了空值/格式防护（参考 Row 15 中已确认的 new BigDecimal() 无防护问题，属于本代码库中反复出现的同类模式，建议一并排查复用）。

效果：即便无法在本轮排查中锁定确切行号，补充异常兜底和日志后，下次同类问题复现时能够从日志直接定位到具体字段和堆栈位置，避免用户端只能看到无实际信息量的"运行时异常"提示。