題幹與適用情境
一個儀表板渲染 300 張卡片。捲動或調整視窗大小時，處理函式會讀取每張卡片的邊界框，修改寬度與位置，接著再讀取高度。介面明顯卡頓，Chrome Performance 錄製顯示處理函式內反覆出現紫色 Layout 事件與 forced reflow 警告。
請解釋瀏覽器的 JavaScript → 樣式計算 → 版面配置 → 繪製 → 合成流水線，證明這段程式碼是否造成 Layout Thrashing，在不使用過期幾何資料的前提下重構，並制定驗證方案。卡片數量與 trace 症狀都是面試假設，不來自真實產品。
這是前端效能診斷題，核心能力是把失效狀態、同步幾何讀取、trace 證據與安全修復連成因果鏈。它比 Core Web Vitals 全面診斷更聚焦，也不同於「輸入 URL 後發生什麼」這類網路與首次渲染流程題。
面試官考察點
第一，候選人能否區分「標記失效」與「立即執行」。DOM 或樣式寫入可能先把樣式或版面配置標記為髒，而不立刻重算。後續必須回傳目前幾何資訊的 API，可能迫使瀏覽器同步刷新待處理的樣式與版面配置。
第二，能否把抖動解釋成依賴順序，而不是背誦「慢屬性」。一次寫入後確實需要一次讀取，可能完全合理。真正有害的是在許多元素或連續影格中反覆出現「寫入 → 依賴版面配置的讀取 → 再寫入」，讓瀏覽器無法合併工作。
第三，能否先診斷再最佳化。強回答會錄製真實互動，查看 Layout 事件的發起者與呼叫堆疊，比較腳本、樣式、版面配置與繪製耗時，並確認可疑處理函式位於因果路徑。看到紫色長條不代表所有版面配置都能避免。
第四，能否保護正確性。只有所有測量都描述同一個更新前狀態時，才能把讀取全部提前。如果一次寫入刻意改變下一次讀取所需的幾何資訊，就必須調整演算法或資料模型；盲目快取只會得到更快但錯誤的版面。
最後，能否依依賴關係選擇讀寫分批、requestAnimationFrame、觀察器、CSS 版面配置、containment 或只需合成的屬性。requestAnimationFrame 只改變時機，不會讓昂貴工作消失；will-change 也不是版面配置問題的通用修復。
回答前需要釐清的問題
- 哪個互動很慢？ 捲動、調整視窗大小、首次渲染、拖曳與一次性展開有不同預算及排程方案。本題基線是持續捲動和縮放。
- 具體有哪些讀寫？
getBoundingClientRect()、offsetWidth、offsetHeight屬於幾何讀取；寫入可能修改 class、行內樣式、內容或 DOM 結構。順序比 API 名稱本身更重要。 - 一張卡片的新尺寸是否決定下一張卡片的測量？ 若不決定，通常可以從同一個穩定狀態讀取全部測量；若決定，簡單分批會破壞順序依賴。
- 能否讓 CSS 管理版面？ Grid、flexbox、容器查詢與固有尺寸可以完全刪除 JavaScript 測量，通常比最佳化測量迴圈更可靠。
- 還有誰會修改輸入？ 框架 commit、圖片、字型、第三方元件或觀察器可能在兩個階段間使版面失效。修復需要單一擁有者或明確排程協定。
- 哪些視覺行為必須保持？ 改實作前先定義卡片位置、尺寸、焦點行為、捲動錨定與響應式結果。
- 目標環境是什麼？ 要在受影響的視窗與裝置級別重現。高效能開發機可能掩蓋受限 CPU 上的重複版面配置。
30 秒回答框架
「我會先錄製固定的捲動或縮放互動，選取重複的 Layout 事件，透過發起者與呼叫堆疊定位程式碼。樣式寫入會讓幾何資訊失效，後續 getBoundingClientRect() 或 offsetHeight 必須回傳目前值，因此可能同步刷新樣式與版面配置；對 300 張卡片反覆執行就是 Layout Thrashing。如果所有卡片都能使用更新前的同一狀態，我會先讀取全部幾何資訊，在記憶體中計算，再於下一次視覺更新集中寫入。如果 JavaScript 輪詢沒有必要，我會優先使用 CSS 版面配置或觀察器。最後重播同一組確定性操作，比較版面配置次數、耗時、長影格與視覺正確性。只加 requestAnimationFrame 無法消除重複工作。」
分步深入解答
第一步：建立因果模型
一個影格可能包含 JavaScript、樣式計算、版面配置、繪製與合成。版面配置負責計算盒子幾何資訊。改變幾何的寫入會讓部分資訊過期，瀏覽器通常延後重算，以便一次處理多項修改。
同步幾何讀取會改變這個安排。為了回傳準確的目前值，瀏覽器可能必須立即套用待處理樣式並執行版面配置。再次寫入後，下一個讀取又可能強制版面配置。對 300 張卡片交錯執行時，一個處理函式內可能產生大量局部或整頁重算。
可重用規則是：從一個已知視覺狀態集中讀取，在不存取 DOM 的情況下計算，再集中寫入下一個狀態。這是依賴規則，並不代表每次讀取或寫入都昂貴。
第二步：證明處理函式是原因
圍繞確定性操作錄製 Performance：固定卡片資料、視窗、捲動距離或縮放序列，以及 CPU 條件。檢查 Frames 與 Main 軌道，選取長 Layout 事件，透過發起者或呼叫堆疊回到應用程式碼，統計一次處理函式內的版面配置次數與總耗時。
若 trace 很擁擠，可以暫時在處理函式前後加 performance mark。Paint flashing 與 layer borders 只能作為輔助證據：它們顯示重繪區域與圖層，而 Performance trace 才能把強制版面配置連到程式碼。同時記錄腳本與繪製耗時；若真正瓶頸是計算或大面積重繪，刪除版面配置也無法完全修好。
建立對照：只關閉可疑讀寫迴圈，保留相同資料與互動。如果重複 Layout 事件和長影格明顯減少，因果證據更強。如果仍然存在，就繼續檢查框架 commit、圖片尺寸、字型與第三方程式碼，不能強行套用預設結論。
第三步：把獨立測量重構成多個階段
原始處理函式交錯讀寫：
function positionCards(container, cards, columns) {
let top = 0;
for (const card of cards) {
const width = container.getBoundingClientRect().width / columns;
card.style.width = `${Math.floor(width)}px`;
const height = card.offsetHeight;
card.style.transform = `translateY(${top}px)`;
top += height;
}
}這裡每張卡片的高度確實依賴新寬度，永久快取舊高度會得到錯誤結果。應拆成兩個穩定視覺狀態，而不是 300 次交錯狀態：
function positionCards(container, cards, columns) {
const width = Math.floor(container.getBoundingClientRect().width / columns);
for (const card of cards) {
card.style.width = `${width}px`;
}
requestAnimationFrame(() => {
const heights = cards.map((card) => card.offsetHeight);
let top = 0;
cards.forEach((card, index) => {
card.style.transform = `translateY(${top}px)`;
top += heights[index];
});
});
}第一次讀取觀察修改寬度前的容器，所有寬度寫入集中完成。第一次讀取高度時可能為新寬度執行一次必要版面配置，後續高度讀取重用這個穩定的更新後幾何狀態；接著集中寫 transform，不再讀取幾何。動畫影格回呼用於協調第二階段，但收益來自把數百次交錯依賴縮減為兩個明確狀態，不來自回呼名稱。
合併 scroll 與 resize 通知，保證每個影格最多存在一個待處理更新。如果每個事件都排入新回呼，只是把積壓搬到別處。保存最新輸入，只排程一次，並在回呼執行時清除 pending 標記。
第四步：處理真實的順序依賴
如果寫入卡片 A 會刻意改變卡片 B 必須讀取的幾何資訊，簡單分批就不正確。要明確說出這個約束。可以在記憶體模型中用累計值推導全部位置，讓 CSS Grid 或 flexbox 管理流式版面，只測量容器而非每個子項，或改為僅依賴上一影格已 commit 的狀態。
內容尺寸非同步變化時，ResizeObserver 可以回報尺寸改變，避免在每次捲動中輪詢。它的回呼仍需防止回饋迴圈：依收到的 observation 計算並集中寫入，不能在沒有收斂規則時反覆修改同一個被觀察盒子的尺寸。
當元件邊界確實獨立時，CSS containment 可縮小版面配置或繪製失效的傳播範圍。它也可能改變固有尺寸、溢出和 containing block 行為，因此必須驗證視覺與無障礙結果。縮小失效範圍能降低單次成本，不能為反覆強制版面配置開脫。
第五步：只有語意允許時才選擇更便宜的視覺變化
修改 width 或 top 等幾何屬性通常需要版面配置、繪製與合成；修改 transform 或 opacity 有時可以略過版面配置與繪製，只進入合成。如果視覺移動不需改變文件流，可以使用這條路徑。
如果相鄰元素、點擊區域、文字換行或無障礙幾何資訊必須反映新尺寸，就不能把真實寬度修改替換成 scale transform。過度提升圖層也會消耗記憶體。先確認版面語意，再選擇成本最低的正確流水線路徑。
第六步：同時驗證效能與正確性
改動前後重播完全相同的輸入，比較每次互動的 Layout 事件數量與總耗時、指向處理函式的 forced reflow 警告、長影格、腳本時間、繪製面積與掉幀。記錄 trace 設定，讓其他工程師能重現。
驗證卡片邊界、換行、焦點順序、點擊區域、捲動位置、縮放、動態字型與圖片，以及多個視窗尺寸。測試快速事件突發與首次渲染後的內容變化。版面配置次數下降但卡片重疊或鍵盤焦點跳動，仍然失敗。
不要承諾通用數字。裝置更新率與負載不同，單次本機影格率不能代表正式環境。發布標準應是：同一工作負載下，重複強制版面配置顯著減少，沒有新的主導瓶頸，並在代表性裝置上保持使用者可見行為。
高品質示範回答
「我會用相同的 300 張卡片與固定縮放序列重現並錄製 Performance。接著選取重複 Layout 事件，透過發起者與呼叫堆疊確認處理函式先寫入幾何樣式，再呼叫 getBoundingClientRect() 或 offsetHeight，使瀏覽器無法合併版面配置。這個交錯因果模式才叫 Layout Thrashing，只有紫色長條還不足以下結論。
接著我會判斷所有卡片能否從更新前版面統一計算。如果可以，就先讀取全部邊界，在普通資料中計算下一組樣式，再集中寫入；scroll 和 resize 只保留一個待處理視覺更新。requestAnimationFrame 有助於安排寫入時機，但不能單獨修復交錯讀寫。如果測量只是在補償一般流式版面，我會優先用 CSS Grid；如果尺寸在渲染後獨立改變，則考慮 ResizeObserver 並防止回饋迴圈。
如果卡片 B 確實依賴卡片 A 寫入後的尺寸，我不會快取舊值後宣稱完成。我會從累計模型推導位置，或讓版面引擎接管依賴。只有移動不需影響文件流時，我才會使用 transform。
最後，我會重播同一錄製，比較版面配置次數與耗時、forced reflow 呼叫堆疊、長影格、腳本與繪製，同時驗證邊界、換行、焦點、捲動錨定、縮放和延遲內容。成功代表重複強制版面配置消失或顯著縮短，而且沒有過期測量或新的繪製瓶頸。」
常見錯誤
- 把每個 Layout 事件都稱為抖動 → 幾何改變本來就需要版面配置 → 證明交錯依賴造成重複同步刷新。
- 只在原迴圈外包一層
requestAnimationFrame→ 回呼內仍交錯讀寫 → 先拆分讀取、計算與寫入階段。 - 永久快取所有測量 → 字型、內容、縮放與視窗會讓資料過期 → 定義失效輸入或使用合適的觀察器。
- 用
will-change修復 → 圖層提示不能刪除幾何依賴，還會消耗資源 → 先修資料流，只提升確有必要的視覺效果。 - 盲目用 transform scale 取代寬度 → 文件流、文字、hit testing 或畫面可能錯誤 → 只在語意允許時使用合成友善屬性。
- 沒有 trace 就開始最佳化 → 真正昂貴的可能是其他腳本或繪製 → 錄製互動並沿事件發起者定位程式碼。
- 只看平均 FPS → 平均值會隱藏長影格，也無法解釋原因 → 對同一負載比較版面配置次數、耗時、呼叫堆疊與影格間隙。
- 忽略視覺正確性 → 過期幾何資料會讓 trace 看起來更快 → 重構後測試版面、焦點、捲動、縮放與非同步內容。
追問及應對
追問一：requestAnimationFrame 能阻止強制同步版面配置嗎？
不能。它只把回呼安排在未來某次繪製前。如果回呼內仍交錯執行幾何寫入與依賴版面配置的讀取，照樣會觸發多次同步版面配置並延遲該影格。應先修正依賴順序，再用它協調集中寫入或動畫步驟。
追問二：什麼時候一次強制版面配置可以接受？
當程式確實需要目前幾何資訊，而且工作量有邊界時，例如新彈出內容開啟後只測量一次再定位。應一次讀完必要資料，避免在迴圈裡重複刷新，並在代表性裝置上驗證成本。「強制」描述執行時機，不會自動等於缺陷。
追問三：ResizeObserver 會消除版面配置工作嗎？
不會。瀏覽器仍需執行版面配置才能知道尺寸改變。觀察器減少手動輪詢，並在規定階段交付結果，從而改善應用資料流；若回呼反覆寫入尺寸並觸發新 observation，仍可能形成回饋迴圈。
追問四：版面配置次數下降後動畫仍然很慢怎麼辦？
比較新的 trace。瓶頸可能轉為腳本計算、大面積繪製、互動期間的圖片解碼或過多合成圖層。繼續最佳化新的實測瓶頸；版面配置已不能解釋長影格時，不應繼續圍繞它做無效調整。
追問五：在元件框架中如何測試？
在 trace 中標記框架 commit 與測量 effect，確認應用是否在框架 DOM 寫入後讀取版面。測量仍放在正確性所需的生命週期階段，但必須有邊界並分離階段。測試重複掛載、狀態更新、延遲內容與開發模式特有行為，再判斷正式環境成本是否來自框架本身。