控制臺(tái)里突然刷出一屏[Violation] Forced reflow while executing JavaScript took 87ms然后頁(yè)面滾一下來(lái)一條、點(diǎn)一下來(lái)一條開(kāi)發(fā)機(jī)上還沒(méi)什么感覺(jué)一上真機(jī)就開(kāi)始滑動(dòng)粘手打字掉幀——這個(gè)場(chǎng)景做 Vue 的同學(xué)基本都躲不掉。這條警告不是報(bào)錯(cuò)不影響功能所以它常年被埋在日志里沒(méi)人管但它幾乎是所有頁(yè)面越用越卡問(wèn)題的第一現(xiàn)場(chǎng)。它說(shuō)的是一件很具體的事JavaScript 執(zhí)行過(guò)程中觸發(fā)了強(qiáng)制同步重排Forced reflow瀏覽器為了把最新的布局?jǐn)?shù)據(jù)交還給你被迫中斷當(dāng)前 JS 執(zhí)行提前把渲染流水線跑了一遍這一趟花了 87 毫秒。而 87 毫秒在 60 幀的節(jié)奏里等于你連丟五幀還多。這篇文章想解決的就是這一類問(wèn)題Vue 項(xiàng)目里為什么特別容易踩到 Forced reflow、怎么用 DevTools 把它釘?shù)骄唧w那一行代碼、讀寫分離到底該怎么寫、第三方庫(kù)和動(dòng)畫場(chǎng)景怎么繞過(guò)去。內(nèi)容偏實(shí)戰(zhàn)代碼可以整段抄走改適合寫過(guò)一兩個(gè) Vue 項(xiàng)目、開(kāi)始關(guān)心性能但還沒(méi)系統(tǒng)整理過(guò)渲染流程的同學(xué)如果你只是想知道警告關(guān)掉行不行那答案是不行后面會(huì)說(shuō)為什么。1. 先把這條警告翻譯成人話1.1 瀏覽器渲染一幀要經(jīng)過(guò)哪幾步現(xiàn)代瀏覽器的渲染主流程可以粗略拆成五段JavaScript 執(zhí)行 → 樣式計(jì)算Style / Recalculate Style→ 布局Layout也就是重排 / Reflow→ 繪制Paint→ 合成Composite。JS 階段你改 DOM、改 class、改 inline style樣式計(jì)算把 CSS 規(guī)則解析成每個(gè)元素最終的計(jì)算樣式布局拿到計(jì)算樣式后算出每個(gè)盒子在頁(yè)面上的精確位置和尺寸繪制把盒子變成像素指令合成把這些指令按圖層拼成你看到的畫面。關(guān)鍵點(diǎn)在于布局這一步是惰性的。你在 JS 里改了el.style.width 200px瀏覽器不會(huì)立刻重算布局它只會(huì)在內(nèi)部標(biāo)記這個(gè)元素的布局臟了然后攢著。攢到什么時(shí)候攢到兩種時(shí)刻一是真的要畫下一幀了二是有代碼來(lái)問(wèn)它要布局結(jié)果。后者就是災(zāi)難的起點(diǎn)。因?yàn)橐坏┠銌?wèn)它要布局結(jié)果它沒(méi)法用舊數(shù)據(jù)糊弄你舊數(shù)據(jù)已經(jīng)過(guò)期了只能立刻停下來(lái)把樣式計(jì)算和布局全部跑完再把答案給你。這中間你的 JS 是被打斷的主線程被布局占滿這就是同步重排。所謂 Forced重點(diǎn)在被迫——瀏覽器本來(lái)想拖到幀末一起算的被你逼著提前算了。1.2 到底哪些操作會(huì)逼瀏覽器重排能觸發(fā)強(qiáng)制重排的操作本質(zhì)都是讀取幾何信息。這些屬性不是存在元素身上的靜態(tài)值而是布局算完才有的結(jié)果所以讀它們就等于向?yàn)g覽器要賬。常見(jiàn)的清單如下觸發(fā)源典型寫法說(shuō)明偏移尺寸offsetTopoffsetLeftoffsetWidthoffsetHeight最常被踩的一類循環(huán)里讀它等于開(kāi)重排循環(huán)客戶區(qū)尺寸clientWidthclientHeightclientTopclientLeft不含邊框常用于算滾動(dòng)容器可視高度滾動(dòng)尺寸與位置scrollTopscrollLeftscrollWidthscrollHeight寫scrollTop是寫操作但連著讀就會(huì)交替幾何矩形getBoundingClientRect()getClientRects()定位類組件、拖拽、Tooltip 全靠它計(jì)算樣式getComputedStyle(el).width等布局相關(guān)屬性讀color未必觸發(fā)讀width必觸發(fā)CSS 變量getComputedStyle(el).getPropertyValue(--x)變量參與了布局計(jì)算時(shí)同樣要 flush焦點(diǎn)與滾動(dòng)定位element.focus()scrollIntoView()內(nèi)部需要知道元素位置才能滾動(dòng)Range 相關(guān)range.getBoundingClientRect()富文本編輯器里非常常見(jiàn)這里有個(gè)非常重要的判斷標(biāo)準(zhǔn)很多人搞混連續(xù)讀是安全的連續(xù)寫也是安全的只有讀寫交替才致命。你一口氣讀一百個(gè)元素的offsetHeight瀏覽器只會(huì)重排一次因?yàn)榈谝淮巫x之后布局就是干凈的剩下的讀都在用同一份新鮮數(shù)據(jù)你一口氣寫一百個(gè)元素的寬高瀏覽器一次都不重排因?yàn)椴季直煌七t到幀末。但你要是讀一個(gè)、寫一個(gè)、再讀一個(gè)、再寫一個(gè)那就是一百次完整重排。注意console.log(el.offsetWidth)這種調(diào)試語(yǔ)句本身就是讀操作。有時(shí)候你只是加了幾行日志想看看尺寸警告就冒出來(lái)了別把這個(gè)鍋甩給業(yè)務(wù)代碼。1.3 警告里那個(gè) took 87ms 是怎么來(lái)的Chrome 會(huì)把每一次強(qiáng)制布局的耗時(shí)算出來(lái)超過(guò)一定閾值經(jīng)驗(yàn)上單次幾十毫秒級(jí)別就會(huì)在控制臺(tái)記一條 Violation。數(shù)字越大說(shuō)明這次重排的代價(jià)越離譜。為什么能這么大因?yàn)橐淮沃嘏挪恢皇撬隳氵@一個(gè)元素布局的波及范圍可能是整棵子樹(shù)甚至整個(gè)文檔。改了外層容器的寬度里面所有依賴百分比的子元素、所有的文本換行、所有的 flex/grid 分配都要跟著重算。一個(gè)幾千行的表格一次重排干到幾十毫秒一點(diǎn)都不夸張。更麻煩的是它會(huì)累積。你在mousemove里搞一次強(qiáng)制重排鼠標(biāo)移動(dòng)一秒觸發(fā)六十次那就是六十次重排主線程被切成碎片用戶看到的就是拖拽跟不上手。單看一條警告好像無(wú)所謂乘上觸發(fā)頻率就是災(zāi)難。2. Vue 項(xiàng)目為什么格外容易踩這個(gè)坑2.1 響應(yīng)式更新的批處理救了你也騙了你Vue 3 的更新是異步批處理的你在一個(gè) tick 里改了十個(gè)ref它只會(huì)在微任務(wù)隊(duì)列里 flush 一次patch一次 DOM。這本身是非常好的設(shè)計(jì)它天然把寫集中起來(lái)了。問(wèn)題出在讀上——Vue 只幫你批處理了寫沒(méi)管你的讀。于是很常見(jiàn)的寫法就變成了這樣組件里某個(gè)方法先改了一個(gè)狀態(tài)然后await nextTick()接著遍歷 DOM 子節(jié)點(diǎn)讀尺寸讀完根據(jù)尺寸再改一次狀態(tài)。這一輪下來(lái)寫、讀、寫交替得非常干凈每一次讀都在逼瀏覽器 flush。而且因?yàn)?Vue 的patch是深度優(yōu)先遍歷虛擬 DOM一個(gè)父組件的更新可能牽動(dòng)幾十個(gè)子組件同時(shí)掛載你在onMounted里讀一次尺寸就是幾十次讀擠在同一幀如果中間還夾雜著子組件的寫操作交替就發(fā)生了。還有一個(gè)隱蔽的點(diǎn)Vue 的nextTick用的是微任務(wù)Promise.then它跑在瀏覽器渲染之前的任意時(shí)刻跟幀的節(jié)奏沒(méi)關(guān)系。你在微任務(wù)里讀布局瀏覽器一樣得立刻滿足你。所以nextTick不是等渲染完它只是等 DOM 更新完DOM 更新完不代表布局算完了。這個(gè)區(qū)別決定了你很多我已經(jīng)nextTick了為什么還有警告的困惑。2.2 組件化本身會(huì)制造隱形讀寫交替單文件組件寫多了你很難一眼看出哪里在讀哪里在寫因?yàn)樽x寫散落在不同組件里。舉個(gè)我真實(shí)遇到過(guò)的例子一個(gè)父組件列表子組件里有個(gè)mounted鉤子用于根據(jù)自身寬度決定標(biāo)題要不要省略號(hào)。子組件掛載時(shí)會(huì)讀自己的clientWidth而父組件在插入這些子組件之前剛剛設(shè)置過(guò)容器的padding。結(jié)果就是子組件每掛載一個(gè)讀一次寬度而父組件的樣式寫入又讓布局臟掉下一個(gè)子組件讀的時(shí)候又得重排。一百個(gè)子組件就是一百次重排控制臺(tái)刷屏。這種問(wèn)題在組件層級(jí)越深、復(fù)用越多的項(xiàng)目里越嚴(yán)重因?yàn)閷懖僮靼l(fā)生在祖先讀操作發(fā)生在后代中間隔著好幾層組件邊界你根本不會(huì)把它們聯(lián)系起來(lái)。這也是為什么我認(rèn)為這條警告不能只靠看到就改得建立一個(gè)意識(shí)任何讀 DOM 尺寸的代碼都要問(wèn)一句我前面有沒(méi)有剛寫過(guò)樣式。2.3 Transition 和動(dòng)畫鉤子里的固定開(kāi)銷Vue 的Transition在實(shí)現(xiàn)上為了拿到過(guò)渡起點(diǎn)需要在元素插入后、添加過(guò)渡類名之前讀取一次布局信息這個(gè)操作本身就會(huì)強(qiáng)制重排。單個(gè)元素?zé)o所謂一兩個(gè)毫秒的事但列表過(guò)濾、v-show批量切換、路由切換帶動(dòng)畫的時(shí)候同一幀內(nèi)可能有幾十個(gè)元素同時(shí)走這套流程代價(jià)就上來(lái)了。v-show還有額外一層display: none和display: block的切換會(huì)直接讓布局失效切完再去讀尺寸就是一次完整重排。有些同學(xué)為了做折疊展開(kāi)動(dòng)畫用v-show配合讀取內(nèi)容高度在長(zhǎng)列表里滾動(dòng)著展開(kāi)卡頓感會(huì)非常明顯。2.4 第三方庫(kù)是重災(zāi)區(qū)而且你往往改不動(dòng)ECharts、Swiper、各類拖拽庫(kù)、虛擬表格、富文本編輯器這些庫(kù)的定位邏輯基本都建立在getBoundingClientRect()上。它們初始化的時(shí)候要量容器尺寸resize的時(shí)候要重新量彈出面板的時(shí)候要算位置。你沒(méi)法改它們的源碼只能從兩個(gè)方向下手控制調(diào)用時(shí)機(jī)和控制調(diào)用頻率。時(shí)機(jī)上別在mounted同步初始化一屏幾十個(gè)圖表讓它們?cè)趓equestAnimationFrame里排隊(duì)頻率上resize回調(diào)必須防抖而且防抖的落地方式最好是rAF節(jié)流加時(shí)間閾值不是簡(jiǎn)單的setTimeout。這部分在第 5 節(jié)會(huì)展開(kāi)寫具體代碼。3. 把這個(gè)警告釘?shù)骄唧w那一行代碼3.1 Performance 面板的正確讀法控制臺(tái)的 Violation 只告訴你發(fā)生了不告訴你在哪。真正定位得靠 Performance 面板。操作步驟是打開(kāi) DevTools切到 Performance點(diǎn)左上角的錄制按鈕然后在頁(yè)面上復(fù)現(xiàn)卡頓操作滾動(dòng)、拖拽、切換列表三五秒后停止錄制。拿到火焰圖之后看頂上那幾條橫軸色塊。紫色偏藍(lán)的是 Layout布局深紫偏紅的是 Recalculate Style。如果你看到一串密密麻麻的小紫色塊每個(gè)都很短但數(shù)量巨大中間還夾著黃色Scripting的小塊那就是典型的 layout thrashing——讀寫交替的指紋。如果是一個(gè)巨大的紫色塊那說(shuō)明是單次重排范圍太大方向就不一樣了該考慮的是減少布局波及面比如contain、content-visibility。再往下看切換到 Bottom-Up 或者 Call Tree 視圖按 Self Time 排序。通常在紫色塊下面能直接看到你的業(yè)務(wù)函數(shù)名點(diǎn)進(jìn)去就能定位到源碼行。如果看到的是一堆getBoundingClientRect、offsetHeight之類的原生調(diào)用展開(kāi)它的調(diào)用棧業(yè)務(wù)代碼一定在里面。3.2 用代碼給自己埋點(diǎn)抓出超時(shí)的那一次Performance 面板好用但它只能事后看而且信息量大、有學(xué)習(xí)成本。想快速定位我習(xí)慣直接給關(guān)鍵 API 打個(gè)補(bǔ)丁統(tǒng)計(jì)每次耗時(shí)和調(diào)用棧。這段代碼只在開(kāi)發(fā)環(huán)境加上線前刪掉或包在if (import.meta.env.DEV)里// dev-perf.js —— 只在開(kāi)發(fā)環(huán)境引入 if (import.meta.env.DEV) { const wrap (obj, name) { const raw obj[name] if (typeof raw ! function) return obj[name] function (...args) { const t0 performance.now() const result raw.apply(this, args) const cost performance.now() - t0 // 閾值可以調(diào)抓大放小 if (cost 5) { console.warn([slow ${name}] ${cost.toFixed(1)}ms, this) console.trace() } return result } } wrap(Element.prototype, getBoundingClientRect) wrap(Element.prototype, getClientRects) wrap(Range.prototype, getBoundingClientRect) // 幾何屬性是 getter用 defineProperty 包一層 const geometryProps [offsetWidth, offsetHeight, offsetTop, offsetLeft, clientWidth, clientHeight, scrollWidth, scrollHeight] geometryProps.forEach((prop) { const owner prop.startsWith(scroll) ? Element.prototype : HTMLElement.prototype const desc Object.getOwnPropertyDescriptor(owner, prop) if (!desc || !desc.get) return Object.defineProperty(owner, prop, { ...desc, get() { const t0 performance.now() const value desc.get.call(this) const cost performance.now() - t0 if (cost 5) { console.warn([slow read ${prop}] ${cost.toFixed(1)}ms, this) console.trace() } return value } }) }) }這里有個(gè)細(xì)節(jié)值得說(shuō)offsetWidth這類屬性是getter不是方法所以不能像getBoundingClientRect那樣直接替換函數(shù)得用Object.getOwnPropertyDescriptor拿到原始 getter 再包一層。另外注意scrollWidth掛在Element上offsetWidth掛在HTMLElement上掛錯(cuò)原型鏈會(huì)報(bào)錯(cuò)我上面做了個(gè)簡(jiǎn)單區(qū)分。埋點(diǎn)閾值別設(shè)太小5ms 以下的不看。跑一遍頁(yè)面控制臺(tái)會(huì)直接告訴你哪一行慢、調(diào)用棧是什么比在火焰圖里翻半天高效得多。3.3 一張現(xiàn)場(chǎng)排查清單真到了線上或者別人移交的項(xiàng)目里時(shí)間緊不可能慢慢打補(bǔ)丁。我整理了一張按現(xiàn)象反推原因的表先對(duì)號(hào)入座再動(dòng)手現(xiàn)場(chǎng)現(xiàn)象大概率原因第一步做什么拖拽/鼠標(biāo)跟隨明顯延遲mousemove里讀getBoundingClientRect并寫樣式把讀取挪到mousedown移動(dòng)過(guò)程只寫transform長(zhǎng)列表滾動(dòng)頓挫列表項(xiàng)內(nèi)讀offsetTop做吸附/瀑布流改用IntersectionObserver或緩存偏移量輸入框打字掉幀input事件里讀scrollHeight做高度自適應(yīng)用rAF節(jié)流 textarea的field-sizing或緩存彈層/下拉定位抖動(dòng)Popper 類庫(kù)在滾動(dòng)事件里持續(xù)測(cè)量限制resize/scroll觸發(fā)源或用 CSS 定位一屏圖表初始化時(shí)白屏卡住多個(gè)圖表mounted同步初始化爭(zhēng)搶主線程用rAF分批初始化配合骨架屏折疊展開(kāi)動(dòng)畫卡v-show切換后立刻讀內(nèi)容高度改v-if加緩存高度或用grid-template-rows動(dòng)畫窗口拉伸時(shí)整體卡頓resize回調(diào)沒(méi)防抖全量重排rAF節(jié)流只在幀內(nèi)算一次這張表覆蓋了八成左右的常見(jiàn)情況。如果你遇到的警告既不屬于拖拽也不屬于滾動(dòng)那大概率是某個(gè)第三方組件的初始化或resize用第 3.2 節(jié)的埋點(diǎn)腳本跑一遍最快。4. 核心解藥讀寫分離到底怎么做4.1 為什么讀寫分離能根治原理其實(shí)一句話把同一幀內(nèi)所有的讀集中在前半段所有的寫集中在后半段讀之前保證布局是干凈的寫之后不再去問(wèn)布局要數(shù)據(jù)。這樣一幀內(nèi)最多強(qiáng)制重排一次甚至零次如果讀的時(shí)候沒(méi)有臟布局。這套思路業(yè)界叫 fastdom名字來(lái)自 FastDOM 這個(gè)庫(kù)核心就是一個(gè)兩階段隊(duì)列measure放讀任務(wù)mutate放寫任務(wù)統(tǒng)一調(diào)度。自己實(shí)現(xiàn)一個(gè)簡(jiǎn)化版完全夠用五十行以內(nèi)。4.2 一個(gè)可以直接抄的調(diào)度器// scheduler.js const readQueue [] const writeQueue [] let rafId 0 let flushing false function flush() { rafId 0 flushing true // 第一階段集中讀此時(shí)布局應(yīng)當(dāng)是最新的 const reads readQueue.splice(0) for (let i 0; i reads.length; i) { try { reads[i]() } catch (e) { console.error(e) } } // 第二階段集中寫寫操作不會(huì)立刻觸發(fā)重排 const writes writeQueue.splice(0) for (let i 0; i writes.length; i) { try { writes[i]() } catch (e) { console.error(e) } } flushing false // 寫入過(guò)程中如果又產(chǎn)生了新的任務(wù)常見(jiàn)于寫里嵌套了讀排到下一幀 if (readQueue.length || writeQueue.length) schedule() } function schedule() { if (rafId) return rafId requestAnimationFrame(flush) } export function measure(fn) { readQueue.push(fn) // 關(guān)鍵如果當(dāng)前不在 flush 中說(shuō)明還沒(méi)到幀可以立即安排 // 如果正在寫階段追加讀任務(wù)絕不能同步執(zhí)行否則立刻退化成 thrashing schedule() } export function mutate(fn) { writeQueue.push(fn) if (!flushing) schedule() }有三個(gè)地方是我踩過(guò)坑之后特意加固的第一schedule用requestAnimationFrame而不是微任務(wù)。微任務(wù)在當(dāng)前宏任務(wù)結(jié)束時(shí)就跑了可能還在同一幀的 JS 階段里讀到的布局照樣要 flushrAF回調(diào)發(fā)生在瀏覽器決定要渲染這一幀的時(shí)刻此時(shí)上一輪寫入的樣式已經(jīng)被瀏覽器納入計(jì)算讀起來(lái)更干凈。第二用一個(gè)flushing標(biāo)志判斷當(dāng)前階段。如果mutate階段的函數(shù)里又調(diào)了measure絕對(duì)不能同步執(zhí)行那個(gè)讀否則你精心設(shè)計(jì)的讀寫分離當(dāng)場(chǎng)失效。我的做法是讓它在flush結(jié)束時(shí)檢測(cè)隊(duì)列非空重新排一幀。第三每個(gè)任務(wù)包try/catch。調(diào)度器是全局的一個(gè)任務(wù)拋錯(cuò)不能拖垮整批任務(wù)線上排查時(shí)這一點(diǎn)很關(guān)鍵。4.3 在 Vue 組件里怎么落地有了調(diào)度器業(yè)務(wù)代碼的改法就很機(jī)械了——把讀包進(jìn)measure把寫包進(jìn)mutate。但 Vue 里有幾個(gè)地方要注意。第一不要在measure回調(diào)里直接改響應(yīng)式狀態(tài)。改狀態(tài)會(huì)觸發(fā) Vue 的更新調(diào)度雖然它也是異步的但在這個(gè)上下文里容易讓數(shù)據(jù)流變得不可預(yù)測(cè)。清爽的做法是讀階段把結(jié)果收集到一個(gè)普通對(duì)象里寫階段再拿這些數(shù)據(jù)統(tǒng)一提交給 Vue。第二await nextTick()之后不要直接讀尺寸。正確的姿勢(shì)是import { nextTick } from vue import { measure, mutate } from ./scheduler async function syncLayout() { await nextTick() // 等 DOM 更新完 measure(() { // 再等一個(gè)渲染幀讀干凈布局 const items [...listRef.value.children] const heights items.map(el el.offsetHeight) // 連續(xù)讀只重排一次 mutate(() { items.forEach((el, i) { el.style.setProperty(--row-h, heights[i] px) // 連續(xù)寫 }) }) }) }注意這里讀和寫的順序先nextTick保證 DOM 存在再measure保證布局新鮮讀的時(shí)候用map一次性收集完不要在循環(huán)里寫然后mutate里批量寫。這套流程下來(lái)整個(gè)函數(shù)最多觸發(fā)一次強(qiáng)制重排。第三組件卸載時(shí)要清理。調(diào)度器是模塊級(jí)的如果組件卸載后隊(duì)列里還有引用著已銷毀 DOM 的回調(diào)讀的時(shí)候就會(huì)拿到null。我的處理是在回調(diào)里做空值判斷或者給任務(wù)加一個(gè)cancelled標(biāo)記在onUnmounted里置位。4.4 什么情況下不用調(diào)度器直接 rAF 就夠調(diào)度器解決的是多個(gè)模塊零散讀寫的問(wèn)題。如果你只有一個(gè)函數(shù)讀寫都在里面那直接requestAnimationFrame更輕let pending false let cachedRect null function onScroll() { if (!pending) { pending true requestAnimationFrame(() { pending false // 這里集中做讀寫注意讀必須放在寫前面 const top container.getBoundingClientRect().top sticky.style.transform top 0 ? translateY(${-top}px) : none }) } }這個(gè)模式叫rAF 節(jié)流本質(zhì)上是把一個(gè)高頻事件壓縮成每幀最多執(zhí)行一次。它在滾動(dòng)、拖拽、mousemove、resize場(chǎng)景里幾乎是萬(wàn)能的代碼量小、沒(méi)有依賴建議先把這個(gè)用起來(lái)再考慮上調(diào)度器。提示resize事件還有個(gè)更現(xiàn)代的替代品ResizeObserver。它比window上的resize精準(zhǔn)得多能觀察單個(gè)元素但要注意它的回調(diào)本身也是布局之后、繪制之前執(zhí)行回調(diào)里讀尺寸是安全的寫尺寸卻可能觸發(fā)循環(huán)。要寫就包一層rAF或者直接在回調(diào)里做防抖。5. 高頻場(chǎng)景逐個(gè)擊破5.1 拖拽把讀取挪到事件開(kāi)始那一刻拖拽是 Forced reflow 的頭號(hào)來(lái)源。壞的寫法幾乎人人寫過(guò)// 反面教材每一幀都在讀寫交替 function onMouseMove(e) { const rect box.getBoundingClientRect() // 讀強(qiáng)制重排 box.style.left rect.left e.movementX px // 寫布局臟了 box.style.top rect.top e.movementY px }每一次mousemove都是讀一次、寫一次而且讀的還是自己剛剛寫臟的元素重排跑不掉了。正確做法是把狀態(tài)存在變量里事件開(kāi)始時(shí)讀一次移動(dòng)過(guò)程純計(jì)算加寫const state { startX: 0, startY: 0, originLeft: 0, originTop: 0, moving: false, x: 0, y: 0 } let rafId 0 function onMouseDown(e) { const rect box.getBoundingClientRect() // 整個(gè)拖拽過(guò)程只讀這一次 state.startX e.clientX state.startY e.clientY state.originLeft rect.left state.originTop rect.top state.moving true document.addEventListener(mousemove, onMouseMove) } function onMouseMove(e) { if (!state.moving) return state.x state.originLeft (e.clientX - state.startX) state.y state.originTop (e.clientY - state.startY) if (!rafId) rafId requestAnimationFrame(paint) } function paint() { rafId 0 // 用 translate3d 而不是 left/top box.style.transform translate3d(${state.x}px, ${state.y}px, 0) }兩個(gè)改動(dòng)帶來(lái)兩個(gè)收益第一整個(gè)拖拽只強(qiáng)制重排一次第二用transform替代left/top元素在合成層上移動(dòng)連布局和繪制都省了只剩下合成流暢度是數(shù)量級(jí)的差別。這個(gè)技巧是我做拖拽交互時(shí)最常用的一招記住動(dòng)位置用 transform不動(dòng) left/top基本能躲掉一半的卡頓。5.2 長(zhǎng)列表與虛擬滾動(dòng)v-for渲染幾千條數(shù)據(jù)然后在某個(gè)方法里遍歷子元素讀offsetTop這是瀑布流和吸附滾動(dòng)的經(jīng)典寫法也是經(jīng)典的重排炸彈。改法有兩條路。輕量的一條是緩存加批量在列表數(shù)據(jù)變化之后用一個(gè)measure任務(wù)一次性把所有子元素的偏移量讀出來(lái)存到數(shù)組里之后滾動(dòng)過(guò)程中只查數(shù)組不碰 DOM。注意這個(gè)緩存要在容器尺寸變化時(shí)失效重建ResizeObserver是合適的鉤子。徹底的一條是上虛擬滾動(dòng)。虛擬滾動(dòng)的核心思想是只渲染視口內(nèi)的元素元素?cái)?shù)量從幾千降到幾十任何遍歷操作的代價(jià)都變得可以接受。如果要自己實(shí)現(xiàn)關(guān)鍵點(diǎn)是行高固定或提前測(cè)量、用絕對(duì)定位撐開(kāi)滾動(dòng)高度、滾動(dòng)事件用rAF節(jié)流。行高不固定的場(chǎng)景通常做法是先按估算行高渲染再用ResizeObserver或者measure任務(wù)逐個(gè)修正真實(shí)高度并回填緩存。對(duì)于大多數(shù)業(yè)務(wù)項(xiàng)目我建議直接用成熟庫(kù)而不是自己寫。選庫(kù)的時(shí)候看一眼它在滾動(dòng)過(guò)程中有沒(méi)有讀取getBoundingClientRect有的庫(kù)為了做滾動(dòng)到指定項(xiàng)會(huì)在每次滾動(dòng)時(shí)測(cè)量那就得配個(gè)節(jié)流。5.3 動(dòng)畫優(yōu)先動(dòng)不會(huì)觸發(fā)布局的屬性做動(dòng)畫有一條鐵律只動(dòng)transform和opacity其他屬性盡量別碰。原因是這兩個(gè)屬性在合成階段處理改它們不會(huì)引起樣式重算和布局重排而改width、height、margin、padding、top、left、font-size這些必然重排而且很可能牽連一大片。Vue 的Transition默認(rèn)用的是opacity和transform之外的類名切換所以自定義過(guò)渡的時(shí)候要自己寫對(duì)。常見(jiàn)的折疊展開(kāi)如果想平滑別用height: 0到height: autoauto沒(méi)法過(guò)渡而且會(huì)重排用grid-template-rows: 0fr到1fr或者transform: scaleY加transform-origin。前者是純粹的小技巧兼容性不錯(cuò)。如果用 Vue 的 JS 鉤子做動(dòng)畫before-enter、enter這類記得每次在enter回調(diào)里做一次el.offsetHeight強(qiáng)制重排來(lái)激活過(guò)渡這是標(biāo)準(zhǔn)做法但別在循環(huán)里對(duì)幾十個(gè)元素同時(shí)做。批量過(guò)渡的場(chǎng)景我通常改成 CSS 類切換加transition-delay錯(cuò)開(kāi)讓瀏覽器自己安排。5.4 第三方庫(kù)控時(shí)機(jī)、控頻率、控范圍第三方庫(kù)有三個(gè)可下手的地方。控時(shí)機(jī)指不要在mounted里同步初始化。一屏十個(gè)圖表每個(gè)初始化都要量容器、算布局堆在一起就是幾百毫秒。把它們?nèi)M(jìn)rAF或者用IntersectionObserver做進(jìn)視口才初始化onMounted(() { const io new IntersectionObserver((entries) { entries.forEach((entry) { if (!entry.isIntersecting) return io.unobserve(entry.target) requestAnimationFrame(() initChart(entry.target)) }) }, { rootMargin: 200px }) chartEls.value.forEach(el io.observe(el)) })rootMargin: 200px是提前量用戶還沒(méi)滾到就初始化完了體驗(yàn)更順?？仡l率指給庫(kù)的resize、scroll回調(diào)加節(jié)流。很多庫(kù)自己不做這件事。如果它的 API 允許傳回調(diào)就在外面包一層rAF節(jié)流如果它是監(jiān)聽(tīng)window.resize的可以自己在初始化前先把尺寸算好傳進(jìn)去減少它內(nèi)部測(cè)量的次數(shù)?？胤秶赣?CSS 限制布局的波及面下一節(jié)講。5.5 CSS 側(cè)的兩個(gè)低成本優(yōu)化contain屬性可以讓瀏覽器知道這個(gè)元素的內(nèi)部布局不影響外部從而把重排范圍鎖在局部。常用值是contain: layout paint布局和繪制都不外溢列表項(xiàng)、卡片、彈層都很適合加。加了之后改動(dòng)內(nèi)部的尺寸不會(huì)引起整個(gè)頁(yè)面的布局重算收益非常直接。content-visibility: auto更進(jìn)一步讓屏幕外元素的渲染被跳過(guò)。長(zhǎng)文檔、長(zhǎng)列表里效果明顯但要配contain-intrinsic-size給它一個(gè)占位尺寸否則滾動(dòng)條會(huì)跳。這兩個(gè)屬性現(xiàn)代瀏覽器都支持得不錯(cuò)屬于加一行、收益立竿見(jiàn)影的類型。還有will-change: transform很多人拿它當(dāng)萬(wàn)金油到處加。它的作用是提前把元素提升為獨(dú)立合成層減少動(dòng)畫過(guò)程中的重排和重繪。但別濫用——每個(gè)合成層都要占顯存幾十上百個(gè)層會(huì)把內(nèi)存吃光反而更卡。我的習(xí)慣是只在確實(shí)要做高頻動(dòng)畫的元素上加動(dòng)畫結(jié)束就移除。6. 常見(jiàn)問(wèn)題與避坑速查6.1 問(wèn)題速查表問(wèn)題原因解決nextTick之后讀尺寸仍報(bào)警告nextTick是微任務(wù)不等渲染幀讀操作包進(jìn)rAF或調(diào)度器單個(gè)元素動(dòng)畫也報(bào)警告動(dòng)畫屬性觸發(fā)了布局width/height/top改用transform/opacity只在低端機(jī)上卡高端機(jī)重排耗時(shí)低低于閾值不報(bào)用 Performance 面板看別依賴控制臺(tái)加了will-change反而更卡合成層數(shù)量過(guò)多占顯存只在動(dòng)畫期間加結(jié)束后移除resize里代碼很少也卡沒(méi)節(jié)流一次拉伸觸發(fā)幾十次用rAF節(jié)流并加最小間隔生產(chǎn)環(huán)境沒(méi)有警告Violation 只在 DevTools 打開(kāi)時(shí)采集生產(chǎn)排查靠 Performance 性能指標(biāo)組件卸載后報(bào)錯(cuò)調(diào)度隊(duì)列里的回調(diào)引用了已銷毀 DOM回調(diào)內(nèi)判空或加取消標(biāo)記列表用index做 key 更卡復(fù)用錯(cuò)位導(dǎo)致大量 DOM 重建用穩(wěn)定的業(yè)務(wù) id 做 key6.2 幾個(gè)容易搞反的細(xì)節(jié)第一個(gè)反直覺(jué)的點(diǎn)getComputedStyle讀color、font-weight這類純繪制屬性通常不會(huì)觸發(fā)重排但讀width、height、margin這些布局屬性一定觸發(fā)。所以別一看到getComputedStyle就緊張看你讀的是哪個(gè)屬性。第二個(gè)scrollTop的讀取是重排的來(lái)源之一但對(duì)滾動(dòng)容器來(lái)說(shuō)它更常見(jiàn)的坑是讀scrollHeight算總高。這個(gè)屬性依賴全部子元素布局代價(jià)很高能緩存就緩存。第三個(gè)v-if和v-show在這件事上的表現(xiàn)不同。v-if是增刪節(jié)點(diǎn)插入新節(jié)點(diǎn)必然讓布局臟掉v-show是切換display同樣讓布局臟掉。兩者都不省區(qū)別在渲染成本和狀態(tài)保持上別指望用v-show能繞開(kāi)重排。第四個(gè)offsetTop是相對(duì)于offsetParent的不是相對(duì)于視口。很多同學(xué)算錯(cuò)位置是因?yàn)闆](méi)注意offsetParent會(huì)被position: relative的祖先改變。算視口坐標(biāo)老老實(shí)實(shí)用getBoundingClientRect。6.3 我在實(shí)際項(xiàng)目里踩過(guò)的坑第一個(gè)坑是埋點(diǎn)本身拖慢了頁(yè)面。有一段時(shí)間我在Element.prototype上包了好幾層補(bǔ)丁本地跑得好好的一上真機(jī)開(kāi)發(fā)包就卡成幻燈片。原因是補(bǔ)丁里的performance.now()和console.trace()本身開(kāi)銷就不小console.trace()尤其重在mousemove高頻場(chǎng)景里直接拖垮主線程。后來(lái)我改成只在超過(guò)閾值且做了采樣比如每 20 次記錄一次的情況下才打日志問(wèn)題就沒(méi)了。第二個(gè)坑是調(diào)度器里的死循環(huán)。我最初的版本在flush結(jié)束時(shí)無(wú)條件重新schedule()結(jié)果一個(gè)任務(wù)里不斷往隊(duì)列里塞新任務(wù)把rAF變成了忙循環(huán)頁(yè)面反而更卡。后來(lái)加了單幀最多迭代兩次的限制超出的任務(wù)順著排到下一幀才穩(wěn)下來(lái)。第三個(gè)坑是以為transform是萬(wàn)能藥。transform確實(shí)不觸發(fā)布局但如果它作用的元素上有一個(gè)filter或者復(fù)雜的box-shadow照樣會(huì)觸發(fā)重繪代價(jià)并不低。還有transform會(huì)影響position: fixed子元素的定位基準(zhǔn)做全屏遮罩的時(shí)候要特別注意。第四個(gè)坑比較隱蔽document.body上的 class 切換會(huì)引發(fā)全頁(yè)重排。項(xiàng)目里做主題切換、字號(hào)切換的時(shí)候我在body上切了個(gè) class里面包含font-size變量結(jié)果整頁(yè)所有文本重新?lián)Q行一次重排上百毫秒。后來(lái)改成用 CSS 變量配合contain把影響限制在主要內(nèi)容區(qū)才把這一下優(yōu)化掉。說(shuō)到底Forced reflow 這條警告的價(jià)值不在于它本身而在于它是一個(gè)信號(hào)——它告訴你你的代碼正在用一種命令式、逐步確認(rèn)的方式跟瀏覽器打交道而瀏覽器更希望你一次說(shuō)清楚。把讀和寫分開(kāi)、把動(dòng)位置交給transform、把高頻事件壓到每幀一次這三件事做到位控制臺(tái)里那串紅色的[Violation]基本就會(huì)消失頁(yè)面手感也會(huì)跟著變一個(gè)檔次。