企业官网建设流程全解析

上个月接手一个商城首页，打开要3秒多，滚动起来一卡一顿。JavaScript性能优化，说到底是用户体验的事。下面这20个实战技巧，是我这几年在生产环境里反复验证过的，按渲染交互、代码执行、加载网络、运行监控四个维度排开，覆盖从页面加载到运行时性能的完整链路，可以直接抄作业。不管你是刚转前端的新手，还是带团队做技术评审的负责人，我尽量用不绕弯的写法，把每个技巧的原理、做法、坑一次性讲透。优化前后的差别，用户未必说得出来，但他们的手会告诉你：滑动是否跟手、按钮是否立即响应、列表是否秒开。

1. 渲染与交互层优化：让页面先“快”起来

用户感知最明显的“卡”，十次里有八次出在渲染和交互层。浏览器喜欢一次性把事情做完，但用户的鼠标滚轮不会等它。这一层优化先把事件处理、DOM操作、动画这些最容易“肉眼可见”的瓶颈解决掉。

1.1 技巧1：节流与防抖，事件处理函数别裸奔

先说一个常见的反例：搜索框每敲一个字符就发一次请求，页面滚动时每滚一像素就执行一次重量级计算。这种场景下事件本身没有错，错的是触发频率远高于实际处理能力。防抖是把连续触发合并成最后一次执行，节流则是保证一段时间内只执行一次。二者解决的问题不同，别混着用。

// 防抖：适合输入搜索、窗口resize后重新计算 function debounce(fn, delay = 300) { let timer = null; return function(...args) { clearTimeout(timer); timer = setTimeout(() => fn.apply(this, args), delay); }; } // 节流：适合滚动监听、拖拽、频繁点击 function throttle(fn, wait = 300) { let last = 0; return function(...args) { const now = Date.now(); if (now - last >= wait) { last = now; fn.apply(this, args); } }; }

踩过的坑有两个。一个是防抖会带来“响应延迟”，用户输完字还要等一会儿才看到结果，体感反而更差。解决方法是给防抖加一个最大等待时间，比如同时用setInterval兜底，保证即使输入一直不停，至少每400ms响应一次。另一个是我见过有人给滚动事件做防抖，结果页面停下来之前根本不触发任何处理，需要展示的内容迟迟不出现。滚动类高频事件该用节流，而不是防抖。

1.2 技巧2：DOM批量更新，把重排重绘的次数压到最低

浏览器渲染是很贵的。每改一次DOM，都可能触发布局重排和重绘。如果在一个循环里连续插入100个列表项，浏览器就要反复“重新排版”100次。解决思路是批量操作，把改动攒成一次。

// 反例：循环里逐个插入 const listEl = document.querySelector('#list'); items.forEach(item => { const li = document.createElement('li'); li.textContent = item; listEl.appendChild(li); // 每次都触发布局 }); // 正例：先用DocumentFragment攒起来 const frag = document.createDocumentFragment(); items.forEach(item => { const li = document.createElement('li'); li.textContent = item; frag.appendChild(li); }); listEl.appendChild(frag); // 只触发一次布局

另一个思路是“离线”操作：给目标容器加display: none，改完再显示，让浏览器在元素隐藏时一次性处理所有样式变化。但注意别反过来踩坑——有些人为了批量更新，把一段不需要隐藏的代码也包进display:none里，结果用户能看到短暂闪烁。批量更新的核心不是用什么API，而是减少强制同步布局的次数。还有一点特别容易忽略：在循环里读取el.offsetHeight、el.clientWidth这类会强制刷新布局的属性，会让前面的DOM改动立刻重排一次，性能直接崩掉。正确的做法是“先批量改，再一次读”。

1.3 技巧3：高频更新用requestAnimationFrame，别再用setInterval

