diff --git a/BUG_401_ANALYSIS.md b/BUG_401_ANALYSIS.md
new file mode 100644
index 000000000..83737ec3e
--- /dev/null
+++ b/BUG_401_ANALYSIS.md
@@ -0,0 +1,36 @@
+# Bug #401 分析报告
+
+## 问题描述
+门诊完诊审计日志错误：div_log 表中 pool_id 与 slot_id 存值与设计规范不符。
+
+## 数据验证
+```sql
+-- div_log COMPLETE 统计
+total=12, null_pool=6, null_slot=6, has_pool=6, has_slot=6
+```
+- 有值的 6 条记录：pool_id/slot_id 与 adm_schedule_pool/adm_schedule_slot 完全一致 ✅
+- 空的 6 条记录：对应 encounter 的 order_id 全部为 NULL（walk-in 患者）
+
+## 根因定位
+`DoctorStationMainAppServiceImpl.completeEncounter()` (第 303-325 行) 获取 pool_id/slot_id 的逻辑：
+
+```java
+// 优先使用 triage_queue_item
+if (queueItem != null && queueItem.getPoolId() != null && queueItem.getSlotId() != null) {
+    divPoolId = queueItem.getPoolId();
+    divSlotId = queueItem.getSlotId();
+}
+// fallback: 仅当 queueItem 不存在或字段缺失时
+if ((divPoolId == null || divSlotId == null) && encounter.getOrderId() != null) {
+    ...
+}
+```
+
+**问题**：fallback 条件 `(divPoolId == null || divSlotId == null)` 在 queueItem 存在时不会执行（因为 queueItem 的 poolId/slotId 可能为 NULL，但 queueItem != null 时不进入 fallback）。实际上，对于有 encounter.orderId 的患者（挂号患者），应该始终通过 order → schedule_slot 获取权威的 pool_id/slot_id。
+
+## 修复方案
+调整 fallback 逻辑：只要有 encounter.orderId，就通过 order → schedule_slot 获取 pool_id/slot_id，不再依赖 queueItem 的字段值。queueItem 仅用于确定是否需要写审计日志的时机判断。
+
+## 影响范围
+- 修改文件：`DoctorStationMainAppServiceImpl.java`（约 10 行调整）
+- 不涉及数据库 DDL 变更