前端监控二选一：Sentry还是LogRocket？别急着站队

凌晨3点，你被报警电话吵醒。线上某个页面白屏率飙到15%，用户疯狂投诉。你打开监控后台，看到一堆堆的报错堆栈，但就是复现不了问题。这个场景，前端工程师大概率都经历过。

据2023年的一项开发者调查，超过60%的前端团队已经部署了某种形式的错误监控工具。Sentry和LogRocket是这个领域最常被比较的两个名字。但说实话，很多人选错了。

Sentry：错误追踪的瑞士军刀

Sentry的核心能力是错误追踪。它能把一个报错从客户端一路追到后端，告诉你哪行代码、哪个变量、哪个请求出了问题。它的源码映射（Source Map）处理做得相当成熟，压缩后的代码也能还原成开发时的样子。

举个例子，我用Sentry抓过一个线上bug：某个用户点击“提交订单”按钮后，页面直接崩溃。Sentry的堆栈显示是TypeError: Cannot read property 'id' of undefined，同时给出了那个时刻的上下文——用户选了一个被下架的商品，导致商品对象为空。这个信息，光靠后端日志是拿不到的。

但Sentry也有短板。它告诉你“发生了什么”，但很难告诉你“用户当时在干什么”。你看到一堆错误，但不知道用户是怎么一步步走到那个页面的。

LogRocket：用户行为的录像机

LogRocket走的是另一条路。它像一架黑匣子，记录用户的操作轨迹：鼠标移动、点击、滚动、键盘输入，甚至控制台输出。它还能回放整个用户会话，就像看录像一样。

我见过一个案例：某个团队发现Sentry上报了大量Network Error，但一直找不到原因。后来用LogRocket回放才发现，这些错误都发生在用户快速切换页面时——一个请求还没返回，用户就跳走了，浏览器自动取消了请求。这不是代码bug，而是用户操作习惯导致的现象。

LogRocket还能自动捕获控制台里的console.warn和console.error，甚至能记录Redux的状态变化。调试复杂状态问题时，这个功能特别实用。

但LogRocket的代价不小。它记录的数据量巨大，每个用户会话都在上传视频级别的信息。对隐私敏感的应用（比如金融、医疗），部署前得先过合规审查。

怎么选？看你的痛点在哪

选Sentry的场景：

• 团队主要关注“代码层面的错误”
• 需要跨前后端的全链路追踪
• 错误量很大，需要聚合和智能分类
• 预算有限，Sentry的自托管版（self-hosted）能省下SaaS费用

选LogRocket的场景：

• 错误复现困难，需要完整的用户操作上下文
• 产品体验优化（比如分析用户为什么在某个页面停留了10秒）
• 需要和内部工具（如Jira、Slack）深度集成
• 愿意为“能回放用户操作”这个能力付费

两个都用的场景：

• 团队规模较大（20人以上）
• 错误类型复杂，既有代码bug又有用户行为问题
• 预算充裕，能承受两套系统的费用

一个实用的折中方案

如果预算和精力都有限，有个折中方案：用Sentry做错误捕获，同时在前端代码里自己埋点，记录用户的关键操作（比如页面跳转、点击按钮、提交表单），把这些事件也上报到Sentry的breadcrumbs里。

这样，你既能拿到错误堆栈，又能看到用户在报错前做了什么操作。虽然比不上LogRocket的全量回放，但已经能覆盖80%的调试场景。而且，这个方案几乎零成本。

别被“全栈监控”的营销话术带偏

很多厂商喜欢宣传“一个工具解决所有问题”。但现实是，错误监控工具和用户行为分析工具，本质上是两种不同的产品。Sentry擅长“点”的追踪，LogRocket擅长“线”的回放。硬要让一个工具干另一个工具的活，结果往往是两头都不够好。

下次选型时，先问自己一个问题：我现在最痛苦的是“找不到错误原因”，还是“不知道用户怎么操作的”？答案会帮你省下不少试错成本。