Dreamer寻做了几年接口调试和前端性能优化，我一直对“抓包”这件事又爱又恨。项目前期排查一个线上问题，往往需要在抓包工具和浏览器之间来回切换，配置各种转发规则、信任证书、重启服务，好不容易抓到几个请求，又因为连接断掉得重新来。后来我干脆写了一个开源浏览器插件，核心就两件事：第一，在浏览器里直接完成全栈抓包，不用折腾一堆转发链路；第二，把抓到的请求交给 AI 做自动审计，从海量请求里快速标出可疑点。
这个项目上线后，基本成了我每天开发调试的标配。这里把这套插件从选型到实现、从安装到踩坑的完整过程整理出来，希望能帮到正在做接口调试、性能分析、前端安全排查的同学。
1. 这是做什么的：为什么你需要一个“边抓边审”的浏览器插件
1.1 传统抓包方式的痛点
不少情况下，抓包工具能拿到的信息其实是不完整的。传统桌面抓包工具大多采用中间人转发模式，需要在操作系统、浏览器、甚至手机端分别配置网络出口，还要安装并信任根证书。这套流程用起来最难受的有几个地方：第一，改完后浏览器可能提示证书不受信，个别页面直接访问失败；第二，很多工具默认只处理走转发链路的流量，像 WebSocket 升级、Service Worker 发起的请求、某些后台预取的请求，经常漏得一干二净；第三，在工作电脑上可能没有管理员权限，证书装不上、端口被占满，整个过程彻底卡死。
我还遇到过更头疼的场景：抓包工具刚连上不久，页面里某个长连接就断了。排查了很久才发现，不是工具本身的问题，而是浏览器和服务端都做了连接复用，某些加密握手逻辑在转发链路下校验不通过，于是一段时间后连接被服务端主动断开。这就是为什么很多人会说“抓个包，怎么老掉线”。
而在浏览器插件方案里，这些麻烦基本不存在。插件通过浏览器调试协议直接读取页面网络栈真实产生的事件，不需要改证书，不需要开独立本地服务，也不干预正常连接，因此抓到的数据就是页面实际收发的数据，不用再担心“转发模式下数据和真实场景不一致”的问题。
1.2 AI审计能补上哪一块
抓包本身只是手段，真正难的是从大量请求里发现异常。比如前端调用某个接口时，响应里出现了明文手机号、身份证号；某个内部管理接口在线上环境任何人都能访问；某个静态资源里嵌入了一段看起来像密钥的字符串。这些信息混在成百上千条请求里，人眼扫一遍非常容易漏。
于是我在这款插件里加了一个 AI 审计层。用户选中刚才抓到的请求，点一下“发送到 AI 审计”，插件会把请求的 URL、方法、关键请求头、业务参数以及响应片段汇总起来，调用配置好的大模型接口进行风险识别。AI 能做的事情主要有三类：第一，自动判断当前请求有没有携带敏感标识、令牌是否过期或缺失；第二，从接口返回内容里查找手机号、身份证、密钥等敏感模式，并给出风险等级；第三，结合请求频率、响应大小、Cookie 属性等上下文信息，推断是否存在未鉴权访问、不合理暴露、调试开关遗留等隐患。
说到底，抓包工具解决的是“数据怎么拿到”的问题，AI 审计解决的是“拿到之后该怎么看”的问题。把这两个能力塞进一个浏览器插件里，日常调试效率能高不少。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 插件整体架构：从选型到数据模型
2.1 为什么用 chrome.debugger API 而不是 webRequest
插件要拦截并查看真实响应体，早期最容易想到的是 webRequest API。但实际操作后会发现，在 MV3 版本里 webRequest 默认只能观察到请求的开始和结束，不能直接读取响应体内容；即使配合 declarativeNetRequest 做动态规则，也很难拿到完整的响应数据。
我最终选择了 chrome.debugger API。它底层走的是 Chrome DevTools Protocol，也就是浏览器开发者工具使用的同一套调试协议。使用 chrome.debugger 附加到一个标签页后，可以监听 Network 域里的各种事件，包括请求发送、响应头返回、加载完成，还能主动调用 Network.getResponseBody 获取响应体的完整内容。
这里要注意一个代价：使用 chrome.debugger 时，浏览器顶部会弹出一条“扩展程序正在调试此浏览器”的提示，而且同一个标签页在同一时间只能有一个调试客户端。如果你同时打开了开发者工具，或者另一个抓包扩展正在运行，就可能会冲突。不过对大多数开发调试场景来说，这个提示完全能接受，换来的是精准、完整的数据通道。
2.2 插件内部模块划分
我一开始想着把抓包逻辑直接写在 popup 页面里，省事，后来发现不行。popup 一旦关