上周生产车间的同事在生产管理系统里用坯料管理模块的导入功能连着撞见两个怪事一是导入成功后表格不刷新得手动按 F5 才能看到新导入的坯料二是导入失败时只弹个导入失败的静态提示既不说失败原因也没法下载失败明细去排查。接到反馈我们很快定位到根因最后就改了前端一个文件把两件事都解决了后端接口一个字没动上线也是零回滚。这个修复的决策过程比修 bug 本身更值得记一笔。复现之后根因一眼就清楚了先复现选一个格式错误的坯料 Excel 点导入果然只弹静态失败提示没有下载入口选一个正确的文件导入接口返回 200但表格没刷新。然后翻导入组件的代码src/views/billet/components/billet-import.vuehandleConfirm的逻辑很简单把文件拼进formData调后端接口调完之后就什么都不做了——既没触发表格刷新的emits事件也没处理接口返回的errorDownloadPath和tip字段更没做自定义错误提示。再翻后端接口文档才发现这个导入接口早就支持返回失败文件下载路径和失败原因提示只是前端一直没接这部分逻辑等于后端的能力完全被闲置了。为什么只改前端定位到根因团队先讨论了两种方案改后端接口把失败提示和下载逻辑放后端处理或者只改前端把接口返回的字段接起来。最后选了只改前端理由很实在后端接口已经把需要的字段全都返回了不存在后端逻辑缺失改后端纯属重复造轮子只改前端的话改动面极小就一个组件的一个函数review 成本低上线风险几乎为零要是改后端还得协调后端排期、联调至少多花 2-3 天而前端当天就能提测。这也印证了之前踩过的一个坑遇到功能类问题先别急着动后端先看现有接口是不是已经支持对应能力很多时候问题只是前端没把逻辑接全。最小改动具体怎么落最终只给handleConfirm加了 4 行核心逻辑原有的提交、错误处理结构一字没动async function handleConfirm(): Promisevoid { formData.append(file, fileList.value[0].raw as File) submitLoading() try { // 等待接口返回获取后续需要的错误信息 const res await billetImport(formData) // 导入完成后触发父组件刷新表格数据 emits(getTableList) // 如果接口返回了失败文件下载路径弹出带下载按钮的提示 if (res.data?.errorDownloadPath) { ElMessageBox({ title: 导入失败, message: h(div, null, [ h(div, null, res.data?.tip), // 自定义下载按钮点击后触发下载逻辑 h(button, { style: color:#5688E8;cursor:pointer, id: messageBtn }, 点击下载导入失败信息) ]) }) } } catch (error) { // 原有错误处理逻辑保持不变 ElMessage.error(导入失败请稍后重试) } finally { submitLoading() } }逻辑很直白调完接口先拿返回结果触发表格刷新再判断有没有失败文件下载路径有就弹个带自定义下载按钮的提示框。那个下载按钮的点击事件可以后续单独迭代绑定这次先保证核心逻辑跑通正好符合最小改动解决核心问题。三个场景测完就敢提测改完只测了 3 个核心场景就提测正常导入成功的场景确认表格自动刷新、不用再手动 F5导入失败的场景确认弹出带下载按钮的提示、失败原因能正常展示边界场景比如没选文件就点确认原有错误提示没被破坏。测试同学只跑了导入相关用例没发现回归第二天上线生产侧反馈问题完全解决。回头看这件 bug 根子不在技术难度而在后端能力前端没接。以后遇到功能类反馈我会先翻一遍接口文档确认能力边界再决定改哪一层——能省掉大把没必要的联调时间。