主线程被榨干？前端页面卡成PPT的真相与优化实战

先说结论：你做的页面之所以滑动起来像PPT，多半不是电脑太差，也不是网速太慢，而是主线程被榨干了。

作为前端，我们花了大量时间在组件化、工程化、微前端甚至Agent化这些新鲜概念上，反而最容易忽略一个最底层、最基础、也最致命的东西——浏览器的主线程。你写的每一行JavaScript、每一次DOM操作、每一帧动画、每一次事件绑定，最终都要在主线程上排队执行。主线程一旦阻塞，页面就是卡顿、掉帧、白屏、点击无响应，用户不会去查你的代码，只会默默关掉页面。

这篇文章不是讲八股文，而是结合实战，把主线程这件事掰开揉碎讲清楚：它到底在忙什么、为什么你的页面会卡成PPT、用哪些工具能一眼定位问题、以及针对2026年前端技术栈下的处理方案。看完你就能明白，很多时候前端性能差的根源，根本不在框架，也不在打包工具，而在主线程上那些被你忽略的“隐形杀手”。

1. 主线程到底在忙什么：一个页面的一生

1.1 浏览器主线程的职责与运行机制

主线程就是浏览器用来执行JavaScript、解析样式、计算布局、绘制页面的那条核心线程。你在页面上看到的一切、点到的一切、滚动时感受到的一切，几乎都跟主线程有关。

可以把它理解成一家餐厅里唯一的厨师：点单（事件触发）、备菜（网络请求后的数据处理）、炒菜（JavaScript逻辑执行）、摆盘（样式布局与绘制）、上菜（合成显示）全在这一条流水线上完成。一旦某个环节堵住了，后面的所有菜都得等着，顾客感受到的就是上菜慢、甚至厨房瘫痪。

具体来说，主线程主要干四件事：

• 执行JavaScript代码（包括框架运行时、业务逻辑、事件回调、定时器）
• 解析HTML和CSS，构建DOM树和CSSOM树
• 计算样式和布局（Layout），确定每个元素的几何位置
• 绘制（Paint）和合成（Composite），把页面变成像素显示在屏幕上

这四个环节是串行的，任何一个环节耗时过长，都会阻塞后面的环节。2026年了，浏览器的架构越来越复杂，多进程、GPU加速、合成器线程都已经很成熟，但核心问题没变：所有JavaScript仍然跑在主线程上，而JavaScript执行会直接阻塞渲染。

1.2 卡成PPT的根源：任务队列与事件循环

说一下事件循环。很多人面试时背过“微任务宏任务”、“事件循环机制”，但真正理解它对卡顿影响的人不多。

主线程是单线程的，同一时间只能干一件事。浏览器维护一个任务队列，然后主线程不断从队列里取出任务执行。这个机制本身没问题，问题出在：一个任务如果执行时间过长，就会阻塞后续所有任务的执行。

这里的关键指标叫长任务。浏览器性能规范把超过50毫秒的任务定义为长任务。为什么是50毫秒？因为在1000毫秒内有250毫秒可以自由支配，以每秒60帧计算，每帧约16.67毫秒，但浏览器还留了余量——一个长任务超过50毫秒，就意味着至少三帧动画被卡住。用户能明显感知到：“哎，这个页面卡了一下。”

实际开发中，你遇到的场景可能是这样的：某个数据列表渲染了上万条数据，React在 Reconciliation 阶段递归遍历虚拟DOM，这一跑就是两三百毫秒；然后强制同步布局又来一下，又是几十毫秒；接着某个第三方SDK初始化再来一个一百多毫秒的任务。主线程被这些任务轮番轰炸，页面能不卡吗。

1.3 首屏性能外的隐性成本

现在的性能监控体系，比如LCP（最大内容绘制）、FID（首次输入延迟）、INP（交互到下一次绘制），本质上全都在围绕主线程做文章。

尤其要注意INP（Interaction to Next Paint），这是2024年谷歌把FID替换掉后的指标，也是2026年Core Web Vitals里最受关注的指标之一。INP测量的就是用户从点击、敲击键盘到页面产生视觉反馈之间的时间。说白了，它量化的就是主线程处理交互事件的响应能力。

很多前端团队把LCP优化到了1秒以内，但INP还是很糟糕。为什么？因为首屏加载优化了很多内容，可是交互事件被放在主线程上处理时，主线程已经被一堆懒加载的脚本、埋点上报、数据轮询塞满了。用户点了一个按钮，事件回调排在长任务后面，等前面的活干完才能执行，视觉反馈自然就慢了。

