kefu/deploy/loading-performance-20260917/TEST_REPORT.md

消息库加载与协议检测优化

日期：2026-09-17

已更新 C:\kefu\wechat_rpa 和 C:\wechat_rpa 的共用消息库/界面代码；协议优化仅更新已有协议功能的 C:\wechat_rpa。保留两目录其他差异。

结果

• 本地聊天先显示，远程患者关联单独加载。患者接口超时不再挡住消息列表，且旧会话的迟到结果不会覆盖当前会话。
• 加载期间保留最后一次切账号、切会话与搜索；患者关联请求最多一个执行中加一个最新待办，避免堆积。
• 缓存文件信息、联系人名称、统计及会话行号；切换只读所需消息页。显式刷新、数据库/WAL变化、文件替换会使缓存失效；取行时核对会话，防止文件替换竞争导致串消息。
• 消息库旧会话搜索不再受最近1000会话的限制。
• 协议健康检测只准备当前账号的 message.db，不再初始化其他历史账号及联系人表。实际回复仍加载需要的元数据。
• 同轮只读协议检测复用大文件构建哈希；新进程、文件变化、下一轮检测、实际发送仍重新校验。保留当前账号和发送入口检查，没有缓存登录就绪判断。
• 协议检测和消息库同时请求密钥时共用一次进行中的读取；完成后再次主动获取仍执行新校验。
• 去掉重复刷新、重复选择；中文输入法仅搜索最终文字，加载时保留搜索焦点与光标。协议检测实际耗时写入运行日志。

测量

以下均为临时合成数据与组件测量，不是线上端到端保证。

测量范围	优化前	优化后
50万消息、2500会话，首次打开本地浏览模型	1.363 秒	1.221 秒
同样数据，重复切换会话	1.297–1.394 秒	2.7–4.4 毫秒
搜索旧会话	1.341 秒且漏查	58.4 毫秒，正确返回
4账号、24库、6万联系人：协议数据库准备	1708.684 毫秒	22.029 毫秒
64 MiB构建文件，同轮两次完整哈希校验	255.550 毫秒	149.119 毫秒
连点刷新/检测5次	5次界面调用	1次

在另一个控制实验中，仅模拟患者接口延迟300毫秒，本地结果等待由约301毫秒降至不到1毫秒；这是解除网络等待的验证，不包含真实数据库读取成本。

首次没有可用密钥时仍需本机初始化，数据库或WAL变化后也需要重建受影响缓存。这些必要工作没有被跳过。

原始数据：本地浏览最终基准、优化前、协议组件基准、网络等待控制实验。

验证

• 原版目录：105项通过、1项协议能力不适用跳过、0失败。
• 协议目录：263项通过、0失败。
• 两目录界面交互：15项通过、JavaScript错误0；合成截图已检查。
• 覆盖缓存失效、WAL、账号隔离、数据库替换竞争、协议构建变化、当前账号健康检查、旧审核入口及归档模拟传输。
• 所有验证使用隔离数据与模拟服务，没有发送真实聊天、注入真实进程或改动真实队列、密钥和数据库。

结果：原版、协议版、界面。中间测试中的请求被隔离器拦截，是模拟传输层位置问题；最终隔离器继续阻止真实网络，上述最终回归全部通过。

使用与回滚

当前运行的是 Python 源码客户端，重新启动对应目录的客户端即可加载优化。未主动终止或重启当前程序，未重新制作安装包。

源码备份位于两个目录的 backups/loading-performance-20260917，前端位于其 frontend 子目录。当前变更文件及SHA256见清单。回滚时只恢复对应代码文件，勿覆盖真实数据与登录配置。