动画和滚动类高频更新，很多人习惯用setInterval(fn, 16.7)模拟60fps，这个习惯要改掉。浏览器的刷新频率是16.7ms左右一帧，但setInterval并不保证跟屏幕刷新对齐，可能一帧内执行两次，也可能隔帧执行，导致画面抖动，而且后台标签页的定时器会被降频甚至挂起，严重影响体验。

requestAnimationFrame是浏览器专为动画设计的API，它会在每次屏幕刷新前调用，由系统自动对齐帧率，页面不可见时自动暂停，既不耗电也不卡顿。比如做滚动进度条或吸附效果，用rAF把更新塞进渲染帧里，能明显减少卡顿感。

let ticking = false; window.addEventListener('scroll', () => { if (ticking) return; ticking = true; requestAnimationFrame(() => { updateScrollStatus(); ticking = false; }); });

这里有个容易出错的点：rAF里不要做重活，别在回调里塞大量DOM操作或复杂计算。rAF只负责“把更新安排到下一帧”，如果回调本身执行超过16.7ms，帧率照样掉。如果确实需要做复杂计算，放到Web Worker或者在rAF回调里拆分任务，这个思路后面会细说。

1.4 技巧4：动画优先用transform与合成层，别再动top/left

页面里做位移、缩放、旋转，最方便的是直接改top、left或者width、height，但这是对性能最不友好的做法。改top/left会触发布局和重绘，浏览器需要重新计算整棵渲染树的位置；改width/height同理。而transform和opacity只触发合成，不需要经过布局阶段，性能要高一整个量级。

/* 不推荐 */ .box { position: absolute; left: 0; transition: left 0.3s ease; } .box.move { left: 200px; } /* 推荐 */ .box { transform: translateX(0); transition: transform 0.3s ease; } .box.move { transform: translateX(200px); }

很多人一听transform能提性能，就把will-change: transform加得到处都是，这是误用。will-change相当于提前告诉浏览器这个元素要经常变化，准备好合成层，但每个合成层都会占内存，上百个will-change同时存在，内存直接爆掉，滚动反而更卡。只有动画持续时间较长、且已经确认有卡顿问题时，针对单个元素加will-change才有意义。用完动画记得移除。

1.5 技巧5：事件委托，一个监听器接管整个列表

给列表里的每个子项分别绑定事件，是一件“当时省事、过后遭罪”的事。列表有500个可点击项，就注册500个监听器，内存占用高不说，动态新增的子项还得重新绑定。事件委托利用事件冒泡机制，把监听器挂到共同的父元素上，通过判断event.target决定是否处理。

document.querySelector('#list').addEventListener('click', (e) => { const item = e.target.closest('.list-item'); if (!item) return; handleItemClick(item.dataset.id); });

我见过有人踩坑：直接在document上委托所有点击事件，然后回调里做一堆字符串判断，不仅性能没变好，代码还变得极难维护。事件委托适合“大量相似子元素、子元素需要相同交互”的场景，比如列表、表格、菜单。如果页面上只有三五个按钮，完全没有委托的必要，直接绑更清晰。另外注意，滚动、鼠标移动这类高频事件委托到document层会让函数一直在主线程里被调用，哪怕你用节流，也要确认回调真的轻量。

2. 代码执行层优化：把主线程的每一毫秒还给用户

渲染层优化做完，页面可能已经流畅不少，但主线程上还有隐藏的CPU杀手。JavaScript是单线程语言，所有计算都在主线程排队执行，一旦某个任务耗时过长，用户的点击、滚动、输入就会被堵在后面。这一层优化的目标很直接：压缩主线程的工作时间。

2.1 技巧6：长任务拆分，别让主线程一次干太久

浏览器有一个“长任务”的概念，超过50ms的任务就会被标记为Long Task，它会阻塞用户交互。为什么是50ms？因为浏览器要保证对用户输入的响应足够快，任何超过这个阈值的连续工作，都会让页面看起来像卡死。一个计算量很大的for循环，如果一口气跑完消耗800ms，用户在这800ms内点任何按钮都没反应。