2. 主线程被占用的常见元凶：为什么你会踩坑

2.1 大数组渲染与虚拟DOM的计算风暴

我看了太多线上项目的代码，最常见的问题就出在列表渲染上。一个表格直接渲染5000行数据，每行还有复杂的嵌套结构和各种事件绑定。React要维护这5000行组件的虚拟DOM树，每次更新时还需要diff对比，这是纯JavaScript计算，全部发生在主线程上。

你可能觉得“5000行也不多啊”，但问题在于这5000行组件背后还有样式计算和布局。一次数据更新触发setState，React重新渲染整个列表，diff算法递归遍历，然后浏览器还得重新计算样式、重新布局。三步叠加，轻轻松松突破200毫秒。

更恶心的是强制同步布局（Forced Synchronous Layout），读一下offsetHeight、offsetWidth、getBoundingClientRect，然后马上改样式，浏览器不得不放弃异步批量布局策略，立刻同步执行布局计算。这个在滚动加载、动画过渡的场景里特别容易踩中。比如你写了个滚动加载更多的效果，在scroll事件里读了scrollTop又动态改了某些元素的height，每次滚动都是一次强制同步布局，页面直接卡到头秃。

2.2 巨型JavaScript包与第三方脚本

2026年了，前端构建工具已经很强大，但仍有大量项目在犯同一个错误：把整个依赖库打进主包。一个包含了完整Ant Design组件库、ECharts、Moment.js（现在应该换成Day.js了）、Axios的大包，压缩后可能轻松超过2MB。浏览器下载这些代码倒还好，关键是解析和执行。

JavaScript解析是CPU密集型操作，这段代码的主线程占用时长不是按毫秒算的，而是按几百毫秒甚至秒来算的。移动端设备上尤其明显，同样一段代码，桌面端解析只要200毫秒，低端安卓手机上可能要600毫秒甚至更多。

第三方脚本更是主线程黑洞。你为了加一个在线客服、加一个埋点统计、加一个AB测试SDK，每个脚本都会往主线程上增加定时器、事件监听、MutationObserver。哪怕每个只占5毫秒，五六个第三方脚本加起来就是30毫秒的任务。平时看不出问题，一旦用户滚动页面，这些任务来回穿插，立刻掉帧。

2.3 过度使用setTimeout和setInterval

说得难听点，很多前端写异步代码就是在乱用定时器。数据轮询用setInterval没问题，但你至少要考虑页面对不可见时暂停轮询。而且setInterval本身有个特性：如果主线程卡顿，多个interval回调会排队等待，后面连续执行，造成任务激增。

还有拿setTimeout做动画的。早期没有requestAnimationFrame的时候，setTimeout确实可以模拟动画，但它的执行时机不受帧率控制，可能在两帧之间执行两次，也可能跳过一帧。现在还有人这么干，我只能说优化空间太大了。requestAnimationFrame才是浏览器为帧渲染专门设计的API，它会把回调安排在下一帧渲染之前，与浏览器节奏保持一致。

2.4 序列化、解析与高成本的数据处理

大量应用需要从后端拉取JSON数据并转成前端对象，这本来是常规操作。但当你处理的是一个巨型JSON，比如某个接口一次性返回10MB的配置数据，JSON.parse本身就要耗时几百毫秒。再加上前端框架的响应式系统会对每个字段做代理（Proxy）监听，10MB的数据转成响应式对象，那开销就更夸张了。

还有WebSocket消息的序列化和反序列化、ArrayBuffer与字符串的互相转换、大文件Base64编码，这些处理全都是主线程上的CPU密集操作。前端行业发展到今天，很多后台管理系统的代码已经复杂到这种程度，主线程其实是在超负荷运转。

3. 用Performance面板和指标精确定位主线程问题

3.1 Chrome Performance面板的核心用法

我一直觉得，不会用Performance面板的前端和不会用DevTools的厨师没有区别。这个工具能直接告诉你的页面主线程上到底跑了什么任务，每个任务花了多长时间。

我的使用习惯是这样的：打开无痕窗口，打开DevTools，切到Performance面板，点击录制按钮，然后在页面上复现卡顿场景（滚动、点击、切换路由），操作10秒左右停止录制。接着重点看Main线程的火焰图。

