想象一下这样的场景：你刚刚结束了一个漫长的迭代周期，代码上线，你合上电脑，心满意足地准备享受一个轻松的周末。然而几个小时后社交媒体上开始出现零星的抱怨，紧接着客服

为什么会出现这种“你在明，Bug在暗”的尴尬局面？因为缺乏一套完善的前端监控系统。这就好比你开了一家无人超市，却只在收银台装了个摄像头，至于货架是否倒塌、冷柜是否制冷、顾客是否找不到商品，你一无所知。我们需要给网站装上一个“黑匣子”，无论发生什么douNeng把现场数据传回大本营。今天我们就来手把手搭建一套虽然简易，但五脏俱全的前端监控体系，让你对线上状态了如指掌。

一、 错误捕获：别让异常悄无声息地溜走

错误是监控系统的第一道防线。我们不仅要捕获错误，还要知道错误发生在哪里是谁遇到了错误。传统的try-catch虽然有用，但在复杂的异步流和庞大的代码库面前，往往捉襟见肘。我们需要geng全局、geng自动化的捕获机制。

1. 全局JavaScript运行时错误

这是Zui基础的兜底方案。当JS引擎执行代码时抛出异常，window.onerror就是那个接盘侠。它Neng捕获大部分同步错误以及部分异步错误。我们需要Zuo的，就是把错误信息、堆栈、甚至用户的浏览器型号打包发送。

window.onerror = function {
  // 构建上报数据包，越详细越好
  const report = {
    type: 'jsError',
    message: message,       // 错误信息
    stack: error?.stack,    // 堆栈信息，定位问题的关键
    file: source,           // 哪个文件出错了
    line: lineno,           // 哪一行
    col: colno,             // 哪一列
    userAgent: navigator.userAgent, // 用户环境
    url: location.href      // 当前页面
  };
  sendReport; // 发送到你的监控服务器
  return true; // 返回trueKe以阻止控制台继续抛出默认错误，显得geng专业
};

2. Promise未捕获的拒绝

现代前端开发离不开Promise，但那些没有写.catch的Promise，一旦reject，就像断了线的风筝，window.onerror是抓不住它们的。这时候，unhandledrejection事件就派上用场了。它专门用来处理那些被遗忘的异步错误。

window.addEventListener => {
  const report = {
    type: 'promiseError',
    reason: event.reason,   // 拒绝原因
    stack: event.reason?.stack // 尝试获取堆栈
  };
  sendReport;
});

3. 资源加载失败：图片、脚本去哪了？

有时候JS没报错，但页面一片空白，或者图片显示为“裂开”的图标。这通常是资源加载失败导致的。我们需要监听error事件，但要区分是JS执行错误还是资源加载错误。一个简单的技巧是判断event.target是否为window。

window.addEventListener => {
  // Ru果target不是window，说明是元素加载出错
  if  {
    const report = {
      type: 'resourceError',
      tagName: event.target.tagName,
      src: event.target.src || event.target.href // 记录下失败的资源地址
    };
    sendReport;
  }
}, true); // 必须在捕获阶段触发，否则可Neng漏掉

4. 框架级别的错误：Vue与React的守护

组件化的代码结构使得全局监听有时力不从心。框架提供了生命周期钩子来处理组件内部的错误。

对于Vue开发者，Vue.config.errorHandler是必填项：

// Vue
Vue.config.errorHandler =  => {
  sendReport({ 
    type: 'vueError', 
    err: err, 
    info: info // Vue特定的错误信息，比如哪个生命周期钩子
  });
};

对于React开发者，ErrorBoundary组件则是标准答案：

// React
class ErrorBoundary extends React.Component {
  componentDidCatch {
    sendReport;
  }
  render { return this.props.children; }
}

5. 接口请求错误：后端在说什么？

前端报错可Neng是后端的问题。接口返回500、404，或者超时用户kan到的是“数据加载失败”。通过拦截器，我们Ke以统一捕获这些异常。

// 以axios为例
axios.interceptors.response.use(
  response => response,
  error => {
    sendReport({
      type: 'apiError',
      url: error.config.url,     // 请求的URL
      status: error.response?.status, // 状态码
      message: error.message     // 错误描述
    });
    return Promise.reject;
  }
);

二、 性Neng监控：谁拖慢了我们的页面？

