用ApiCatcher替代浏览器的 Network 面板，一样的体验，但那些Network 面板看不到的请求都能看到了

调试网页接口，大家都会用 Chrome 的 F12，打开 Network 面板看请求。 但 Network 面板有几个缺点，有些请求你根本看不到，或者刚看到就没了，还找不回来。

Network 面板的几个缺点

比如你想看登录接口、提交表单这类请求，接口响应之后页面马上重定向，这条请求很快就在 Network 面板里消失了。 响应内容还没来得及看就已经看不到了，而且无法找回。

再比如调试 Chrome 插件。插件在后台发送的请求，需要在「审核弹出内容」窗口里查看。 你点一下切换个浏览器标签页，这个窗口就消失了，再次打开，刚刚那些请求也看不到了。

还有，Network 面板永远只显示当前 location 的请求，不会记录历史请求。 调试页面接口时，刷新一下就看不到之前的请求了，想回头分析只能重新再操作一遍，把请求再打出来。

ApiCatcher 抓包跟浏览器 Network 不一样

ApiCatcher 桌面端不是看当前这个浏览器标签页，而是通过系统代理抓包。 Chrome 发出去的 HTTPS 请求，只要走了系统代理，就会被抓到。 你有没有开 F12，页面有没有跳转，插件的「审核弹出内容」窗口关没关，都不影响。

所以登录跳转之后，那条 POST 请求还在抓包记录里。 插件后台发的请求也会被抓到，不需要一直开着审核窗口。 刷新页面，之前抓到的请求也不会被清掉，想回头看不用重新复现。

不过抓包记录默认是按时间排的。打开一个网页，文档、CSS、JS、图片、接口全挤在一起，想找某个站点的 XHR 其实不好找。 Chrome Network 面板好的地方是可以按 Fetch/XHR、JS、图片这些类型筛选。 抓包有历史，但一直缺少这种按网站、按资源类型查看的方式。

Browser 视图

所以我们在桌面端加了 Browser 视图，把已经抓到的流量按站点和资源类型展示。 左边是网站列表，上面可以按 Fetch/XHR、文档、JS、图片这些类型筛选，用法接近 Chrome 的 Network 面板， 但数据是抓包留下来的，不会因为页面重定向、刷新、或者关掉「审核弹出内容」窗口就丢。

打开一个网站，请求不会只打到这一个域名上。页面自己的接口是一个域名，静态资源经常放在 CDN 子域名上，再集成个 Google 分析，还会打到 googletagmanager、google-analytics 这些第三方域名。 如果按请求 URL 的 Host 来分组，同一个页面会被拆成很多个站点，你点进去只能看到其中一块。

我们分组用的不是这条请求打到了哪个 Host，而是它是哪个页面发起的。

打开页面那一次文档请求，站点就取这个页面 URL 自己的 origin，比如 https://www.example.com。 页面里再发出去的 JS、CSS、图片、Fetch/XHR，浏览器一般会带 Origin 或 Referer。我们优先看 Origin 头，没有再看 Referer，把它们归到这个页面所在的站点。 所以 Google 分析的上报、CDN 子域名上的静态资源，只要是这个页面加载的，都会出现在同一个站点下面，而不是各自占一行。

有些请求既没有 Origin 也没有 Referer，我们就没法判断它属于哪个网站，不会硬塞进某个站点里。Chrome 插件走的是 chrome-extension:// 这种 Origin，会单独归到插件。

Browser 视图只能看到浏览器发的请求，App 发的请求不会出现在这里，还是去请求历史里看。 也不限于 PC 上抓到的。HAR 导入的浏览器请求，或者 iOS、Android 设备实时同步过来的浏览器请求，一样能在 Browser 视图里看。

抓包走的是系统代理，Chrome 和 App 的流量会进同一条记录，要按网站摊开，得先把浏览器的请求挑出来。 现代浏览器发请求会带 Sec-Fetch-Dest、Sec-Fetch-Mode、Sec-Fetch-Site，或者 Sec-CH-UA 这类头，有这些我们就当它是浏览器。 Chrome 插件的 Origin、Referer 是 chrome-extension:// 开头，也算浏览器，归到插件。 没有这些头，再看 User-Agent，带 Mozilla 并且是 Chrome、Firefox、Safari、Edge 这类，才当浏览器。 okhttp、curl、Java、Python 这些客户端的 UA 直接排除掉，不进 Browser 视图。

Chrome Network 面板里看不到、或者一闪就没了的那些请求，在 Browser 视图里都能看到。