火焰图里横轴是时间，纵轴是调用栈，越高的层叠说明函数调用越深。你需要找的是那些深色、宽大的块——它们就是长任务。点击一个长任务块，下方会显示这个任务的调用栈，你能看到具体是哪个函数在耗时。

实际排查时最常见的发现就是：一个antd Table组件的render函数占了120毫秒、某个ECharts图表的setOption方法占了80毫秒、一段操作DOM的代码触发了两次强制同步布局占了60毫秒。这些数据不会说谎，比任何性能监控平台都更直观。

3.2 用PerformanceObserver量化线上问题

Performance面板只能解决本地复现的问题，线上用户遇到卡顿，你是看不到火焰图的。这时候就需要用PerformanceObserver来监控指标。

PerformanceObserver是浏览器提供的一组API，可以监听各种性能指标，包括长任务（LongTask）、布局偏移（LayoutShift）、渲染更新时间（Event Timing）。

我们项目里是这么做的：在入口文件里注册一个PerformanceObserver，专门监听longtask，把超过50毫秒的任务记录下来，连同当时的页面URL、UA、任务耗时、调用堆栈（如果浏览器支持attribution）一起打点到监控平台。这样用户反馈页面卡顿，你直接去监控平台查那个时间段的长任务列表，定位哪个功能模块在线上真实用户环境里拖垮了主线程。

这个思路解决了一个长期痛点：开发环境性能好不等于线上性能好。通过线上长任务监控，你能拿到真实用户的数据，根据这些数据分配优化排期，比靠猜和靠感觉靠谱得多。

3.3 关注Lightweight指标：长任务数量与总阻塞时间

分析主线程问题时，下面几个指标是我每天都要看的：

• Long Task数量：超过50毫秒的任务个数，越多说明主线程越繁忙
• Total Blocking Time，简称TBT：主线程被长任务阻塞的总时间，这个值会直接影响LCP指标的钻探
• INP：交互延迟指标，反映用户操作到页面反馈的时间
• 帧率帧时间：卡顿的直接体现，帧时间超过16.7毫秒就说明已经掉帧了

在Performance面板里，你可以在Summary区域看到每个环节的耗时占比（Scripting、Rendering、Painting等）。如果Scripting占大头，说明JavaScript逻辑有问题；如果Rendering占大头，说明样式和布局有问题；如果Painting占大头，那得考虑减少绘制区域或者用CSS动画替代JavaScript动画。

这里我建议每次大促活动、大版本上线前，都跑一遍性能基线测试。用Performance面板录制一个固定操作流程（比如进入列表页、搜索、翻页），记录TBT这些指标作为基线，后续每次代码变更都对比一次。这样可以防止性能问题回归，比出了问题再回头排查效率高太多。

4. 主线程优化实战：从任务拆分到异步化

4.1 长任务拆分：让出主线程的两种姿势

识别出长任务之后，下一步就是拆任务。拆的目的不是减少总执行时间，而是把一个100毫秒的任务拆成两个50毫秒以内的任务，中间让主线程有时间处理渲染和事件响应，用户感知上就是“没有那么卡了”。

第一种拆法是分片执行。比如有一个需要遍历100万条数据的for循环，如果一次性执行完肯定会卡。可以改成每次处理一定数量的数据，然后通过postMessage或setTimeout把控制权交还给浏览器，分批次处理。

具体代码类似这样：