仅仅“不报错”是不够的。Ru果一个页面需要5秒钟才Neng显示内容，用户虽然没有kan到报错，但心里Yi经把你拉黑了。性Neng监控的核心是量化用户的等待体验。

1. Google推荐的黄金指标：Web Vitals

Google提出了三个核心指标，用来衡量用户体验的“健康度”。我们Ke以利用web-vitals库轻松获取这些数据。

LCP : Zui大内容绘制。页面主要内容什么时候出现？这决定了用户觉得页面“加载快不快”。

FID : 首次输入延迟。用户第一次点击到页面响应的时间。这决定了页面“卡不卡”。

CLS : 累积布局偏移。页面元素是否发生了意外的跳动？这决定了页面“稳不稳”。

import {getLCP, getFID, getCLS} from 'web-vitals';
// 监听LCP
getLCP(metric => sendReport({
  type: 'webVital', 
  name: 'LCP', 
  value: metric.value,
  id: metric.id // 用于关联其他指标
}));
// 同理监听 FID 和 CLS
getFID);
getCLS);

2. 细粒度的网络耗时：Navigation Timing API

除了Web Vitals，我们还需要知道网络层面的细节。DNS解析花了多久？TCP连接花了多久？首字节时间是多少？performance.timing对象提供了详尽的时间戳。

window.addEventListener => {
  const timing = performance.timing;
  const report = {
    type: 'performance',
    dns: timing.domainLookupEnd - timing.domainLookupStart, // DNS解析耗时
    tcp: timing.connectEnd - timing.connectStart,           // TCP连接耗时
    ttfb: timing.responseStart - timing.requestStart,        // 首字节时间
    domReady: timing.domContentLoadedEventEnd - timing.navigationStart, // DOM准备时间
    load: timing.loadEventEnd - timing.navigationStart      // 完整加载时间
  };
  sendReport;
});

3. 首屏时间的自定义计算

有时候标准指标并不Neng完全反映业务真实情况。比如我们只关心“商品列表”什么时候出来。这时候Ke以用MutationObserver来监听DOM变化，结合性Neng时间戳，计算关键元素出现的时间。

三、 用户行为监控：还原案发现场

知道了报错，知道了慢，但还缺一环：用户到底Zuo了什么才导致报错的？还原用户操作路径是复现Bug的关键。

1. 点击流：他到底点了哪里？

全局监听点击事件kan似简单，但Ru果处理不好，会产生海量数据。我们需要提取关键信息，比如标签名、文本内容、类名等，同时要注意隐私保护，不要上报敏感信息。

document.addEventListener => {
  const target = e.target;
  const report = {
    type: 'click',
    tag: target.tagName,
    // 只截取前10个字符，避免文本过长
    text: target.innerText?.slice, 
    className: target.className,
    id: target.id,
    x: e.clientX, // 记录点击坐标，辅助判断
    y: e.clientY
  };
  sendReport;
});

特别提示： 点击事件非常频繁，务必Zuo好防抖和采样。比如只上报10%的点击，或者设置上报频率上限，否则你的服务器会被日志冲垮。

2. 路由变化：SPA的轨迹

在单页应用中，页面不会刷新，URL的变化是用户浏览路径的唯一线索。我们需要监听路由变化。对于Hash模式，监听hashchange即可；对于History模式，情况稍微复杂一点。

// 拦截 pushState 和 replaceState
const originalPushState = history.pushState;
const originalReplaceState = history.replaceState;
history.pushState = function {
  originalPushState.apply;
  sendReport;
};
history.replaceState = function {
  originalReplaceState.apply;
  sendReport;
};
// 监听 popstate 事件
window.addEventListener => {
  sendReport;
});

四、 ：从“救火”到“预防”

前端监控不仅仅是一堆代码的堆砌，它是一种产品思维的体现。它让我们从被动地等待用户投诉，转变为主动发现并解决问题。通过记录错误、性Neng指标和用户行为，我们实际上是在构建一个数字世界的“全知视角”。

当然搭建监控系统只是第一步。如何处理海量数据、如何设置报警阈值、如何根据数据反哺代码优化，那是geng广阔的天地。但至少现在当用户再遇到问题时你不再是那个“浑然不觉”的开发者，而是手握真相、胸有成竹的问题解决者。别让你的Bug在黑暗中滋生，把它们暴露在监控的阳光下吧。

---