这可能是目前最好用的 WS 调试插件 - WebSocket DevTools

前言

有点标题党了，不过写完这个 WebSocket 插件后我自己逛了一圈，确实目前全网无代餐，大家可以放心食用。而且这个 WebSocket 调试插件全程本地运行，不用担心隐私泄露。同时，不管是功能上还是体验上，这都是一个非常完整的产品，我相信会让你满意。好了好了，吹牛结束，我们开始

插件适合谁用？

开门见山，先说这个插件适合谁？适合任何需要调试 WebSocket 的开发者

为什么适合？

因为它提供了 监控、拦截、模拟、收藏 等其他 WebSocket 插件都没有的功能，基本对于之前浏览器 Network 的功能不满意的点，基本都能在这里找到答案。如果各位还有兴趣，下面我介绍核心功能和使用场景

一、官网和地址

官网地址：websocket-devtools.com
插件地址：Chrome 商店
源码地址：GitHub

（支持中文/英文，可手动切换语言）

二、核心功能详解

1. 实时监控：让 WebSocket 连接无所遁形

实际演示：

首先，我们进入任意网站并成功建立了一个 WebSocket 连接（这里我使用了 websocketking.com 的测试页面，很好用的测试网站，推荐），然后按 F12 打开 DevTools，找到 WebSocket DevTools 标签页，可以看到插件自动捕获到了这个连接，并且可以查看连接的详细信息

测试地址使用的是 wss://echo.websocket.org ，功能是回复我们发送的消息

（这里演示使用的是英文，是因为录屏实在太麻烦了，就没有重录了，抱歉。进入插件后会自动检测浏览器语言，也可以手动直接切换语言）

以前调试 WebSocket，最怕的就是“消息丢了”，在 WebSocket 建连之前忘了打开 Network 就会错过时机而看不到消息。而我们很好得解决了这个问题

功能亮点： 后台监控 即使 Network 关了也能抓包，不会因为错过时机而需要重新刷新网页（这是我自己的一个痛点 😂）

2. 流量控制：做减法，拦截上下行消息

实际演示：

打开消息拦截，比如 拦截接收 消息，那么我们给 echo.websocket.org 发送消息后，回复的下行消息被直接拦截，并且展示在了我们的消息列表里面。这个功能结合下面介绍的模拟功能，可以实现类似于对于 HTTP API 请求的代理功能。

功能亮点： 拦截上下行消息，目前市面上几乎没有类似能力的工具

3. 消息模拟：做加法，完美掌控 WebSocket 调试

“每次想测个边界条件，都得等合作方配合？不如自己造数据！”

实际演示：

点击右下角的小飞机，打开模拟控制台，然后输入消息，点击发送、接收。

模拟发送，动图中可以看到，可以看到消息被发送到了 echo.websocket.org ，并且收到回复，但是此时 拦截接收 被打开，下行消息被直接拦截。然后我关闭后，再次发送消息，Server 侧成功收到并且回复

对于模拟接收，效果同理。那么此功能打通了加法，流量控制打通了减法，那么你就完全掌控了一个 WebSocket 连接的的行为

模拟消息是不受消息拦截影响的，也就是说，模拟消息不会被拦截。这样更便于开发者调试

4. 数据解析：支持嵌套解析 JSON

有时候，格式化就是生产力

“以前看一坨嵌套 JSON，脑壳疼。现在自动高亮、折叠，终于能一眼看明白。”

实际演示：

图中可以看到，后端发送了一个嵌套的 JSON，正常的工作流是复制 String 状态的 JSON 到某个三方解析工具格式化，然后查看（当然部分开发已经锻炼出了在字符串中人肉找到所需要值的能力，值得敬佩 👀）。接着，编辑器会提示说检测到这是一个有嵌套的 JSON，可以通过点击/关闭嵌套解析按钮来切换状态。同时，编辑器也支持一键复制、收藏、以及进入模拟控制台面板去编辑发送。（后文会提到收藏）

举个例子

