接上回《支持远程调试的 "vConsole"》发出后,大家对此挺感兴趣,所以咱这回接着唠。
起初在开发 PageSpy 的时候,我们是想着解决 vConsole 做不到的事情,也就是远程调试的工作协同:开发人员在上海,测试、产品等团队在深圳。
那时候是这样的啊,项目白屏了、程序报错了、接口 Error了,完事儿让测试人员对着 vConsole 截图,人家怎么知道截啥图、截哪个面板的图?具体来说,打个比方:js 里通过 res.data.users.map(fn)
去遍历用户渲染,但是由于种种原因,接口返回的数据长这样式儿的:
json
{
"success": true,
"message": "请求成功",
"data": null
}
测试人员在 vConsole 看到的、最直观的也就是以下 "报红" 错误信息:
bash
Uncaught TypeError: Cannot read properties of null (reading 'users')
at <压缩后的.js>:3:10010
当测试小姐姐把这个错误截图发过来的时候,对开发人员排障有什么帮助吗?有的!我们从中可以得知:
- 读取的是某个对象的
users
属性; - 是在 <压缩后的.js> 第 3 行、第 10010 列处发生的问题;
信息量够吗?单独针对于这个场景,勉强可以接受,虽然 .users
的关键词搜索结果很多,但因为我们可以去扒 <压缩后的.js> 文件,耐心的定位到错误堆栈的具体报错位置,再结合我们自身对这个项目源代码的熟悉、理解,有经验的同学还是能够找到问题所在的,但是大家等我说完这一大串也能感受到,整个排查的过程下来会很累。。。
那如果客户端报错的现场不是在测试小姐姐那边、是在我们本地谷歌浏览器的话,排障的流程又会是什么样子的呢?
- 发现 Console 面板报错,堆栈中有源码索引;
- 点击后会定位到源文件的原始行列;
- 初步确认数据有问题后,切换到 Network 面板,查看接口返回的数据;
- 确认问题。
相比上面的 "盲人摸象",本地的排障非常的自然、顺畅。
正因如此,PageSpy 本着向控制台看齐的初衷,基本还原了控制台排障的流程:
- 当程序报错时支持可以查看错误堆栈
- 支持定位源码
- 查看网络请求和响应数据
除了上面提到的这些功能外,我们在 PageSpy 的应用截图中也可以看到其他的信息:
- 左上角自动识别了当前客户端的系统、浏览器,当鼠标划过时还会显示更加具体的版本详情;
- 中间顶部显示着当前调试连接的在线状态;
- 侧边栏按钮中得知可以查看日志输出、网络请求、页面渲染状况、缓存信息、系统信息(这是什么?);
当开发者直面这些数据的时候,大多数问题将迎刃而解。今天我们先分享到这里,大家如果感兴趣的话,可以查看 官网文档,官方提供了 Docker / Node 等方式的部署方案,一键部署、一劳永逸,使用起来非常简单。
有问题大家可以加入 技术支持群。