① 基本信息
| 问题描述 | 调度材料补录点击处理后报404 |
|---|---|
| 一级模块 | 调度材料补录 |
| 二级模块 | 调度材料补录 |
| 涉及类型 | 全部类型 |
| 所属区域 | 五区 |
| 严重性 | 严重 |
| 当前状态 | 2.1.待开发 |
| 研发处理人 | 周小龙 |
| 处理说明 | 待调整 |
② 问题截图
gec.csg.cn:10288/project-history-record-list/project-form?...，返回的是 nginx 层的 "404 Not Found"（非 Vue 路由内的"页面未找到"提示），说明该路径在服务器/网关层根本没有被转发到任何已部署应用③ 旧代码涉及的项目文件及行数（backup730/730backup 分支排查结果）
在 xnybw5f（backup730）和 xnybw5b（730backup）两个仓库中，对"调度材料补录""在途历史补录""project-history-record-list"等关键词做了全仓库文本检索（
git grep，覆盖 .vue/.js/.java/.json 全部文件类型），均未检索到任何一处命中。同时检查了 xnybw5f 全部路由文件（src/router/index.js、src/router/modules/base.js、src/router/modules/projectMaintain.js），也没有任何路径匹配 /project-history-record-list 或 /project-form（后者虽然路径片段相同，但对应的是完全不同的"项目信息管理"路由，组件也不同）。
xnybw5f / vue.config.js
第 6-7 行：publicPath: '/IntegrationNewenergyGridWebTh'，outputDir: 'IntegrationNewenergyGridWebTh'
module.exports = defineConfig({
publicPath: '/IntegrationNewenergyGridWebTh', // 本应用部署后的所有路由都应带此前缀
outputDir: 'IntegrationNewenergyGridWebTh',
...
关键证据：截图中出问题的 URL 是
gec.csg.cn:10288/project-history-record-list/project-form?...，路径里完全没有 /IntegrationNewenergyGridWebTh 这个本应用固定的发布路径前缀。这说明"调度材料补录 > 在途历史补录"这个菜单项，指向的其实是部署在同一网关下的另一个独立前端应用（很可能是一个单独的微前端子应用或旧版历史系统），并不属于 xnybw5f 这份代码。
xnybw5b / src/main/java/cn/csg/so/oms/in/newenergy/project/controller/HistoryProjectController.java
第 37 行 @RequestMapping("/newenergy/history")；第 47-63 行 getProjectListByPhone；第 68-82 行 validateAccess
@RestController
@Api(tags = "历史项目并网资料补录")
@RequestMapping("/newenergy/history")
public class HistoryProjectController extends AbstractOAuthController<OAuthSessionVO> {
@PostMapping("/getProjectListByPhone") // 仅查询列表
public IPage<HistoryProjectVO> getProjectListByPhone(...) { ... }
@PostMapping("/validateAccess") // 仅校验是否可访问
public Boolean validateUserTokenPhone(...) { ... }
// 全类仅这两个接口，没有任何返回"表单详情/处理页数据"的接口，
// 也没有任何代码引用或拼接 "project-history-record-list" 这个路径
}
后端确实存在一个语义相关的"历史项目并网资料补录"模块（
HistoryProjectController / HistoryProjectFacade），但只实现了"列表查询"和"权限校验"两个接口，没有配套的"处理/详情表单"接口；xnybw5f 前端也完全没有调用这两个接口的代码（git grep getProjectListByPhone 在前端仓库零命中）。据此判断这个后端模块目前是"孤立"状态——尚未与任何前端页面对接。
④ 修复代码涉及的项目文件及行数
无法在 backup730/730backup 中定位到"调度材料补录 > 在途历史补录"页面对应的前端源码，因此无法给出该功能自身的代码级修改点。这不属于"抓不到线索"的空泛结论，而是有明确排查依据的结论（见上一节的路径前缀比对与全仓库检索结果）。
建议按以下方向核实，而不是在 xnybw5f/xnybw5b 里定位代码：
- 核实网关 / Nginx / 微前端（qiankun 等）注册表中，
/project-history-record-list这个路径前缀对应的子应用是否存在、是否已正常部署到gec.csg.cn:10288这台环境； - 如果该子应用属于其他团队/其他仓库维护，需要同步该团队排查为什么访问会落到 nginx 默认 404（大概率是 location 转发规则缺失或子应用未随本次环境一起发布）；
- 若确认"调度材料补录"这个菜单项本应指向 xnybw5b 已有的
HistoryProjectController模块，则需要补齐前端页面（列表+处理表单）与"详情/处理"接口，并把菜单跳转地址改为本应用自己的路由（会带/IntegrationNewenergyGridWebTh前缀），而不是当前这个查无实据的独立路径。
⑤ 修复方案
本条问题的现象（点击"处理"跳转到 project-history-record-list/project-form，返回 nginx 级 404）在证据链上明确指向部署/网关层面的路由缺失，而不是 xnybw5f/xnybw5b 代码里的业务逻辑缺陷：
- 目标 URL 不带本应用固定的发布路径前缀
/IntegrationNewenergyGridWebTh，说明它不是 xnybw5f 自身的路由跳转结果； - xnybw5f 全仓库检索不到任何"调度材料补录""在途历史补录""project-history-record-list"字样，说明该菜单项/跳转链接的定义也不在这份前端代码里（大概率是配置在动态菜单系统或另一独立子应用里）；
- xnybw5b 虽有一个语义相关但尚未与任何前端对接的
HistoryProjectController，说明后端为此功能预留了雏形，但前端从未接入。
建议处理路径：先由运维/网关侧确认 project-history-record-list 这个独立应用的部署状态与转发规则；如确认该功能应该并入 xnybw5 现有体系，再评估是复用 HistoryProjectController 现有接口补齐前端页面，还是保留独立子应用但修复其网关转发配置。这两条路径都不是在 xnybw5f/xnybw5b 里"改几行代码"能解决的，需要与部署/网关或该子应用负责团队一起确认后再排期。
结论：本行问题根因大概率不在 backup730/730backup 分支代码范围内，建议优先排查部署与网关配置。