{
  "category": "fruits",
  "items": [
    {
      "id": "fruit_001",
      "name": "apple",
      "type": "pome",
      // 👇 这就是一个经典的嵌套 JSON，非常考验眼力 👀
      "origin": "{\"country\":\"USA\",\"regions\":[{\"name\":\"Washington\",\"climate\":\"temperate\",\"altitude\":{\"min\":500,\"max\":1500,\"unit\":\"m\"}},{\"name\":\"California\",\"climate\":\"mediterranean\"}],\"certifications\":{\"organic\":true,\"gmoFree\":true}}",
      "varieties": [
        {
          "id": "apple_var_01",
          "name": "Fuji",
          "color": "red",
          "taste": "sweet",
          "season": {
            "start": "October",
            "end": "March"
          }
        }
      ]
    }
  ]
  // ... ...
}

5. 最佳实践：专业级调试工作流

看到这里，我相信大家都知道如何使用这个插件了，但是我也多几句。

对于前端开发，比如后端部署还没有完成，我们前端可以直接拦截掉某条消息，然后在模拟控制台中编辑（比如 GIF 中，把USA的字段改为了CHINA），然后再模拟发送回来，这样就可以独立于后端进行测试。对于一些需要测试的边界条件，我们也可以在模拟控制台中编辑，然后模拟发送回来，或者发送出去

对于后端开发，同样的，也可以利用这个在产线环境，进行模拟测试，修改前端的输入来 Debug，调试刚刚部署好的后端逻辑。总之用处多多

实际演示：

6. 收藏功能：调试效率神器

那么基于上述功能，我想到或许某些很复杂的、常用的消息，可以收藏起来，然后直接发送。那么自然，我们的 收藏 功能就孕育而出。

在 收藏 功能中，每条消息都是可以被快速模拟发送、模拟接收的，且可以二次编辑，直接看演示

实际演示：

7. 系统事件：连接状态一手掌握

Network 面板没有对于 系统事件 的监控和调试，现在我们有了一个更专业的面板来展示。里面可以“模拟”掉 客户端的事件 + 服务端的事件。

在演示里面，我完成了两次 Close 操作，一次是在模拟控制台使用客户端关闭事件1000，一次是在连接实例处，点击关闭开关完成。

实际演示：

因为插件是在 JS 层进行的 中间人拦截，那么 JS 感知不到的系统事件，我们同样也无法感知。至于为什么在 JS 层拦截，是因为CDP (Chrome DevTools Protocol)这层没有暴露拦截修改的能力。具体的实现原理可以见下面的 技术原理 章节

总之，目前只有 close 1000 或者大于 3000 的自定义事件，可以被真实发送给服务端，而服务端的 error 等事件，也是通过 onError 等来触发的

8. 手动建联：原来这也是一个客户端

其实大家看到所有调试的功能也具备了，那么此时，我们只需要增加一个手动建联的功能，那么我们就可以把其当作一个 WebSocket 客户端来使用。另外已经支持了记录最近 3 次使用的 WebSocket地址，可以一键触达创建连接。

实际演示：

三、快速安装

这个其实大家都会哈，但是为了凑一个章节，还是放在这里

Chrome 商店安装

访问 Chrome Web Store （Edge也可用）
点击“添加至 Chrome”
确认安装

启用扩展

打开任意网页
按 F12 打开开发者工具
找到 WebSocket DevTools 标签页

四、技术原理

核心实现，在 JS 层做了一次中间人拦截，直接把 new WebSocket 进行了一个替换劫持，这样真实的 WS 做的任何事，只要 JS 层可以感知的，我们都可以感知到，并且转发出去。核心方向确定了，剩下就是事件在 Chrome 插件系统中不同 Context 之间的传递事件的问题了。接着，在此基础上，建构了用户友好的 UI 和功能，比起技术实现，在我这里用户友好是最重要的。

其他更多的功能，可以直接访问 GitHub

也可以直接访问 DeepWiki，里面有详细的架构实现，上面的架构图也是出自 DeepWiki