解决办法是把大任务拆成小任务，让它们分散到不同的帧里执行。比如遍历一万条数据处理时，每处理100条就让出一次主线程，再继续下一批。

function processInChunks(data, chunkSize = 100) { let index = 0; function next() { const end = Math.min(index + chunkSize, data.length); for (; index < end; index++) { process(data[index]); } if (index < data.length) { requestIdleCallback(next, { timeout: 500 }); } } next(); }

requestIdleCallback会把任务安排到浏览器空闲期执行，但如果浏览器一直不空闲，任务就永远得不到机会，所以必须传timeout兜底。低版本浏览器不支持时，退回去用setTimeout(next, 0)也能拆任务。还有一点：拆分后要小心任务之间的状态共享，如果每批任务都依赖上一次的结果，得先把中间结果保存在变量里，别把循环变量搞乱。

2.2 技巧7：大数据计算丢给Web Worker，主线程只负责收结果

拆任务能让长任务不阻塞界面，但如果计算量大到必须尽快出结果，拆任务反而总耗时更长。这时候应该开Web Worker，把计算挪到独立的线程里跑，主线程继续响应交互。

// main.js const worker = new Worker('calc.js'); worker.postMessage({ type: 'process', data: bigArray }); worker.onmessage = (e) => { renderResult(e.data); }; // calc.js self.onmessage = (e) => { const result = heavyCalculation(e.data); self.postMessage(result); };

Web Worker适合纯计算的场景：数据处理、图片像素操作、加密、复杂校验、批量转换。但它有几个限制必须提前知道：Worker里不能直接操作DOM，不能访问window和document，通信靠postMessage传结构化数据。这里有个容易踩的坑：传给Worker的数据要经过结构化克隆，如果数据量巨大，克隆本身就有不小的开销。数据在1MB以下可以随便传，超过几MB时就要考虑用Transferable对象转移，比如ArrayBuffer，转移过程是零拷贝的。

还有一点建议：不要每个小任务都开一个Worker，线程创建有成本。一个页面里的并行计算任务，用两三个Worker复用就足够了，复杂场景可以直接上线程池。

2.3 技巧8：对象池复用高频对象，减少GC压力

垃圾回收（GC）在JavaScript里是自动的，但GC执行时会让主线程暂停一会儿，频繁创建和销毁大量对象，就会频繁触发GC，造成肉眼可见的卡顿。对象池的思路很简单：对象用完不丢，放回池子里，下次要用直接从池里取，减少创建和销毁的重复开销。

最典型的场景是游戏或实时画布里的粒子对象、弹幕、频繁展示的临时气泡。拿粒子来说，每秒要创建几百个粒子、销毁几百个粒子，如果每个都新建对象，内存分配和回收压力非常大。对象池实现大概是：

const particlePool = []; function getParticle() { return particlePool.pop() || new Particle(); } function releaseParticle(p) { p.reset(); particlePool.push(p); }

这里的坑是：对象复用后，旧状态必须完全重置。我见过有人漏掉了一个属性没清，导致复用的对象带着上一帧的颜色或位置，画面出现诡异的残留。另一个坑是池子里的对象如果被外部持有引用，放回池后又被改动，会连带影响下次取用。对象池只适合重量级、高频率的对象，不是所有对象都需要池化，不要让代码复杂度无意义上升。

2.4 技巧9：用Map和Set替代朴素对象做高频查找

对象字面量{}在JavaScript里很万能，但高频查找、频繁增删键值对的场景，它未必是最优选择。ES6的Map和Set在设计上更适合动态操作，查找复杂度同样是O(1)，但迭代有序，删除键值不会产生原型链污染问题，而且键可以是对象。

一个具体例子：管理一个“已读消息ID集合”。如果写成const readSet = {}，每次判断时写readSet[id] = true，会隐藏两个问题：ID是字符串时可能跟原型链属性冲突，比如id = 'toString'；而且频繁增删时对象是隐藏类机制，优化也不如Set来得稳。改用Set不仅更简洁，性能也更稳定：

