呱呱 问题修复
界面改动必须读渲染后的真实 DOM 才算验过
改样式或交互后，「进程活着」「没有报错」「接口 200」都不算验过。必须打开真实界面读渲染后的 DOM，断言元素数量、布局结果、交互效果。
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
适用场景
界面改动验证UI验证改完样式自测验证点击没反应
解决思路
- 四层判据逐级升高：①进程活着（最弱，完全不说明问题）②真渲染了（有窗口/renderer 进程）③界面内容真的出现（读 DOM 断言特征元素）④交互真的生效（真点一下再看结果变化）
- 用浏览器/调试协议读真实 DOM，别靠肉眼或「看起来对」
- 断言要落到具体数量：元素个数、每项的按钮数（能抓出重复渲染这类问题）
- 点完要看**页面内容变化**，不是看路由/hash 变了——hash 变了但页面没动是常见失败模式
- 自查时先确认验的是最新构建：改了路由表/顶层结构后热更新可能不生效，要强制刷新再断言
适用边界 · 注意事项
- ❌ 别用「能启动/无报错」交付 GUI 改动 —— 这是被反复抓到的漏检
- ❌ 别把「接口返回 200」当成功能可用
- 别只用肉眼截图判断「看着没问题」，要读 DOM 拿到可断言的数值
完整经验
问题：改完界面（样式、布局、交互）自己验过说没问题，用户一看就是坏的——比如每项画了两遍、点了没反应。
根因：验证停留在「能启动、无报错、接口 200」，这些都不反映界面实际状态。
解决：判据分四层，逐级升高，至少要做到第三层：① 进程活着（最弱）② 真渲染了（有窗口/renderer 进程）③ **界面内容真的出现**（读渲染后的 DOM 断言特征元素）④ 交互真的生效（真点一下，断言结果变化）。
关键细节：
· 用调试协议/CDP 读真实 DOM，别靠肉眼。
· 断言落到具体数量——比如「每个列表项内部有几个按钮」，>1 就说明重复渲染了。
· 点完看**页面内容**变化，不是看路由变了。路由跳转正常但主区一动不动是常见 bug。
· 改了路由表或顶层结构后，热更新往往不生效，必须先强制刷新再断言，否则验的是旧模块。
这套同样适用于「从用户那版包复现问题」：要拿用户装的**那个版本**测，别用最新构建——版本比线上新时根本复现不出问题。