起初在开发 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 :3:10010
当测试小姐姐把这个错误截图发过来的时候，对开发人员排障有什么帮助吗？有的！我们从中可以得知：
[ol]
[/ol]
信息量够吗？单独针对于这个场景，勉强可以接受，虽然 .users 的关键词搜索结果很多，但因为我们可以去扒 文件，耐心的定位到错误堆栈的具体报错位置，再结合我们自身对这个项目源代码的熟悉、理解，有经验的同学还是能够找到问题所在的，但是大家等我说完这一大串也能感受到，整个排查的过程下来会很累。。。
那如果客户端报错的现场不是在测试小姐姐那边、是在我们本地谷歌浏览器的话，排障的流程又会是什么样子的呢？
相比上面的 "盲人摸象"，本地的排障非常的自然、顺畅。
正因如此，PageSpy 本着向控制台看齐的初衷，基本还原了控制台排障的流程：
除了上面提到的这些功能外，我们在 PageSpy 的应用截图中也可以看到其他的信息：
当开发者直面这些数据的时候，大多数问题将迎刃而解。今天我们先分享到这里，大家如果感兴趣的话，可以查看 官网文档，官方提供了 Docker / Node 等方式的部署方案，一键部署、一劳永逸，使用起来非常简单。
有问题大家可以加入 技术支持群。
