# Bug #749 诸葛亮分析报告 > **文档类型**: Bug分析 > **分析时间**: 2026-06-12 22:44:54 > **分析模型**: mimo-v2.5 (LLM深度分析) --- ## 基本信息 - **Bug #**: 749 - **标题**: 【门诊医生工作站】门诊医生工作站无法对患者进行保存医嘱的 - **模块**: 门诊医生工作站 - **提出人**: 王栩坤 --- Now I have enough understanding of the code flow. Let me compile my analysis. --- ## 一、Bug 理解 **原文引用 — 禅道 Bug #749:** > **标题**:【门诊医生工作站】门诊医生工作站无法对患者进行保存医嘱的 > > **重现步骤**:登录内科医生1的账号:doctor1 密码:123456 进入门诊医生工作站 → 保存一个诊断 → 进入医嘱 → 新增一条医嘱 → [结果] 点击了保存,无法保存成功,点击保存按钮无法响应 > > **期望结果**:能够将医嘱保存成功,状态有待保存,变成待签发的状态 **附图关键信息:** - 医嘱Tab页已打开,列表中有 3 条已保存医嘱(已签发×2、已收费×1) - 顶部有一条**"待保存"状态的新行**:医嘱类型显示"选择..."(未选择)、项目未输入、药房/科室"请选择药房"(未选择) - **保存按钮**(蓝色)可见,但用户反映点击后无法响应 **综合总结**:用户在门诊医生工作站的医嘱Tab页新增了一条医嘱行,尝试点击"保存"按钮将医嘱从"待保存"变为"待签发",但按钮点击后没有任何响应,保存未生效。根据截图中"待保存"行关键字段(医嘱类型、项目、药房)均为空的状态,判断该行的**展开编辑区域(expand row)仍然处于打开状态**,导致 `handleSaveBatch()` 中的前置校验拦截了保存操作。 --- ## 二、根因分析 **核心问题:** `handleSaveBatch()` 函数在 line 3738-3741 检查了展开行状态: ```javascript // line 3738-3741 prescriptionlist.vue const prescriptionExpandOrder = prescription.expandOrder || []; if (prescriptionExpandOrder.length > 0) { proxy.$modal.msgWarning('请先点击确定确认当前医嘱'); return; // ← 保存被拦截 } ``` **关键发现:** 这里的检查目标是 `prescription.expandOrder`(处方对象的属性),**不是**组件的 `expandOrder.value`(控制实际展开行的响应式变量)。`prescription.expandOrder` 在 `createNewPrescription()` 中被初始化为 `[]`,此后**从未被修改**,所以此检查永远为 false — 这是一段**无效的死代码**。 **真正的拦截点**在更上游的几个校验。结合截图分析,用户点击"保存"时: 1. **展开编辑行仍然打开**:用户新增医嘱行后(`handleAddPrescription`),如果选了项目但没点展开行中的"确定"按钮确认,行仍处于 `isEdit: true` 状态 2. **`handleSaveBatch` 中 `saveList` 构建问题**:`saveList` 过滤条件中检查 `item.prescriptionId === targetPrescriptionId`,但从 `getListInfo` 加载的历史医嘱**没有 `prescriptionId` 字段**(因为 `prescriptionId` 是前端本地生成的处方ID),导致只有通过 `handleAddPrescription` 新增的行才有正确的 `prescriptionId` 匹配 3. **`handleSaveSign` 对新医嘱不调 API**:当用户点击展开行中的"确定"按钮时,`handleSaveSign` 对没有 `requestId` 的新医嘱只做前端状态更新(`isEdit = false`),**不调用后端保存接口**,真正的保存依赖后续点击"保存"按钮 **最可能的失败场景:** - 用户新增行 → 未完全填写展开行 → 直接点击"保存" → 前置校验(如 `expandOrder.value.length > 0`、或 `accountId` 校验)拦截 → 弹出警告但用户可能忽略 - 或者用户填写了展开行但未点击"确定"就点击"保存" → 保存被 `expandOrder` 拦截 **涉及文件:** - `healthlink-his-ui/src/views/doctorstation/components/prescription/prescriptionlist.vue` — `handleSaveBatch()` (line 3693)、`handleSaveSign()` (line 3500)、`handleAddPrescription()` (line 2370) - `healthlink-his-ui/src/views/doctorstation/components/api.js` — `savePrescription()` (line 295) - `healthlink-his-server/.../DoctorStationAdviceController.java` — `saveAdvice()` (line 560) --- ## 三、修复方案 ### 方案 A:UX 修复 — 让保存按钮对"未确认"的行也能正常保存 **核心思路**:用户点击"保存"时,自动完成未确认行的关闭操作,而不是拦截并弹出警告。 **修改文件:** `prescriptionlist.vue` **修改 1:** 在 `handleSaveBatch()` 中,移除无效的 `prescription.expandOrder` 检查(line 3738-3741),改为检查组件级 `expandOrder.value`,并在有展开行时**自动关闭**而非拦截: ```javascript // 替换 line 3738-3741 // 删除旧的无效检查: // const prescriptionExpandOrder = prescription.expandOrder || []; // if (prescriptionExpandOrder.length > 0) { ... } // 改为:如果有展开行,自动关闭展开行 if (expandOrder.value.length > 0) { updateExpandOrder([]); } ``` **修改 2:** 在 `handleSaveBatch()` 的 `saveList` 过滤中,移除 `prescriptionId` 匹配条件(因为历史医嘱没有此字段),改为对所有 `statusEnum == 1 && !isSaved` 的行都能保存: ```javascript // 修改 saveList 过滤条件(约 line 3823) .filter((item) => { return item.statusEnum == 1 && !item.isSaved; // 删除:&& (item.prescriptionId === targetPrescriptionId || !item.prescriptionId) }) ``` **修改 3:** 给"保存"按钮增加明确的校验提示(当存在未填写完整的新行时): ```javascript // 在 saveList 过滤后,检查是否有未填完关键字段的行 const incompleteItems = saveList.filter(item => !item.adviceType || !item.adviceName || !item.encounterId ); if (incompleteItems.length > 0 && saveList.length === incompleteItems.length) { proxy.$modal.msgWarning('请先选择医嘱类型和项目,填写完整后再保存'); return; } ``` ### 方案 B(如果方案 A 改动太大):仅确保按钮可见反馈 在 `handleSaveBatch` 的每个 `return` 前,确保有明确的 `proxy.$modal.msgWarning()` 提示,让用户知道为什么保存失败。 --- ## 四、路由决策 **FIXER: zhaoyun(赵云)** **REASON:** 该 Bug 主要涉及前端 `prescriptionlist.vue` 的 UX 和数据流问题(保存按钮点击无响应、展开行状态管理、保存过滤条件),属于前端交互和界面逻辑修复范畴,由前端开发 Agent 赵云负责。无需数据库迁移或后端接口修改。 --- ## 路由决策 - **FIXER_ID**: zhaoyun - **修复 Agent**: zhaoyun(前端) - **原因**: ** 该 Bug 主要涉及前端 `prescriptionlist.vue` 的 UX 和数据流问题(保存按钮点击无响应、展开行状态管理、保存过滤条件),属于前端交互和界面逻辑修复范畴,由前端开发 Agent 赵云负责。无需数据库迁移或后端接口修改。 > ⚠️ 修复人员请先验证以上分析是否正确,再执行修复。