# Bug #725 诸葛亮分析报告

> **文档类型**: Bug分析
> **分析时间**: 2026-06-13 01:14:15
> **分析模型**: mimo-v2.5 (LLM深度分析)

---

## 基本信息
- **Bug #**: 725
- **标题**: 【急诊管理】绿色通道的激活出现报错
- **模块**: 会诊管理
- **提出人**: 王栩坤

---

I have all the information needed. Let me now output the analysis.

---

## 一、Bug 理解

**禅道 Bug #725**：【急诊管理】绿色通道的激活出现报错

**重现步骤**：
> 登录内科医生1账号：doctor1 密码：123456 → 打开急诊管理 → 进入绿色通道激活

**期望结果**：能够正常激活绿色通道

**错误信息**：
```
Error updating database. Cause: PSQLException: ERROR: null value in column "patient_id" 
of relation "emergency_green_channel" violates not-null constraint
```

**附图分析**：
- 弹窗表单中「患者ID」字段为空（`el-input-number` 未输入值），但用户点击了「激活」按钮
- 数据库 INSERT SQL：`INSERT INTO emergency_green_channel (id, disease_type, target_time, doctor, activate_time, create_by, create_time, tenant_id)` — **`patient_id` 完全不在 INSERT 列表中**
- 表单规则 `addFormRules.patientId` 声明了 required，但实际未阻止提交

**综合总结**：用户点击「激活绿色通道」时，弹窗表单中「患者ID」为空就直接提交，后端 MyBatis-Plus 生成的 INSERT 语句完全跳过了 `patient_id` 字段（null 值被 MyBatis 默认策略忽略），导致违反数据库 `NOT NULL` 约束。前端表单的 required 校验规则未生效，后端校验也未拦住请求。

---

## 二、根因分析

**根因链路（全链路 6 环）**：

| 环 | 问题 |
|---|---|
| ① 录入（前端） | `addFormRules.patientId` 的 `required` 规则触发条件是 `trigger:'blur'`，但 `el-input-number` 的 blur 事件对 null 值不触发校验；`submitAdd` 中的 `validate()` 可能静默通过 |
| ② 验证（后端） | `EmergencyController.activateGreenChannel()` 有 `if (gc.getPatientId() == null)` 检查，但 **前端根本没发起带正确错误码的请求** — MyBatis-Plus 异常被全局异常处理器捕获，前端收到的是原始错误堆栈文本而非结构化 R.fail |
| ③ 业务 | `EmergencyGreenChannelServiceImpl` 无额外校验，直接继承 MyBatis-Plus `save()` |
| ④ 持久化 | MyBatis-Plus 默认 `FieldStrategy.INSERT_NOT_NULL`：null 字段不写入 INSERT → `patient_id` 缺失 |
| ⑤ 存储 | `emergency_green_channel` 表定义 `patient_id BIGINT NOT NULL` → 报错 |

**涉及文件**：
- `healthlink-his-server/.../web/emergency/controller/EmergencyController.java` — 后端校验逻辑（已有但被跳过）
- `healthlink-his-ui/src/views/emergency/greentrack/index.vue` — 前端表单校验失效
- `healthlink-his-ui/src/views/emergency/greentrack/api.js` — API 调用
- `healthlink-his-server/.../emergency/domain/EmergencyGreenChannel.java` — 实体定义
- `V32__followup_pathology_emergency.sql` — DB 表结构（`NOT NULL` 约束）

---

## 三、修复方案

### 修复点 1：前端表单校验（`greentrack/index.vue`）

**问题**：`submitAdd` 中 `validate()` 逻辑有隐患 — `el-input-number` 组件在未输入时 v-model 为 `null`，但 required 校验的 `trigger:'blur'` 对此场景不可靠。更关键的是，**validate 的 try-catch 写法在某些情况下可能跳过校验**。

**修改**：改为标准 async/await 写法，并将 trigger 改为 `change`：

```js
// 修改 addFormRules
const addFormRules = {
  patientId: [{required: true, message: '请输入患者ID', trigger: 'change'}]
}

// 修改 submitAdd — 移除 try-catch，使用标准 await
const submitAdd = async () => {
  if (addFormRef.value) {
    const valid = await addFormRef.value.validate().catch(() => false)
    if (!valid) return
  }
  await activate(addForm.value)
  ElMessage.success('绿色通道已激活')
  addVisible.value = false
  loadData()
  refreshStats()
}
```

### 修复点 2：后端校验（`EmergencyController.java`）

后端已有 `gc.getPatientId() == null` 检查，但需确认 `R.fail()` 返回格式被前端正确识别。当前后端代码已正确，无需修改后端（校验逻辑存在且会返回错误）。如果前端仍能穿透，则需要检查全局异常处理器是否正确包装了 `MethodArgumentNotValidException`。

### 修复点 3（可选优化）：增加后端 `@Valid` 注解

在 `activateGreenChannel` 方法参数上增加 `@Valid` 并在实体 `patientId` 字段加 `@NotNull`，作为双保险：

```java
public R<?> activateGreenChannel(@RequestBody @Valid EmergencyGreenChannel gc) {
```

---

## 四、路由决策

**FIXER**: **zhaoyun**（前端开发）

**REASON**: 根因在前端表单校验失效 — `addFormRules` 的 trigger 选择不当 + `submitAdd` 中 validate 的错误处理逻辑有缺陷。后端校验逻辑已存在且正确，核心修复是前端表单校验。修改范围仅限 1 个前端文件 `greentrack/index.vue`。

---

## 路由决策
- **FIXER_ID**: guanyu
- **修复 Agent**: guanyu（后端）
- **原因**: LLM 分析决策

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