“

前言
我是个在前端摸爬滚打十多年的“老油条”，码过各种埋点 SDK，也被自己写的监控埋坑埋到差点翻车。想在这篇文章里跟大家聊聊——到底怎么才能把前端监控方案做得不只是“跑通”那么简单，而是真正能帮我们及时发现问题、减少线上折腾。

那些年，我和监控的“对抗”

还记得有次上线新版本，A/B 流量实验突然跳出一堆白屏用户。监控埋点只报了一个接口超时，定位到具体场景却毫无头绪。后来翻了半天日志，才挖出是同一个接口在某个老旧安卓机型上被网络劫持，返回了 302 重定向。我当时心里苦：

“

“埋点 SDK 把接口错误都归到 XHR fail，根本没记录下真实状态码。”

从那之后，我就立志——前端监控，不能只盯一个指标，要越细越好。

一、不只是埋一个错误上报

有人说：埋个 window.onerror、addEventListener('unhandledrejection') 就够了。结果是：

• 前端崩溃了，监控也崩了。有一次 SDK 自己抛异常，结果上报通道被堵死，后续所有错误都被吞。
• 只知道出错，不知道为什么出错。A 错不用调，B 错一堆人盯着，最后发现是同一个 C 错在不同页面重复触发。

后端同学爱加链路追踪 ID？前端也应该给每个用户会话打个唯一标志。这样你既能串起一连串操作，也能把接口、路由、点击等多条数据汇总到一个请求链。

二、盛情难却的性能指标

有一次产品经理想看“页面可交互时间（TTI）”，让我埋 performance.timing。我直接翻了个白眼：

“

“你要的是 TTI，但浏览器指标里只有 FCP、LCP、DOMContentLoaded……”

最后搞了一个“手动 TTI”，在关键脚本都加载完后，放一个 window.__tti = Date.now()，再加埋点上报。结果发现，React 组件挂载后用户其实还要等待第三方广告脚本插入 DOM，才算“可用了”。
经验：性能监控要贴近真实业务场景，不能盯着指标打转，要从用户感知出发。

三、埋点形式千千万，哪种最靠谱？

我刷面试的时候，HR 问我“打点方式哪种好？”我答得支吾其词——到底是手写 fetch('/log', ...)，还是用第三方 SDK？

• 手写优点：灵活，可控；缺点：业务代码里到处是埋点调用，容易忘。
• SDK 优点：一行初始化搞定；缺点：黑盒感太强，排查问题要翻 SDK 源码。

后来我在项目里折中：

1. 核心模块（登录、支付、重要表单）用手写埋点，顺便加上自定义属性（页面状态、网络类型、机型信息）
2. 其他模块用轻量级 SDK，定期开会统一校验事件和字段命名，避免失控。

这样既保证了关键路径的可追溯性，又不至于让业务同学天天被埋点折磨。

四、埋坑现场：几个真实案例

“

案例 A：埋点“掉链”导致统计失真
一次大促，PV 数据突然暴跌。原来新版去掉了旧版的 onhashchange 事件监听，忘记埋替代的路由监控。
教训：切换路由方案时，一定要梳理所有历史 hook，并配合灰度发布验证。

“

案例 B：错误上报泛滥，报警像吵闹的蚊子
某天凌晨，报警系统炸了：网络抖动导致 SDK 上传失败进入无限重试，结果上万条错误堆积。
解决：给失败上报加上“重试上限”和“去重窗口”（比如同一错误 5 分钟内只报一次），报警瞬间安静。

“

案例 C：性能监控没覆盖到第三方脚本
产品想看“整体页面渲染耗时”，结果埋点只盯了自家 JS。真正拖慢页面的，是广告脚本和推荐组件。
方法：用 MutationObserver 检测关键 DOM 变化时机，埋点埋在广告容器插入完成，拿到完整链路数据。

五、我总结的“前端监控三板斧”

1. “链”要打通：从用户点击到接口响应，再到 DOM 更新，每一步都要打上上下文 ID，方便串事件。
2. 落地度要高：埋点太细未必好，先把核心场景、关键路径、异常分等级；基础指标全埋，高级指标逐步补。
3. 自我演练：每次大版本发布前，模拟失败场景（接口 500、网络慢、电量低、缓存失效），看监控告警是否靠谱。

讲完这些，想到最近一位同学在群里问：“前端监控到底该花多少精力？”我的回答是：

“

能救命的监控，一点点埋；能省事的监控，一步到位；其余的，等到真卡了再补。

监控不是压力山大，也不是装逼利器。把它当成日常的“安全带”和“导航”，关键时刻它能救你一命。不知道你们还碰到过什么奇葩监控场景？评论区聊起来~😉