const readIds = new Set(); readIds.add(msg.id); if (readIds.has(msg.id)) return; // 已读

另外一个常见的坑是“为省事把数组当Map用”，比如用find遍历数组找对象，数组一长这种查找就是O(n)，性能随数据量直线下滑。碰到高频查找的场景，先花两分钟想清楚该用Map还是Set，数据量上万时差别是几十倍的。

2.5 技巧10：位运算做状态集合，空间和时间一起省

位运算是一类容易被忽略的优化手段。如果页面里有一组互斥或组合的布尔状态，比如权限标记、配置开关，与其写七八个true/false变量，不如用一个整数表示，每一位代表一个开关。判断时用按位与，开启用按位或。

const PERM_VIEW = 1; // 0001 const PERM_EDIT = 2; // 0010 const PERM_DELETE = 4; // 0100 let role = PERM_VIEW | PERM_EDIT; // 能看能改 if (role & PERM_EDIT) enableEdit(); // 按位与判断

位运算的优点不止是省内存，CPU计算位操作比布尔逻辑更快，而且状态集合传参时只需要传一个数字，非常干脆。但代价是可读性下降，团队其他人来维护时，看到0b10110可能一脸茫然。我的建议是：只在状态足够多且变化频繁、团队约定清晰的场景用，且一定要配合良好的常量注释，否则会给后续维护埋坑。为了省一个变量而把代码弄到没人敢动，性价比很低。

3. 加载与网络优化：从资源层面压榨加载速度

运行时再流畅，页面半天加载不出来也白搭。加载阶段的优化核心是“少传、延后、并行”，每一毫秒的加载时间都直接影响用户跳出率。这个环节的优化通常要跟前端工程化配置、后端响应头一起配合。

3.1 技巧11：代码分割，按路由加载而不是一锅端

很多项目早期的写法是一个入口文件打到底，所有页面的代码全打包进一个bundle。首屏可能只需要登录页的逻辑，却连后台管理页的图表库一起下载了。代码分割的目的就是把一个大包切成若干小包，首屏只加载首屏需要的代码，其他页面等用户访问时再按需加载。

现代打包工具都支持动态import，React和Vue路由懒加载是标配：

const routes = [ { path: '/home', component: () => import('./pages/Home.vue') }, { path: '/report', component: () => import('./pages/Report.vue') }, ];

这里有个反直觉的地方：很多同学以为切得越细越好，最后切成几百个小文件。文件数量上去了，HTTP请求数也上去了，HTTP/2下虽然并行连接问题不大，但每个请求的耗时、解析开销仍然存在，反而可能更慢。正确的做法是按“路由级”或“业务模块级”切，把关联紧密的组件打包到一起，公共依赖抽成单独的vendor包，控制在几十KB到几百KB的合理粒度。

还有一个容易忽略的坑：不要把动态import的组件在页面还没真正需要时就提前import()。比如我在一个项目里见过，为了“优化”，在首页加载完成后就去预加载所有路由的组件，结果首屏wifi环境下没问题，弱网环境下首页反而更慢了，因为它在偷偷抢带宽。

3.2 技巧12：preload、prefetch、preconnect，资源提示要分清

浏览器资源提示看起来不起眼，用对了效果明显。三者的分工完全不同：

<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin> <link rel="prefetch" href="/next-page.js"> <link rel="preconnect" href="https://api.example.com">

最容易犯的错是把所有资源都preload。preload的优先级很高，不加区分地preload一堆图片字体，会让真正关键的资源排队等待，首屏反而变慢。prefetch也类似，只适合你非常有把握用户会访问的页面，不能当成免费午餐。preconnect则要注意，浏览器对每个域名都会维持连接，无限制地preconnect十几个域名，内存占用和网络连接数都会增加，一般控制在3个以内。

