线上页面突然变卡你怎么排查

一句话先定性

我不会一上来就改代码，而会先判断是全局问题、局部问题，还是偶发问题，再用指标和工具把“感觉卡”变成“知道卡在哪”。

---

30 秒版本

如果线上页面突然变卡，我一般会先做三步。第一，确认范围，是某个页面、某类用户还是全站都卡。第二，看监控数据和最近发布，先判断是资源、接口、主线程还是布局问题。第三，再用 Performance、日志和录屏去还原现场。对我来说，排查核心不是一开始猜答案，而是先缩小范围，再决定从 LCP、INP、CLS 还是接口链路下手。

1 分钟版本

我排查线上卡顿时，一般会先问三个问题。第一，是不是最近刚发版；第二，是不是所有用户都这样，还是特定页面、特定设备、特定网络更明显；第三，是“加载慢”“操作卡”还是“页面抖”。这三个问题一分，后面的排查方向就清楚很多。

如果偏加载慢，我会优先看 TTFB、FCP、LCP 和接口耗时；如果偏交互卡，我会优先看 INP、主线程长任务和 React 重渲染；如果是页面抖，我会看 CLS、图片尺寸预留和异步内容插入。

然后我会结合最近发布记录、监控平台、浏览器 Performance、React Profiler、网络面板和必要的录屏去复现和定位。我的目标不是马上给结论，而是先把问题从“页面变卡了”收敛成“是资源问题、渲染问题、还是数据量放大导致的问题”。

2 到 3 分钟版本

如果线上页面突然变卡，我一般会把排查分成四步。第一步先判断影响范围，第二步再判断问题类型，第三步定位具体瓶颈，第四步再决定止血和根因修复方案。

第一步是范围判断。我会先看是不是最近发版后出现的，是单页面还是全站，是特定设备还是所有用户，是高数据量场景才会触发还是一进页面就有问题。因为这一步会直接决定你后面优先查前端、后端还是资源。

第二步是问题分类。我通常分成三类：加载慢、交互卡、页面抖。加载慢更多看 TTFB、FCP、LCP、接口耗时和资源加载；交互卡更多看 INP、长任务、重复渲染和同步阻塞；页面抖更多看 CLS、尺寸预留和异步内容插入。先分好类，排查会比一上来全查高效得多。

第三步才是工具定位。如果怀疑是加载问题，我会先看网络面板、资源瀑布图、接口耗时、包体积和缓存命中；如果怀疑是交互问题，我会开浏览器 Performance 看主线程时间花在哪，再配合 React Profiler 看是不是某次状态更新带出了大面积重渲染；如果怀疑是布局问题，我会重点看图片、广告位、异步模块和骨架屏的占位策略。

第四步是处理策略。我通常会分成“先止血”和“再治理”。比如最近发版引入了明显卡顿，必要时先回滚；如果是某个大计算导致输入卡顿，可以先降级功能或延后计算；如果是大列表问题，可以先上虚拟列表或减少首屏渲染量。等影响控制住之后，再去做根因修复，比如拆状态边界、做资源治理、补监控指标或者优化接口链路。

所以如果让我总结，我会说线上卡顿排查最怕的不是问题难，而是没有顺序。我的习惯一定是先判断范围，再判断类型，再用工具定位，最后区分止血和根因治理。这样回答会比较像真正处理过线上问题，而不是只会背性能术语。

如果面试官追问“你第一反应先看什么”

我第一反应通常是先看最近有没有发版，再看监控平台里 LCP、INP、CLS 和接口耗时有没有明显波动。因为这是最快把问题从“主观感受”变成“可观测现象”的方式。

如果面试官追问“怎么区分是前端问题还是后端问题”

我一般会先看 TTFB 和接口耗时。如果首包和接口明显慢，那更偏后端或网络；如果接口正常但主线程长任务很重、React 重渲染很多，那更偏前端。很多时候不是纯前端或纯后端，而是两边叠加，所以我会先找哪一边最明显。

如果面试官追问“如果暂时复现不了怎么办”

那我会尽量依赖线上监控、日志、录屏和用户环境信息去还原现场，比如设备型号、网络条件、数据量、页面路径和操作链路。复现不了不代表没法排查，关键是先把上下文收齐。

最后一句收尾

所以线上页面突然变卡，我不会先猜代码哪儿有问题，而是先把范围、类型和瓶颈拆清楚，再决定是回滚、止血还是根因治理。这样才像真实线上排查，而不是拍脑袋修 bug。