有了 vConsole，我们为什么还要做 PageSpy

接上回《支持远程调试的 "vConsole"》发出后，大家对此挺感兴趣，所以咱这回接着唠。

起初在开发 PageSpy 的时候，我们是想着解决 vConsole 做不到的事情，也就是远程调试的工作协同：开发人员在上海，测试、产品等团队在深圳。

那时候是这样的啊，项目白屏了、程序报错了、接口 Error 了，完事儿让测试人员对着 vConsole 截图，人家怎么知道截啥图、截哪个面板的图？具体来说，打个比方：js 里通过 res.data.users.map(fn) 去遍历用户渲染，但是由于种种原因，接口返回的数据长这样式儿的：

{
    "success": true,
    "message": "请求成功",
    "data": null
}

测试人员在 vConsole 看到的、最直观的也就是以下 "报红" 错误信息：

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 等方式的部署方案，一键部署、一劳永逸，使用起来非常简单。

有问题大家可以加入技术支持群。