3.3 技巧13：图片懒加载，交给浏览器也留好兜底

图片往往是页面上最重的资源。传统的懒加载需要监听滚动位置、计算图片是否进入视口，自己实现很容易出bug。现代浏览器已经支持原生懒加载：

<img src="big.png" loading="lazy" width="1200" height="800" alt="">

loading="lazy"简单高效，但有两件事得自己兜底。第一，老浏览器不认识这个属性，懒加载完全不生效。需要加一个基于IntersectionObserver的降级方案，检测到不支持时再用JS做懒加载。第二，占位空间问题。图片没有设置宽高时，懒加载图片一开始不占空间，等滚动到位置时图片加载出来，页面布局突然跳一下，产生CLS，拉低核心体验指标。所有img标签都该写width和height，或者用CSS aspect-ratio占住位置。

这里有个特别重要的坑：首屏大图不能懒加载。首屏的LCP图片一旦懒加载，会让核心内容延迟展示，直接伤害用户体验。首屏图片正常加载或preload，滚动区以下的图片才懒加载。

3.4 技巧14：关键CSS内联，非关键CSS异步加载

CSS是渲染阻塞资源，浏览器遇到CSS会停下来等它下载完再渲染。首屏CSS如果是一个几百KB的大文件，用户看到的内容是白屏等待。优化的常见思路是把首屏真正用到的CSS（关键CSS）内联到HTML的<style>里，其余非关键CSS异步加载。

<style> /* 关键CSS直接内联 */ .header { ... } .hero { ... } </style> <link rel="stylesheet" href="/non-critical.css" media="print" onload="this.media='all'">

用media="print" onload="this.media='all'"这种写法可以让非关键CSS不阻塞渲染，加载完再生效。但这里有个平衡问题：内联CSS太多会让HTML变大，HTML本身就是首屏必须传输的资源，内联超过50KB的关键CSS反而拖慢首屏。我一般建议内联的CSS控制在10KB到20KB以内，只覆盖首屏视口区域的样式，其余交给异步加载。还有个细节：内联CSS和外部CSS重复时，要保证非关键CSS加载完之后不会覆盖掉关键样式，造成页面“闪一下”，建议把非关键CSS的范围限定在首屏之下的模块。

3.5 技巧15：HTTP缓存与服务端协作，让重复访问秒开

网络请求再快也快不过缓存。静态资源的HTTP缓存策略通常依赖文件名加哈希，比如app.a3f9e2.js，文件内容变了哈希就变，浏览器缓存自然失效。配合响应头Cache-Control: max-age=31536000, immutable，这类哈希资源可以被浏览器年为单位缓存。

Service Worker则更进一步，可以在浏览器端拦截请求，直接把资源从本地缓存取出来。经典的离线优先策略是“App Shell”：首次访问时缓存完整的页面骨架和静态资源，后续访问即使断网，也能从缓存里渲染出基本界面。我实际项目中会这样处理：

self.addEventListener('fetch', (event) => { if (event.request.mode === 'navigate') { event.respondWith( caches.match(event.request).then(res => res || fetch(event.request)) ); } });

Service Worker最大的坑是缓存更新问题。旧版本的SW会一直占据着页面控制权，用户怎么刷新都拿到旧资源。解决方案是把版本号写进SW文件名，更新时先self.skipWaiting()再配合clients.claim()，让新SW尽快接管。另一个容易踩的坑是缓存策略不分资源类型：HTML应该网络优先，图片和静态JS可以缓存优先，接口请求绝不能被缓存复用，否则用户看到的数据永远是旧的。

4. 运行时与监控优化：让性能问题无处可藏

前面的技巧解决的是“如何优化”，但优化完之后怎么验证、怎么防止性能回退，同样重要。这一层的核心是让性能问题可度量、可追踪，不然优化就是一笔糊涂账。

4.1 技巧16：建立可量化的性能基线，别靠感觉判断

