2.2 KiB
2.2 KiB
消息库与协议检测前端性能检查
测试目标：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；本轮前端仅去除同目标重复提交，不取消或屏蔽新的请求。