生成时间: 2026-08-03 · 数据来源: xnybw平台需求及工作计划.xlsx(南网在线绿能云缺陷跟踪表)· 仅针对 backup730/730backup 分支代码

Row 48:集中式实际并网容量提交失败(运行时异常)

严重 2.1.待开发 全部类型 五区 模块:实际并网流程 处理人:洪陈解

1基本信息

问题描述集中式实际并网容量提交失败。
所属模块实际并网流程 / 实际并网流程
严重程度严重(阻断流程:是)
涉及类型全部类型
提出人罗晶
处理人 / 状态洪陈解 / 2.1.待开发(研发自评:"冗余测试数据,需清理")

2问题截图

实际并网容量信息页面提交报错
图1:项目"测试验证-TEST#-南宁220千伏集中式风电项目" → 实际并网容量信息 Tab,顶部弹出红色提示条"运行时异常,请联系管理员!"

3旧代码定位(backup730 / 730backup 分支)

① 前端提示文案来源 —— xnybw5f@backup730:src/utils/request.js 第 144-183 行,axios 响应拦截器在业务码非 0 或 HTTP 非 2xx 时,直接把后端返回的 res.msg / data.msg 原样弹给用户:

// src/utils/request.js
if (res.code !== 0 /* ... */) {
  Message({ message: res.msg || 'Error', type: 'error' })   // 145-147行
}
// ...
Message({ message: data.msg || 'Error', type: 'error' })     // 156-158行
// ...
(error) => {
  Message({ message: error.message, type: 'error' })         // 176-183行 网络/HTTP层错误
}

说明"运行时异常,请联系管理员!"这句文案 不是前端硬编码,而是后端 msg 字段透传显示的。

② 后端提交入口 —— xnybw5b@730backup:src/main/java/cn/csg/so/oms/in/newenergy/project/controller/NePjImplAdjustController.java 与其抽象父类 controller/abs/AbstractNePjImplAdjustController.java 第 34-35 行:

@RequestMapping("/nePjImplAdjust")
public abstract class AbstractNePjImplAdjustController<T extends NePjImplAdjustVO>
        extends CapBaseController<NePjImplAdjustVO> {   // 提交/保存等 CRUD 全部继承自框架基类
}

③ 业务扩展类 —— appservice/NePjImplAdjustAppService.java 全文仅 24 行,是纯脚手架,未覆写任何方法:

@Service(value = "nePjImplAdjustAppService")
public class NePjImplAdjustAppService<T extends NePjImplAdjustVO>
        extends AbstractNePjImplAdjustAppService<NePjImplAdjustVO> {
    //TODO 请在此编写自己的业务代码      // 第23行:低代码脚手架,未填充任何自定义逻辑
}
根因说明:
① 提交链路无业务代码可查:实际并网容量提交走的是 comtop 低代码框架 CapBaseController → CapBaseAppService 通用 CRUD 链路(框架 jar 内编译代码,不在本仓库源码范围内),本仓库暴露出的 Controller/AppService 均为空扩展点,因此"运行时异常,请联系管理员"这句框架层兜底异常提示无法在本仓库源码中定位到抛出该文案的具体 throw 语句,如实说明"未能在业务代码中定位到明确抛出点"。
② 研发自评已定位数据层根因:处理人 洪陈解 在跟踪表中已将 dev_status 标注为"冗余测试数据,需清理"——结合截图中项目名"测试验证-TEST#-南宁220千伏集中式风电项目"带有明显测试标识,可推断该项目关联的机组/批次/发电单元数据存在脏数据(如重复主键、孤儿外键引用、批次与实际并网记录不一致等),触发框架层数据库唯一约束或空指针等 RuntimeException,被框架全局异常处理器统一包装成"运行时异常,请联系管理员"后返回。
点击"保存并提交审核"
POST /nePjImplAdjust/...(CapBaseController 通用提交)
脏测试数据触发框架层 RuntimeException
全局异常处理器兜底文案"运行时异常,请联系管理员"
前端 request.js 原样透传弹窗

4修复方案

4.1 数据层(即时止血,与研发自评一致):由数据库管理员/后端人员核对该测试项目在 NE_PJ_IMPL_ADJUSTNE_PJ_DET_ENERGY 等实际并网相关表中的记录,清理重复/孤儿测试数据后重新提交验证;建议同时在测试环境建立"测试数据"与"正式数据"隔离机制(本表 Row 10 已有同类问题记录),从源头减少此类脏数据。

4.2 代码层(长期加固):修复代码文件 xnybw5b@730backup:src/main/java/cn/csg/so/oms/in/newenergy/project/appservice/NePjImplAdjustAppService.java,在业务扩展点中覆写提交方法,捕获常见异常并转换为可自诊断的提示,而不是让框架兜底异常直接透传给互联网用户:

@Service(value = "nePjImplAdjustAppService")
public class NePjImplAdjustAppService<T extends NePjImplAdjustVO>
        extends AbstractNePjImplAdjustAppService<NePjImplAdjustVO> {

    private static final Logger logger =
        LoggerFactory.getLogger(NePjImplAdjustAppService.class);

    @Override
    public Result save(NePjImplAdjustVO vo) {
        try {
            // 保存前校验:机组编号/批次号等关键字段是否已被其他记录占用
            checkDuplicateBeforeSave(vo);
            return super.save(vo);
        } catch (DuplicateKeyException e) {
            logger.warn("实际并网容量提交唯一性冲突, implId={}", vo.getId(), e);
            return Result.fail("该批次/机组编号的实际并网数据已存在,请核实是否为重复提交或联系管理员清理冗余测试数据");
        } catch (Exception e) {
            logger.error("实际并网容量提交失败, implId={}", vo.getId(), e);
            return Result.fail("提交失败:数据校验未通过,请检查场站/批次/机组信息是否完整或重复后重试");
        }
    }
}
效果:短期通过清理该测试项目的脏数据即可解除阻断;长期在业务扩展类中补充异常捕获与语义化提示后,即使后续再出现同类脏数据问题,运维和用户也能从提示文案直接判断是"重复提交/数据冲突"而非无从下手的"运行时异常",减少对研发人工排查的依赖。