“我感觉页面好像快了一点”，这句话在性能优化里毫无价值。所有优化都必须建立在可量化的指标上。浏览器的Performance API提供了精确的时间测量能力，performance.now()可以拿到毫秒级甚至微秒级的高精度时间戳，比Date.now()稳定得多。

const start = performance.now(); doSomething(); console.log('耗时', performance.now() - start);

还可以用PerformanceObserver监听长任务和资源加载耗时。我在项目里习惯用Lighthouse跑一次固定的性能审计，把FCP、LCP、CLS这些指标记下来作为基线，之后每合入一版代码，对比基线的变化。如果优化后LCP慢了一秒，那这次改动大概率引入了问题。这里有一个经验：基线要在固定网络节流下测，比如DevTools里设置Slow 4G，真实用户不同网络环境差异太大，同一台电脑跑两次结果都可能不一样，测出来波动小于10%都不算显著变化。

4.2 技巧17：盯紧核心Web指标，LCP、CLS、INP分别优化

性能指标很多，但真正跟用户体验强相关的就三四个。LCP衡量最大内容绘制时间，代表“页面主要内容是否已经可见”；CLS衡量布局稳定性，代表“页面有没有乱跳”；INP衡量交互响应延迟，代表“用户每次点击、输入后页面多久有反应”。这三个指标直接影响用户会不会流失。

每个指标对应的优化方向完全不同：

• LCP变慢：优先优化最大图片的加载、首屏渲染路径、以及服务器响应时间。给LCP图片加preload、压缩图片体积、代码分割减少首屏JS，都是直接有效的动作。
• CLS偏高：图片和嵌入元素必须预留宽高，动态插入内容不要挤占已渲染区域，字体加载要搭配字体度量调整。
• INP偏慢：减少长任务、优化交互事件处理函数、把复杂逻辑移出主线程。这里要注意，INP已经逐步取代了原来的FID，它衡量的是整体交互延迟，而不仅仅是首次输入。用户连续快速的点击，如果每次点击都要等主线程空闲才能响应，体验依然糟糕。

这三类指标放在一起，需要在同一个优化周期里同时观察，因为修了LCP可能让CLS变差，比如你为了让首屏更快把图片loading值改了，却没写宽高，结果页面布局崩了。

4.3 技巧18：内存泄漏排查，用快照对比找到游离DOM

页面越用越卡、内存占用只升不降，往往是内存泄漏。最常见的一个泄漏场景是：把某个DOM元素存进了JS变量或闭包里，同时把它从页面里移除了，结果它和它的子节点永远无法被回收。这种“游离DOM”很难通过肉眼发现，我一般用开发工具的Memory面板排查。

标准流程是：加载页面，先拍一个内存快照；然后做几次会让待测功能反复执行的操作；等稳定后再拍第二个快照，在快照对比里搜索Detached DOM节点，看有没有大量游离节点。

还有几个常见的泄漏来源：全局变量无意中变大，比如不小心把数据挂到了window上；setInterval没有清理，定时器回调持有整个对象引用；事件监听器绑在外部元素上，组件销毁时没有解除，导致组件被外部引用链保活。React/Vue项目里还要注意，组件卸载时清理自定义事件总线和第三方库的监听器，这个坑我踩过不止一次。

4.4 技巧19：长列表用虚拟滚动，几千条DOM靠“画”不靠“建”

一次性渲染几千条列表数据，DOM节点数量巨大，每条数据哪怕是几十个字节的文本，乘以几千也是不小的内存开销，更别说每条节点带的事件和样式。虚拟滚动的核心思想是：我们不需要渲染全部数据，只需要渲染用户当前可视区域内的那部分，滚动时动态替换节点内容。

实现上并不复杂：容器高度固定，根据滚动位置计算出起始索引，只渲染可视区加缓冲区的列表项，通过transform: translateY调整整体偏移。

container.addEventListener('scroll', () => { const startIndex = Math.floor(container.scrollTop / itemHeight); renderItems(startIndex, startIndex + visibleCount); });

