计划/实际并网审核中或已审核的项目，删除后未真正拦截、也未真正清除Excel 第 62 行

① 基本信息

② 问题截图

③ 旧代码涉及的项目文件及行数

_deleteBatch(goalRow) {
  ...
  projectBaseApi.deleteBatchImpl(param).then(res => {
    this.tableLoading = false
    this.selectedData = []
    this.$message.info('删除成功')     // 无论后端 res 里返回的是"删除成功"还是"批量删除失败：xxx无法删除"的拦截文案，
                                         // 前端都不判断内容，一律提示"删除成功"并刷新列表
    this.getDataList(this.searchForm)
    this.$refs.listTable.tableClearSelection()
  }).catch((error) => { this.$message.error('调用接口出错:' + error) })
}

public String deleteBatchImpl(ProjectVo vo) throws Exception {
    ...
    String msg = validateProjectDelete(requestedImplIds, true);
    if (msg != "") { return msg; }   // 校验不通过时返回说明文字，HTTP状态码仍是200，前端未读取内容
    ...
}
// getDeleteBlockedReasons 中：
if (Integer.valueOf(1).equals(validation.getPlanGridBlocked())) {
    blockedReasons.add("计划并网容量信息处于审核中或已审核状态");
}
if (Integer.valueOf(1).equals(validation.getActualGridBlocked())) {   // 该字段永远是 null，见下方SQL
    blockedReasons.add("实际并网容量信息处于审核中或已审核状态");
}
if (Integer.valueOf(1).equals(validation.getMaterialBlocked())) {     // 该字段也永远是 null
    blockedReasons.add("并网资料信息处于审核中或已审核状态");
}

<select id="SoInNePjImplDO_selectDeleteValidation" ... resultType="...ProjectDeleteValidationVO">
    SELECT impl.ID AS implId, impl.PLAN_NAME AS planName, ...,
    CASE WHEN EXISTS (
        SELECT 1 FROM so_in_flow plan_flow
        WHERE plan_flow.PLAN_ID = impl.PLAN_ID AND plan_flow.FLOWSTATUS IN (1, 2)
    ) THEN 1 ELSE 0 END AS planGridBlocked   -- 只查了"计划并网"一种流程状态，
                                                 -- resultType 对应的 VO 还定义了 actualGridBlocked / materialBlocked 两个字段，
                                                 -- 但SELECT列表里完全没有对应的CASE子句，MyBatis自动映射结果为null
    FROM SO_IN_NE_PJ_IMPL impl WHERE impl.ID IN (...)
</select>

④ 修复代码涉及的项目文件及行数

SELECT impl.ID AS implId, impl.PLAN_NAME AS planName, impl.DISPATCH_NAME AS dispatchName, impl.GRID_CAPACITY AS actualGridCapacity,
CASE WHEN EXISTS (SELECT 1 FROM so_in_flow plan_flow WHERE plan_flow.PLAN_ID = impl.PLAN_ID AND plan_flow.FLOWSTATUS IN (1, 2)) THEN 1 ELSE 0 END AS planGridBlocked,
+CASE WHEN EXISTS (SELECT 1 FROM so_in_flow actual_flow WHERE actual_flow.PLAN_ID = impl.PLAN_ID AND actual_flow.FLOW_TYPE = 'ACTUAL' AND actual_flow.FLOWSTATUS IN (1, 2)) THEN 1 ELSE 0 END AS actualGridBlocked,
+CASE WHEN EXISTS (SELECT 1 FROM so_in_flow material_flow WHERE material_flow.PLAN_ID = impl.PLAN_ID AND material_flow.FLOW_TYPE = 'MATERIAL' AND material_flow.FLOWSTATUS IN (1, 2)) THEN 1 ELSE 0 END AS materialBlocked
FROM SO_IN_NE_PJ_IMPL impl WHERE impl.ID IN (...)

projectBaseApi.deleteBatchImpl(param).then(res => {
  this.tableLoading = false
-  this.$message.info('删除成功')
+  if (res.data && res.data.indexOf('无法删除') !== -1) {
+    this.$message.warning(res.data)   // 展示后端真实的拦截原因，不再一律提示"删除成功"
+  } else {
+    this.$message.success('删除成功')
+  }
  this.selectedData = []
  this.getDataList(this.searchForm)
  this.$refs.listTable.tableClearSelection()
})

⑤ 修复方案

本条本质是两个独立缺陷叠加，需要分别修复：

1. 后端漏拦截（安全/数据一致性问题，优先级更高）：SoInNePjImplDO_selectDeleteValidation SQL 只计算了 planGridBlocked（计划并网审核中/已审核），完全没有计算 actualGridBlocked（实际并网）和 materialBlocked（并网资料）两项，导致 Java 侧 Integer.valueOf(1).equals(null) 恒为 false，这两类审核状态下的项目能被真正删除掉。需要补齐 SQL 的两个 CASE WHEN 子句。
2. 前端误报"删除成功"（体验/误导问题）：_deleteBatch 不管后端返回内容是什么都提示"删除成功"，导致"计划并网审核中"项目本来已被后端正确拦截，用户却看到"删除成功"的假象，误以为系统有 bug、反复重试删除。需要读取后端返回文案，按"是否包含拦截关键字"区分成功/失败提示。