# 消息库与协议检测前端性能检查

测试目标：`C:/wechat_rpa`、`C:/kefu/wechat_rpa`。仅使用合成聊天数据、模拟 Qt 桥接；浏览器阻断外部网络，未操作企业微信或发送消息。

## 已复现与修复

| 场景 | 修改前 | 修改后 |
| --- | --- | --- |
| 连点“刷新消息库”5次 | 5次桥接调用 | 1次；按钮立即禁用 |
| 连点“检测本机协议”5次（协议目录） | 5次桥接调用 | 1次；按钮立即禁用 |
| 连点已选账号或会话5次 | 5次桥接调用 | 0次，无意义重复选择被跳过 |
| 连点另一个账号/会话5次 | 5次桥接调用 | 1次；随后改选其他目标仍提交 |
| 原目录中文输入法组字，每次停顿330ms | 查询`ni`、`nihao`、`你好` | 只查询最终`你好` |
| 原目录搜索中接收加载快照 | 丢失输入节点、焦点和输入值 | 保留节点、输入值、焦点、光标 |
| 患者关联加载中 | 无独立展示 | 显示“患者关联加载中”，不阻挡聊天/搜索/账号切换 |

普通快速搜索原本已有280ms防抖，5次快速输入仅查询最终值，不属于每键扫描。Qt协议检测原本也有running保护，前端5次桥接不等于实际启动5次检测。

合成500个会话、200条消息的加载状态变化造成整个列表重绘，测试环境约13–35ms；100次相同快照约18–20ms，列表DOM保持。该耗时不足以解释秒级至分钟级等待，因此本轮未扩展为列表虚拟化改造。

## 验证与文件

15项浏览器回归全部通过，JavaScript错误0。另已检查合成数据截图，患者关联提示不会遮挡聊天、列表和搜索。

- 修改前原始数据：`frontend-audit-before.json`
- 回归结果：`frontend-results.json`
- 测试脚本：`frontend-test.mjs`
- 文件SHA256：`frontend-files.json`
- 截图：`protocol-patient-loading.png`、`original-patient-loading.png`
- 两目录仅修改`assets/ui/console-app.js`、`assets/ui/zhenyang-ai-console.html`，JS缓存版本`loading1`。
- 备份：各目录`backups/loading-performance-20260917/frontend/`。

加载期间的新会话、新账号、最终搜索继续提交Qt；本轮前端仅去除同目标重复提交，不取消或屏蔽新的请求。