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

Row 66:项目通过"删除"按钮删除后,新增同名项目提示"项目名已存在,请重新编辑!"

严重 2.1.待开发 全部类型 五区 模块:项目信息填报 处理人:周小龙

1基本信息

问题描述项目通过删除按钮删除之后,新增同项目名称的项目,出现"项目名已存在,请重新编辑!",新增不了项目的情况。
所属模块项目信息填报 / -
严重程度严重(阻断流程:是)
涉及类型全部类型
提出人刘向诚
处理人 / 状态周小龙 / 2.1.待开发(待调整)

2问题截图

生物质项目列表-已删除项目提示
图1:生物质项目列表,勾选"删除测试项目-2-测试删除项目名称重复"一行,工具提示气泡显示该行名称即为测试重复场景
删除后列表剩余数据
图2:删除操作完成后,列表共4条,"删除测试项目-2-测试删除项目名称重复"已从可见列表消失,说明前端界面上"看起来"已删除成功

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

① 前端删除入口 —— xnybw5f@backup730:src/views/projectNew/projectNewList.vue 第 494-529 行 _deleteBatch(goalRow),调用:

projectBaseApi.deleteBatchImpl(param).then(res => {   // 第519行
  this.$message.info('删除成功')
  this.getDataList(this.searchForm)                    // 重新查询列表,刷新后"看不到"该项目
})

② 后端删除实现 —— xnybw5b@730backup:src/main/java/cn/csg/so/oms/in/newenergy/project/appservice/ProjectImplAppService.java 第 1749-1839 行 deleteBatchImpl(ProjectVo vo),方法开头有一段非常关键的设计注释(第 1770-1774 行):

//删除机组
//删除批次
//删除场站
//删除场站项目关联
//删除项目          <-- 第1774行:设计上明确要"删除项目"这一步

但往下看整个方法的唯一一处落库操作(第 1836 行):

Map<String, Object> params = new HashMap<>();
params.put("implIdList", implIdList);
getCapBaseCommonDAO().update(
    "cn.csg.so.oms.in.newenergy.project.model.NePjImplVO_updateDelFlagByIds", params);  // 第1836行:只对"场站(impl)"记录做软删除
return "删除成功";                                                                        // 第1838行:直接返回成功,此后再无任何代码
根因说明:
级联删除只做了一半:第 1770-1774 行注释描述了"删除机组→删除批次→删除场站→删除场站项目关联→删除项目"五个步骤,但实际实现只对场站/实施记录(NePjImplVO,对应表 SO_IN_NE_PJ_IMPL)执行了 DEL_FLAG=1 的软删除(第 1809 行 impl.setDelFlag("1") + 第 1836 行批量更新),从未处理项目主表 SO_IN_NE_PJ(对应模型 NePjVO,含 PLAN_NAME 字段)——该表既没有被删除,也没有任何 DEL_FLAG 类字段可供标记(经查 NePjVO.javaNePjSQL_mysql.xml 均无 DEL_FLAG 相关定义)。
重名校验命中"僵尸"项目行:新增项目时前端调用 projectBaseApi.addOrUpdatePro → 后端 ProjectImplAppService.java 第 1158 行 checkProjectName(planName, opType, planId)(实现见第 1590-1607 行),其查询 SQL NePjSQL_mysql.xml:NePjVO_selectByPlanName(第 47-71 行)为:
SELECT ... FROM SO_IN_NE_PJ WHERE PLAN_NAME = #{planName}   -- 没有任何 DEL_FLAG 过滤条件
由于"删除"操作从未清理/标记 SO_IN_NE_PJ 里的项目行,这条 SQL 依然能查到"已删除"项目的那一行,checkProjectName 判定为重名,第 1159 行返回 "项目名已存在,请重新编辑!",用户因此无法用同名重新新增。
勾选项目 → 点击"删除"
deleteBatchImpl 只 UPDATE 场站(impl)表 DEL_FLAG=1
项目主表 SO_IN_NE_PJ 的 PLAN_NAME 行原样保留
列表查询过滤掉已删场站 → 界面上"看不到"该项目
用同名新增 → checkProjectName 查到僵尸行 → 报"项目名已存在"
这也解释了截图 Row 16(本表另一条记录)"选择项目删除之后项目还在,重新点击删除显示'请选择要删除的数据',刷新后项目并没有被删除"——两者根因高度一致:项目主表从未真正被清理。

4修复方案

修复代码文件:xnybw5b@730backup:src/main/java/cn/csg/so/oms/in/newenergy/project/appservice/ProjectImplAppService.java,在 deleteBatchImpl(第 1836 行更新 impl DEL_FLAG 之后、第 1838 行 return "删除成功" 之前)补上注释里原本设计但缺失的"删除项目"步骤:

getCapBaseCommonDAO().update(
    "cn.csg.so.oms.in.newenergy.project.model.NePjImplVO_updateDelFlagByIds", params);

// 新增:级联检查 —— 若该项目(planId)下已无任何未删除的场站(impl)记录,则一并清理项目主表,
// 避免项目名残留导致后续无法用同名重新新增
for (String planId : planIdList) {
    GetProjectAdjustQueryParam checkParam = new GetProjectAdjustQueryParam();
    checkParam.setApplyPlanIdList(Collections.singletonList(planId));
    checkParam.setPageNum(1);
    checkParam.setPageSize(1);
    IPage<NePjImplVO> remain = selectAll(checkParam);   // 复用本方法上文已使用的查询
    boolean noActiveImplLeft = remain.getRecords().stream()
            .noneMatch(item -> !"1".equals(item.getDelFlag()));
    if (noActiveImplLeft) {
        Map<String, Object> delProjectParams = new HashMap<>();
        delProjectParams.put("id", planId);
        getCapBaseCommonDAO().delete(
            "cn.csg.so.oms.in.newenergy.project.model.NePjVO_deleteById", delProjectParams);
    }
}

return "删除成功";

并在 NePjSQL_mysql.xml(对应 NePjSQL_dm.xml 同步补充)中新增一条按 ID 删除项目主表记录的 SQL:

<!-- 根据ID删除项目 -->
<delete id="NePjVO_deleteById" parameterType="string">
    DELETE FROM SO_IN_NE_PJ WHERE ID = #{id}
</delete>

备选方案:若担心物理删除影响历史审计/统计报表,也可为 SO_IN_NE_PJ 表新增 DEL_FLAG 字段做软删除,并同步在 NePjVO_selectByPlanName 查询中加上 AND (DEL_FLAG IS NULL OR DEL_FLAG != '1') 过滤条件——两种方案均可解决重名误判问题,物理删除实现更简单,软删除更利于留痕,建议与数据库管理员确认后二选一。

效果:项目下所有场站都被删除后,项目主表记录同步清理(或标记删除并在查重时过滤),后续用同一项目名称新增项目时 checkProjectName 不会再命中"僵尸"记录,"项目名已存在,请重新编辑!"的误报将不再出现。