Network抓包调试技巧与常见问题解决方法分享

项目初期的技术选型

这次的项目是个移动端H5页面，主要功能是展示商品列表并支持下单。听起来挺简单，但需求里有一条让我头疼：需要在用户浏览商品时实时上报数据到服务器，包括用户的点击、滑动等行为。

刚开始我也没多想，觉得直接用 fetch 或者 axios 发请求不就行了吗？结果在测试环境跑起来才发现问题：网络状况不稳定的时候，接口请求会超时甚至失败，而这些数据对业务分析又特别重要，丢不得。

后来和后端同事聊了聊，他建议我用抓包工具先摸清网络请求的情况，再优化代码逻辑。于是我开始研究 Network 抓包，没想到这一研究还真踩了不少坑。

核心代码就这几行

Network 抓包其实没那么复杂，主要是借助浏览器自带的开发者工具或者第三方工具比如 Charles 和 Fiddler。不过在这之前，我先把关键的代码写好：

const API_URL = 'https://jztheme.com/api/log';

function sendData(data) {
  navigator.sendBeacon(API_URL, JSON.stringify(data));
}

document.addEventListener('click', (event) => {
  const target = event.target;
  const logData = {
    eventType: 'click',
    targetId: target.id,
    timestamp: Date.now(),
  };
  sendData(logData);
});

document.addEventListener('scroll', () => {
  const logData = {
    eventType: 'scroll',
    scrollY: window.scrollY,
    timestamp: Date.now(),
  };
  sendData(logData);
});

这里用了 navigator.sendBeacon 方法，主要是因为它适合用来发送小量的数据，并且不会阻塞页面卸载过程，比普通的 AJAX 请求更可靠。

代码看起来挺简单的吧？但实际运行的时候，我发现了不少问题。

最大的坑：性能问题

一开始我以为只要把事件监听加上，数据就能顺利发出去。但很快我就发现不对劲：在低端机型上，页面卡得不行！尤其是当用户疯狂滑动页面时，scroll 事件触发频率太高，导致 sendBeacon 被调用得过于频繁。

后来我查了一下资料，发现 scroll 事件确实是个大坑，它的触发频率非常高，基本上每帧都会触发一次。如果每次触发都发请求，别说低端机了，高端机也会吃不消。

解决办法是加个防抖或者节流。我最终选择了节流，因为防抖会导致最后一次操作的数据丢失，而节流可以保证每隔一段时间至少发一次数据：

function throttle(fn, delay) {

  let lastCall = 0;

  return function(...args) {

    const now = new Date().getTime();

    if (now - lastCall >= delay) {

      lastCall = now;

      fn.apply(this, args);

    }

  };

}

const throttledSendData = throttle(sendData, 1000);
document.addEventListener('scroll', () => {

  const logData = {

    eventType: 'scroll',

    scrollY: window.scrollY,

    timestamp: Date.now(),

  };

  throttledSendData(logData);

});

`>

<p>这样改完之后，性能问题确实缓解了不少，但还是有个小问题：如果用户快速滑动然后迅速关闭页面，可能会有最后一段数据没来得及发送。这个问题暂时没找到完美的解法，不过考虑到影响不大，我也就没继续深究了。</p>

<h2>意外的收获：抓包工具真的好用</h2>

<p>说回 Network 抓包，我一开始用的是 Chrome 自带的开发者工具。打开方式很简单：<strong>按 F12 -> 切换到 Network 面板 -> 刷新页面</strong>，所有的网络请求都会显示出来。</p>

<p>但我很快就发现了它的局限性：只能抓当前页面的请求，没法模拟弱网环境。后来我试了下 Charles，发现它功能强大得多：</p>

<ul>

  <li>可以抓 HTTPS 请求（需要安装证书）</li>

  <li>支持设置弱网模式，比如 2G/3G 网络</li>

  <li>还能修改请求和响应内容，方便调试</li>

</ul>

&lt;p&gt;举个例子，我在测试 &lt;code&gt;sendBeacon&lt;/code&gt; 的时候，发现有些请求在弱网环境下会失败。通过 Charles 模拟弱网，我验证了这一点，并调整了代码逻辑，在请求失败时尝试重发：&lt;/p&gt;</code></pre>javascript

function sendDataWithRetry(data, retries = 3) {

  const success = navigator.sendBeacon(API_URL, JSON.stringify(data));

  if (!success && retries > 0) {

    setTimeout(() => sendDataWithRetry(data, retries - 1), 1000);

  }

}

``
这个改动虽然增加了复杂度，但大大提高了数据上报的成功率。
回顾与反思
总的来说，这个项目让我对 Network 抓包有了更深的理解。以前总觉得抓包是后端或者测试工程师的事，现在才发现前端也能从中受益不少。
做得比较好的地方：

用了 sendBeacon 提高数据上报的可靠性
通过节流解决了性能问题
借助 Charles 模拟弱网，提前发现问题

还可以优化的地方：

最后那段未发送的数据问题还没完全解决
代码里硬编码了一些配置，比如节流时间，可以考虑抽成可配置项

以上是我个人对这个 Network 抓包的完整讲解，有更优的实现方式欢迎评论区交流。这个技巧的拓展用法还有很多，后续我会继续分享这类博客。