这里最大的坑是“动态行高”。列表项高度不固定，比如每条内容文字长短不一，计算起始索引时如果还按固定高度算，就会出现滚动错位、条目跳动。解决方向是估算平均高度，滚动过程中持续校准，或者让列表项在渲染后才测量实际高度再更新偏移。另一个建议是只有列表超过几百条才用虚拟滚动，几百条以内直接正常渲染并不慢，虚拟滚动本身的复杂度反而容易引入新bug。

4.5 技巧20：框架层渲染优化，memo和useMemo要按需使用

React和Vue这类框架自带虚拟DOM和更新机制，但不代表写出来就一定快。React里最常见的性能问题是父组件一更新，子组件全部跟着重新渲染，即使子组件根本没依赖变化的数据。React.memo可以帮组件跳过不必要的重新渲染，前提是它的props没变。

const Child = React.memo(function Child({ value }) { return <div>{value}</div>; });

但这里有个很隐蔽的坑：如果你给子组件传的是一个内联函数或内联对象，比如onClick={() => doSomething()}，那么每次父组件渲染，props里的函数引用都是新的，React.memo的浅比较直接失效，优化等于白做。配合useCallback和useMemo固定引用才有效果。

另一个原则是别滥用memo。我见过有人把每个组件都包一层memo，结果依赖复杂、使用不当，代码可读性变差，性能也没提升。框架层优化一定先看Profiler面板，定位真正导致长时间渲染的组件，再针对性优化。Vue的优化思路略有不同，v-memo、动态组件配合defineAsyncComponent、以及善用computed避免额外计算，都是更自然的姿势。

5. 常见问题与排查技巧实录

技巧讲了20个，实际操作中还是会遇到各种状况。这一节把我自己排查性能问题时的一套固定流程和几张速查表整理出来，遇到问题别一头扎进代码里，按顺序排查会高效得多。

5.1 性能排查的标准流程

我先用Performance面板录制一段操作，找到主线程上的长任务集中在哪一段。这个是第一步，能快速定位“卡顿发生时在干什么”。然后看Network面板，重点查阻塞请求：有没有大文件、有没有请求串行、有没有未开启压缩的资源。这是第二步，因为很多“白屏久”的问题其实出在网络层。第三步打开Memory面板做内存快照，排查内存泄漏和频繁GC。最后才去看代码本身。

这四步顺序是有讲究的：先看性能火焰图能避免凭感觉改代码，比如你觉得是算法问题，结果火焰图显示卡顿发生在渲染，你优化半天算法也白搭。我之前就办过一件蠢事：一个列表卡顿，我以为是数据遍历慢，各种优化循环写法，结果Performance录制一看，卡顿全是布局重排造成的，列表项没有设置宽高导致图片加载后推挤布局，一层层改下来性能才真正好转。

5.2 问题速查表

这个表格不是让你死记硬背，而是排查时对照着问自己：当前问题属不属于这一类？原因方向对不对？方向错了，后面所有的优化动作都是白费。

5.3 项目落地的心得与建议

技巧真正落到团队项目里，比一个人自己改要难得多。我给团队整理了一份性能评审Checklist，新增页面、大列表、第三方接入都要过一遍：首屏有没有懒加载、图片有没有占位、滚动事件有没有节流、组件卸载有没有清理监听器。性能优化如果不变成流程的一部分，就会在一次次业务迭代中被慢慢吃掉。

踩过几次坑之后，我最深的感受是：性能优化并不神秘，难点在于持续做、可验证地做。如果热门的技巧堆了一堆但没有任何指标对比，下个迭代很快又会把性能改回去；如果能固定跑Lighthouse、定好基线、让每次改动都有数据反馈，优化成果才能留下来。如果你的项目正卡在“能跑但体验很差”的阶段，从上面20条里挑出与当前问题最相关的几项动手改，效果往往比想象中来得快。