async function processLargeArray(items, chunkSize = 500) { let index = 0; while (index < items.length) { const chunk = items.slice(index, index + chunkSize); // 处理当前分片 processChunk(chunk); index += chunkSize; // 让出主线程，等下一帧再继续 await new Promise(resolve => { requestAnimationFrame(resolve); }); } }

这里用requestAnimationFrame而不是setTimeout是有讲究的。requestAnimationFrame会在浏览器准备渲染下一帧之前执行回调，意味着每处理完一个分片，浏览器都有机会执行渲染任务，用户看到的是列表在“持续加载中”，而不是无响应的假死状态。

第二种拆法是使用scheduler.postTask。这是现代浏览器提供的任务调度API，可以给任务设置优先级（user-blocking、user-visible、background）。简单说，你可以把不重要的数据处理（比如埋点上报、日志上传）标记为background优先级，把点击响应、滚动处理标记为user-blocking优先级，让浏览器自动调整任务执行顺序，让出主线程给更重要的交互。

4.2 Web Worker与OffscreenCanvas：把计算搬到后台线程

有些任务确实是CPU密集型的，不管怎么拆都会超过50毫秒，比如图片处理、大量数据格式化、复杂计算。这时候正确姿势是让这些任务离开主线程，跑到Web Worker里面去。

Web Worker是浏览器提供的多线程机制，可以创建后台线程执行JavaScript，通过postMessage和主线程通信。我实际项目里用的最多的是这么几个场景：

第一个是数据格式化。接口返回10000条用户数据，每条包含多个字段，需要逐一处理后才能渲染。原来在主线程做，每次都要卡一两百毫秒。后来把数据处理的逻辑搬到Worker里，Worker线程处理完通过postMessage把结果发回主线程，主线程只需要做一次赋值。首屏渲染时间直接快了3倍。

第二个是图片二进制处理。前端经常需要把用户上传的图片做压缩和裁剪，如果直接在FileReader里操作ImageData，大图片会让主线程卡死。用OffscreenCanvas结合Worker，把图片解码、缩放、压缩全部放在后台线程执行，主线程只负责接收最终的Blob对象。我已经用这种方式处理过一个20MB的图片上传场景，用户无感完成压缩。

第三个是复杂状态计算。比如表格的过滤、排序、汇总统计，这些在数据量大的时候非常消耗CPU。把原始数据发给Worker，Worker负责计算，计算完返回结果，主线程只需要更新UI。

需要提醒的是，Web Worker不是银弹，每次postMessage传数据都有克隆开销。如果数据结构太复杂，克隆时间可能比计算还长。实际项目中，要么用Transferable Objects（可转移对象）转移ArrayBuffer，要么分批传递数据，而不是一次性传一个巨大的对象。

4.3 最小化布点重排与强制同步布局

前面提到了强制同步布局，这里详细说说怎么避免。

浏览器的布局是异步批处理的：一段JavaScript代码执行期间，如果你只写样式不改样式，浏览器会在脚本执行完之后统一布局。但如果你在脚本里先读取了一个会导致布局的属性（offsetTop、offsetHeight、getBoundingClientRect），紧接着又修改了样式，浏览器就不得不暂停JavaScript执行，先同步做一次布局，确保读到的值是最新的。下次再读取、再修改，再来一次。这就是布局抖动。

一个很典型的糟糕代码长这样：

function resizeElements() { for (let i = 0; i < items.length; i++) { items[i].style.width = container.offsetWidth / 2 + 'px'; } }

循环里每次都读取container.offsetWidth（触发布局）又修改样式（标记需要重排），浏览器被迫执行了N次同步布局。优化方式很简单：先把需要读取的值一次性拿到，再批量修改样式：

function resizeElements() { const halfWidth = container.offsetWidth / 2; for (let i = 0; i < items.length; i++) { items[i].style.width = halfWidth + 'px'; } }

这只是最简单的情况。实际开发中，我建议大家记住一个原则：读样式和写样式的操作要分开，先集中读，再集中写。

另一个重要手段是使用CSS的content-visibility属性。对长列表页面，这个属性可以直接跳过屏幕外的元素渲染，对主线程的样式和布局计算有巨大的节省效果。设置成content-visibility: auto，浏览器会自动跳过视口外的元素渲染，滚动到视口时才恢复渲染。实测在长文档页面上，这个属性能把渲染时间降低70%以上。

4.4 框架层面的优化：React并发与组件拆分

2026年了，React 19已经全面落地，并发特性（Concurrent Mode）已经是在生产环境可用的状态。并发特性最核心的机制是：React可以中断渲染任务，先处理用户的紧急交互，再回来继续渲染。这意味着列表更新这种大任务不再是一口气执行完，而是分帧执行，中间可以穿插处理用户的点击和滚动。

但要注意，并发渲染不是自动开启的，你需要配合使用合适的状态更新方式。useTransition可以把非紧急的状态更新标记为可中断的转换，useDeferredValue可以对数据变化做延迟处理。这两个API是解决好几百行列表更新问题的关键。

我实际项目中的经验是：当用户在输入框输入关键词过滤一个超长列表时，不用useTransition的版本，每次输入都会触发列表全量重渲染，键盘敲入一个字母就卡一次。加了useTransition之后，输入框本身的响应优先级更高，列表更新会被延迟到空闲时处理，打字手感立刻流畅了。

除了框架本身的并发特性，组件拆分也是降低主线程压力的重要手段。一个页面几十个组件，状态一变化所有组件都可能受影响。使用React.memo、useMemo、useCallback做组件层面的优化，减少不必要的渲染，是从源头减少主线程工作量。

4.5 虚拟滚动：大数据列表的终极解决方案

如果你还在用“渲染全部数据”的方式处理上千行的表格或列表，虚拟滚动是你必须掌握的技能。

虚拟滚动的原理很简单：不管数据有多长，只渲染视口内可见的那部分DOM节点，其余的用空占位符填充高度。这样DOM节点数量始终保持在20-30个的量级，样式计算、布局、绘制都只针对这几十个节点，主线程的工作量骤降。

市面上的库很多：react-window、react-virtualized、vue-virtual-scroller等，都做得比较成熟。我的建议是，优先选择体积小的，比如react-window，它只有几KB，API也简单，够用。除非你需要处理可变高度的列表，那可能得考虑react-virtualized或者自定义实现。

要注意的是，虚拟滚动和某些布局方式会冲突。比如表格里用了position: sticky（表头固定），或者元素依赖测量高度，虚拟滚动实现起来会比较麻烦。但为了主线程的性能，这点复杂度很值得。

4.6 请求策略优化：减少主线程的无效工作

除了计算和渲染，网络请求的处理方式也会影响主线程。每收到一个HTTP响应，浏览器都要在主线程上解析响应体（JSON.parse、文本解析），如果响应体很大，解析本身就会卡住主线程。

两个优化方向：一是从后端入手，接口返回更少的数据，通过字段筛选、分页、压缩来减小响应体体积；二是前端使用流式处理，比如用流式接口（SSE、HTTP流）逐步接收数据并增量渲染，而不是等所有数据到达后再一次性解析处理。

我在一个报表项目里使用过Streaming渲染：后端分批返回10000条数据，前端每收到一批就渲染一批，用户在加载过程中已经能看到部分数据先展示出来了，主线程不会被一个大JSON的解析卡死，用户体验也好了很多。

5. 主线程问题的常见排查技巧与经验汇总

5.1 线上性能问题的排查路径

遇到线上“页面卡成PPT”的反馈，我一般的排查顺序是这样的：

先看监控平台的长任务数量和TBT趋势，确认是某个版本上线后才恶化的，还是长期存在的问题。如果是版本上线后出现的，就用git bisect快速定位到具体提交，回滚或者修复。如果长期存在，就用A/B对比的方法，逐步禁用第三方脚本、国内CDN资源、某些功能模块，看哪个模块对长任务影响最大。

这里要特别强调“组件级定位”的方法：把首页拆成几个独立组件，每个组件单独禁用再测性能。比如怀疑数据表格卡，就临时把表格替换成静态数据；怀疑ECharts卡，就临时把图表隐藏。通过二分法切换定位，通常能在半小时内锁定问题组件。

5.2 一个真实案例：从200ms到16ms的优化过程

分享一个我实际做过的优化案例。一个后台管理系统的报表页，用户反馈“筛选条件一变，页面至少卡2秒”，后来优化到流畅运行，总耗时从200毫秒降到了16毫秒以内。

最初的代码逻辑是这样的：用户点击查询按钮后，前端拿到10000条数据，先做复杂的数据转换（把扁平数据转成树形结构），再交给ECharts渲染四五个图表，同时一个antd表格同步渲染明细数据。排查后发现，数据转换函数本身就要跑600毫秒（在低端机上更久），ECharts setOption全量更新所有图表用了800毫秒，表格渲染又占了几百毫秒。

优化分三步走：

第一步，把数据转换逻辑迁移到Web Worker，页面收到原始数据后立即转交给Worker线程，主线程只需要等待Worker的回调。转换耗时从600毫秒降到了几乎为零（主线程上只剩postMessage的几毫秒开销）。

第二步，ECharts图表优化。把一次setOption更新所有图表改成只更新数据变化的图表，同时关闭动画和过渡效果（type: 'line'时设置animation: false），减少渲染开销。使用ECharts的appendData接口做增量数据追加，避免全量替换。

第三步，antd表格启用virtual属性（Ant Design表格组件自带虚拟滚动），设置scroll.y后表格只渲染可视区域的行。

最终效果：主线程耗时从200毫秒降到16毫秒以内，完全符合一秒60帧的标准，用户再怎么切换筛选条件都很流畅。而且代码逻辑没变，功能完全一致，只是调整了执行位置和执行方式。

5.3 常用性能优化措施一览

我把日常工作中最常用的主线程优化措施整理成了一张表，方便按场景直接查：

5.4 常见性能问题的排查技巧速查表

根据这几年做性能优化的经验，我把踩过的坑和对应解法整理成了一张速查表，遇到问题可以直接对照排查：

6. 2026年前端面试与工作中必备的主线程能力

6.1 面试中被追问的主线程问题

现在前端面试越来越卷，深度学习能力和底层原理理解被问得非常频繁。关于主线程这块，面试官基本会从这三个角度问：

第一层是概念理解：“浏览器的渲染进程里有几个线程？主线程是干什么的？什么是长任务？”这一层属于八股文，背诵题，基本都能答上来。

第二层是原理深挖：“事件循环和渲染是什么关系？为什么说JavaScript会阻塞页面渲染？requestAnimationFrame和setTimeout在帧时机上的本质区别是什么？”这一层需要真正理解渲染管线和事件循环的执行顺序，答得好才能拉开差距。

第三层是实战落地：“如果一个表格有10万条数据，你会怎么优化？”“你在项目中遇到过长任务吗？怎么定位和解决的？”“Web Worker与主线程通信的性能开销怎么处理？”这一层没有标准答案，关键在于你是否真的做过、踩过坑、形成自己的判断。

针对第三层，我的建议是：不要背模板，而是把你自己做过的真实性能优化案例讲透彻，从问题现象、定位过程、优化方案到结果数据，完整展示你的排查链路和思考深度。面试官要的是你会不会解决问题，而不是你背了多少API。

6.2 前端开发中的主线程敏感心智建设

在日常开发中，我建议每个前端都建立一种“主线程敏感”的直觉：每次写代码之前，心里问自己一句——这段代码会让主线程多干多少活？

写一个组件时，想一下它每次渲染要执行多少计算；绑定一个事件时，想一下回调里做了什么处理；写一个全局状态时，想一下它变化会触发多少组件重新渲染。

这个直觉不是说让你什么都不敢写，而是让你在写高风险代码的时候——大循环、大批量DOM操作、超大JSON解析——能意识到它的潜在代价，以及有没有更省力的方案。真正优秀的前端，是能在代码里就预判性能问题，而不是等到线上卡顿了再回过头来排查。

我个人的经验是：给自己定一套代码规范，比如“超过5000条数据的渲染必须用虚拟滚动”、“任何回调里不允许连续读取布局属性后再修改样式”、“所有超过10万条数据的计算必须放到Worker里”。把这些约束写进团队的代码评审标准里，从源头杜绝主线程问题的产生。

6.3 主线程优化之外：一套完整的前端性能优化流程

说句实在话，主线程优化不是性能优化的全部，但它是承上启下的核心环节。一套完整的性能优化流程应该是这样的：

先用真实用户的性能监控数据（CrUX、RUM）定位问题页面和问题指标，决定优先级。然后用Performance面板和PerformanceObserver做问题拆解，精确找到瓶颈代码。接着根据瓶颈类型选择对应的优化手段——主线程相关的用前面说的方法，网络相关的用CDN、缓存、压缩，资源相关的用懒加载、代码分割。最后上线前跑性能基线，上线后持续监控，确保不回归。

这套流程的核心思想是：用数据说话，而不是拍脑袋优化。很多前端一上来就想着“我要把首屏时间优化到1秒”，但连问题在哪都不知道。更合理的做法是：先看数据，找到最大瓶颈，用最小的成本解决最大的问题。

主线程优化是一个持续迭代的过程，不存在“优化一次就永远不卡”的情况。每次业务迭代都可能引入新的主线程压力，所以性能监控必须常态化、体系化。

写在最后的一点个人体会

做了这么多年前端，我越来越觉得，所谓技术功底，很多时候不在于你会多少框架API，而在于你对底层原理的理解深度。主线程就是这么一把钥匙——你理解了它，就能解释“为什么这个列表会卡”“为什么首屏这么慢”“为什么点击没反应”，你能透过现象看到本质。

说句掏心窝的话，每次在新项目里看到那种大而全的第三方脚本引入、一次渲染上万条数据的写法，我都忍不住想：这些线上问题，其实在写代码的那一刻就已经注定了。前端性能不是上线后修复出来的，而是一行一行写出来的。

如果你正在为“页面卡成PPT”这个问题头疼，建议按这篇文章的方法去排查一遍。先从Performance面板入手，找到最长的那几个任务，然后判断是执行太多（拆任务）、计算太重（移出主线程）、还是渲染太多（虚拟滚动和样式优化）。大多数情况下，做完这三步，你的页面就基本告别“PPT体验”了。