Bug #750 诸葛亮分析报告

文档类型: Bug分析 分析时间: 2026-06-12 22:27:51 分析模型: mimo-v2.5 (LLM深度分析)

基本信息

Bug #: 750
标题: 【收费工作站-住院登记】修改患者登记信息（如费用性质）并保存后，系统未更新原记录而是新增了一条重复记录
模块: 住院登记管理
提出人: 陈显精

Now I have enough information to provide the analysis. Let me compile the full diagnosis.

一、Bug 理解

禅道 Bug 标题：【收费工作站-住院登记】修改患者登记信息（如费用性质）并保存后，系统未更新原记录而是新增了一条重复记录

重现步骤：

登录系统，进入 [收费工作站] → [住院登记]
切换到 [已登记入院] 页签，找到一条已存在的登记记录（如：序号9，测试患者戊，费用性质为"全自费"）
点击操作列下的 [修改] 按钮，打开"修改登记"弹窗
将"费用性质"从"全自费"修改为"职工基本医疗保险"
点击 [保存]，系统提示"住院登记操作成功"

期望结果：修改保存后，系统只保留一行该患者的记录，且费用性质成功更新。

附图关键信息：

弹窗中"费用性质"被红框标注为"职工基本医疗保险"（修改后值），"保存"按钮被红框圈出
列表中序号8（旧数据"全自费"）和序号9（新数据"职工基本医疗保险"）同时存在，红字标注"生成了两条重复的数据"
两条记录的登记时间完全相同（2026-06-07 21:42:13），说明不是两次独立操作

综合总结：用户在"已登记入院"列表点击修改并保存后，系统本应在原记录上更新费用性质，但实际行为是保留了原记录并新增了一条相同记录，导致同一患者出现两条住院登记。保存操作被错误地执行为"新增"而非"更新"。

二、根因分析

核心问题：InHospitalRegisterAppServiceImpl.updateRegistration() 方法中，使用 iEncounterService.saveOrUpdate(encounter) 保存修改后的 encounter 时，MyBatis-Plus 将其执行为 INSERT 而非 UPDATE，导致生成新记录。

技术根因链路：

配置冲突：HisBaseEntity.deleteFlag 字段标注了 @TableLogic(value = "0", delval = "1")，但全局配置 application.yml 中设置 logic-delete-value: 0（应为1）和 logic-not-delete-value: 1（应为0），二者矛盾。虽然注解优先于全局配置，但这种不一致可能导致 saveOrUpdate 内部的存在性检查逻辑产生非预期行为。
saveOrUpdate 的二义性：该方法依赖 entity 的 id 是否为 null 来判断 INSERT/UPDATE。虽然 getById 理论上返回了正确的 entity（含 id），但 saveOrUpdate 在多租户拦截器（TenantLineInnerInterceptor）+ 逻辑删除注解（@TableLogic）的叠加作用下，其内部的 selectById 查询可能返回 null（例如 tenant_id 过滤条件不匹配），从而触发 INSERT 分支。

@TableLogic 与全局配置冲突（application.yml）：

mybatis-plus:
  global-config:
    db-config:
      logic-delete-field: validFlag   # 全局指定 validFlag（但实体用的是 deleteFlag）
      logic-delete-value: 0           # 0=已删除（注解是 0=未删除）
      logic-not-delete-value: 1       # 1=未删除（注解是 1=已删除）

涉及文件：

文件	角色
`InHospitalRegisterAppServiceImpl.java:377-475`	`updateRegistration()` 方法 — 问题入口
`HisBaseEntity.java`	`@TableLogic(value="0", delval="1")` 注解 — 配置冲突
`MybatisPlusConfig.java`	多租户 + 乐观锁 + 逻辑删除拦截器链
`application.yml:93-100`	MyBatis-Plus 全局配置 — 与注解矛盾
`accomplishList.vue:286-302` / `patientRegister.vue:455-475`	前端调用链

三、修复方案

方案：将 `saveOrUpdate` 改为显式 `updateById`

最安全、最精确的修复是：在 updateRegistration 中已通过 getById 确认记录存在并获取了完整 entity（含 id），因此无需使用具有二义性的 saveOrUpdate，直接使用 updateById 确保执行 UPDATE。

修改文件：InHospitalRegisterAppServiceImpl.java

// 第406行附近，修改前：
iEncounterService.saveOrUpdate(encounter);

// 修改为：
iEncounterService.updateById(encounter);

同样，病区信息和账户信息的 saveOrUpdate 也应替换为显式更新：

病区更新（约第419行）：

// 修改前：
iEncounterLocationService.saveOrUpdate(encounterLocationReg);

// 修改为：
iEncounterLocationService.updateById(encounterLocationReg);

账户更新（约第429-470行中所有 saveOrUpdate 调用）：

// 修改前：
iAccountService.saveOrUpdate(cashAccount);
// 修改为：
iAccountService.updateById(cashAccount);

// 同理修改所有 iAccountService.saveOrUpdate(...) 调用

注意：账户的"else"分支（账户不存在时创建新账户）保持使用 iAccountService.save(newAccount) 不变。

四、路由决策

FIXER: guanyu

REASON: 根因在后端 InHospitalRegisterAppServiceImpl.updateRegistration() 的 MyBatis-Plus saveOrUpdate 调用需改为 updateById，纯后端 Java 修复，属于 guanyu（后端开发）的职责范围。

路由决策

FIXER_ID: guanyu
修复 Agent: guanyu（后端）
原因: LLM 分析决策

⚠️ 修复人员请先验证以上分析是否正确，再执行修复。

5.6 KiB Raw Blame History Unescape Escape