打开浏览器，按下F12，切到Network面板，刷新页面——你看到的那些密密麻麻的请求记录，就是Web雷达最朴素的样子。它不发射电磁波，不转天线，但它干的事和军舰上那套系统差不多：持续扫描，捕捉信号，判断哪些是朋友，哪些是威胁。

我第一次意识到这件事，是在排查一个线上事故的时候。用户反馈页面加载慢，后端日志干干净净，服务器CPU也正常。后来在Network面板里盯了五分钟，发现一个第三方统计脚本的请求卡在pending状态，整整12秒才超时。页面渲染被它堵住了。这玩意儿平时就几十毫秒，那天对方的CDN节点出了故障。如果没有Web雷达——也就是浏览器开发者工具加上一些监控手段——你根本不知道问题出在哪一层。

雷达屏幕上有什么

Chrome DevTools的Network面板会列出每一个请求：URL、状态码、类型、大小、耗时。看起来平平无奇，但信息密度极高。一个正常的页面加载，请求数在50到150之间。电商网站可能超过300个。每个请求都有自己的生命周期——DNS查询、TCP握手、TLS协商、发送请求、等待响应、接收数据。Waterfall视图把这些阶段画成彩色条，哪一步慢了一眼就能看出来。

我习惯按耗时排序。排在最前面的那几个，要么是接口本身慢，要么是被浏览器排队了。后者更隐蔽。HTTP/1.1下同域名并发连接数有限制，Chrome大概是6个。第7个请求就得等。你看到某个JS文件加载花了3秒，点进去一看，排队等了2.8秒，实际传输200毫秒。问题不在这个文件本身，而在它前面堵了一堆东西。

不止是看，还得盯

手动打开DevTools看请求，那是事后排查。真正的雷达得持续运行。Sentry、Datadog RUM、自建的埋点脚本，这些工具做的事情就是：在真实用户的浏览器里监听请求，把异常上报到服务端。某个接口的P99耗时突然从200毫秒飙到5秒，你比用户先知道。

我搭过一套简易版。用PerformanceObserver监听resource类型的entry，过滤掉耗时超过3秒的请求，带上页面URL和用户UA发到日志接口。代码不到30行，但抓到了好几次CDN局部故障。有意思的是，有些请求超时并不是网络问题——是某个广告脚本在用户浏览器里跑了个死循环，把主线程堵死了，后续请求全被卡住。这种问题后端监控永远看不到。

干扰和误报

Web雷达有个麻烦：杂波太多。浏览器扩展会注入请求，运营商会劫持页面插入广告脚本，用户自己装的油猴插件也在发请求。你看到某个陌生域名在加载资源，不一定是被攻击了，可能只是用户装了某个比价插件。判断信号还是噪声，得靠经验。

另一个坑是缓存。请求显示200 OK，但实际走的是disk cache，耗时0毫秒。你以为资源加载了，其实用的是本地副本。用户那边缓存过期后重新拉取，可能就是一个全新的、你没测试过的版本。所以看Network面板的时候，记得勾上Disable cache，不然你看到的是一张美化过的雷达图。

这东西说到底就是一个观察窗口。浏览器把网络层的事情摊开给你看，但怎么看、看出什么，取决于你对整个系统的理解。工具本身不复杂，复杂的是它背后那套HTTP协议、缓存策略、并发模型、安全策略交织在一起的运行逻辑。雷达屏幕上每一个光点，都是一次真实的网络对话。