提起拼多多，大家想到的都是 “性價比商品” ，但是在 IT 互聯(lián)網(wǎng)大廠里面，拼多多可是 “扛把子” 級別的存在。

根據(jù) 25 屆校招的薪資來看，拼多多給出的校招薪資為：

• 普通檔（白菜）： 27K ~ 30K，18薪，年包大約在 48萬 ~ 54萬
• 中檔（SP）： 30K ~ 34K，18薪，年包大約在 54萬 ~ 61萬
• 高檔（SSP）： 35K ~ 40K，18薪，年包大約在 63萬 ~ 72萬

這薪資，是不是都超過了很多工作經(jīng)驗超過 10 年的老開發(fā)了。

那么咱們這次就來看看一位 訓練營同學 的拼多多一面，大家覺得難度如何呢？

圖片

接下來，咱們跳幾個比較有代表性的問題，來看下......

前端如何捕獲到頁面卡頓，比如死循環(huán)

頁面卡頓通常是由于 長時間的 JavaScript 執(zhí)行、阻塞主線程 或 過多的渲染操作 導致的。為了捕獲和檢測頁面卡頓，尤其是 死循環(huán) 或 性能瓶頸，可以參考以下幾種方式

1. 使用瀏覽器的性能監(jiān)控工具

Chrome DevTools Performance 面板

圖片

Chrome DevTools 提供了 Performance 面板，可以幫助我們檢查頁面的執(zhí)行情況、渲染進程以及資源加載情況。

• 如何使用：

打開 Chrome 開發(fā)者工具（F12 或 Ctrl+Shift+I），選擇 Performance 面板。

點擊 Record 按鈕開始錄制性能數(shù)據(jù)。

在錄制過程中，模擬頁面的交互（例如點擊、滾動、輸入等），然后停止錄制。

分析錄制的結(jié)果，查看是否有長時間的 JavaScript 執(zhí)行或頁面渲染阻塞，尤其關注 Script、Rendering 和 Long Tasks。

• 分析卡頓原因：

     如果發(fā)現(xiàn) Scripting 部分有過長的時間，說明 JavaScript 執(zhí)行可能存在性能問題。

     如果頁面渲染部分（Rendering）或者合成部分（Compositing）有較長的時間，說明渲染過程存在問題。

Chrome DevTools 的 Long Tasks

Chrome DevTools 還可以顯示 長任務（Long Tasks），這些任務會阻塞主線程并導致頁面卡頓。

• 如何使用：

在 Performance 面板中，查看 Long Tasks。長任務的定義是執(zhí)行時間超過 50ms 的 JavaScript 任務。

檢查長任務的調(diào)用棧，找出是哪段代碼導致的阻塞。

2. 使用 requestIdleCallback 和 Performance

requestIdleCallback

requestIdleCallback 是一個瀏覽器 API，用于在主線程空閑時執(zhí)行一些非緊急的操作。可以通過它來分解和異步執(zhí)行一些較為耗時的操作，從而避免主線程被阻塞，導致頁面卡頓。

requestIdleCallback(function(deadline) {
  while (deadline.timeRemaining() > 0) {
    // 執(zhí)行耗時操作
  }
}, { timeout: 1000 });

• 捕獲頁面卡頓：如果 requestIdleCallback 不能在規(guī)定時間內(nèi)完成任務，那么可能存在主線程被長時間占用的情況。你可以結(jié)合 performance.now() 或 Date.now() 來記錄每個任務的執(zhí)行時長，幫助判斷頁面是否卡頓。

Performance API

Performance API 提供了一些方法來檢查頁面性能，包括捕獲頁面加載的時間、各個階段的耗時，以及是否存在長時間的腳本執(zhí)行等。

if (performance.now() > 50) {
  console.warn('可能存在性能問題，主線程被阻塞');
}

• performance.now() 返回當前時間（相對頁面加載時間），如果發(fā)現(xiàn)時間超出了預期，可以判斷是否有耗時操作導致頁面卡頓。

React19的樂觀更新hook如何使用的

樂觀更新是一種在異步操作（如 API 請求）尚未完成時，先假設操作成功并立即更新 UI，以提供更流暢的用戶體驗的技術。如果后續(xù)操作失敗，再回滾 UI 狀態(tài)。

在 React 19 中，引入了新的 useOptimistic Hook 來簡化樂觀更新（Optimistic Updates）的實現(xiàn)。核心邏輯仍然是：先更新 UI → 提交操作 → 成功則保持，失敗則回滾。

圖片

基本使用步驟

1. 引入 Hook

import { useOptimistic } from 'react';

2. 初始化狀態(tài)

const [optimisticState, addOptimistic] = useOptimistic(
  currentState,      // 當前實際狀態(tài)
  (state, newValue) => {  // 更新函數(shù)：合并當前狀態(tài)和樂觀值
    return [...state, { ...newValue, status: 'pending' }];
  }
);

• optimisticState: 合并后的樂觀狀態(tài)（會立即反映到 UI）。
• addOptimistic: 觸發(fā)樂觀更新的函數(shù)。

3. 在異步操作中使用

async function handleSubmit(newItem) {
  // 1. 觸發(fā)樂觀更新
  addOptimistic(newItem);

  try {
    // 2. 執(zhí)行實際異步操作（如 API 請求）
    await postDataToServer(newItem);
    // 3. 如果成功，React 會自動同步最新狀態(tài)
  } catch (error) {
    // 4. 如果失敗，需手動回滾（或提示錯誤）
    alert("操作失敗，請重試");
  }
}

lena模型中的低優(yōu)先級和高優(yōu)先級分別是什么？

在 Lena 模型中，"低優(yōu)先級" 和 "高優(yōu)先級" 是用于描述任務調(diào)度中的不同優(yōu)先級類型的術語。

具體來說，Lena 模型是用于調(diào)度和優(yōu)化任務執(zhí)行的理論模型，在 React 等現(xiàn)代框架中，我們可以用它來更好地理解和實現(xiàn) 時間分片（Time Slicing） 和 并發(fā)渲染（Concurrent Rendering） 的機制。

在 React 中，這些優(yōu)先級概念通常用于決定哪些任務應當盡早處理，哪些可以延遲，確保 UI 保持流暢和響應迅速

高優(yōu)先級任務（High-priority tasks）

高優(yōu)先級任務是指那些對于用戶交互和應用性能至關重要的任務。這些任務需要在最短的時間內(nèi)完成，以保證用戶界面的流暢性和響應性，比如：

• 用戶輸入：如按鍵、鼠標點擊等用戶交互。
• 動畫和過渡：UI 動畫需要盡可能在下一幀渲染前完成，以保證動畫流暢。
• 更新交互狀態(tài)：例如按鈕點擊后更新按鈕狀態(tài)。
• 響應性要求較高的事件：例如滾動或拖拽等交互操作。

高優(yōu)先級任務的處理會被推送到主線程的最前面，確保這些任務能及時完成，以響應用戶的即時操作。

低優(yōu)先級任務（Low-priority tasks）

低優(yōu)先級任務是那些對于用戶體驗來說不是非常緊急的任務。即使它們沒有在短期內(nèi)完成，也不會對用戶的感知造成明顯影響，比如：

• 后臺數(shù)據(jù)請求：例如發(fā)送一個數(shù)據(jù)提交請求或者獲取遠程數(shù)據(jù)。
• 延遲渲染：例如在滾動到頁面的某個位置時才加載該部分內(nèi)容，或者實現(xiàn)懶加載。
• 非緊急的 UI 更新：例如某些信息的更新不直接影響用戶的當前操作。
• 長時間執(zhí)行的任務：例如長列表的渲染或復雜的計算操作。

這些低優(yōu)先級任務通常會被安排在瀏覽器的空閑時間執(zhí)行，避免阻塞主線程和影響用戶操作。

React 中的時間分片和優(yōu)先級調(diào)度

在 React 中，并發(fā)模式（Concurrent Mode）引入了任務優(yōu)先級的概念，能夠根據(jù)任務的緊急程度（優(yōu)先級）來動態(tài)調(diào)度任務。React 使用 時間分片 來將高優(yōu)先級任務提前執(zhí)行，并且將低優(yōu)先級任務推遲，直到系統(tǒng)空閑。

• 高優(yōu)先級任務：通常是用戶交互或需要立刻渲染的任務（如點擊按鈕、滾動、輸入框輸入等）。React 會在用戶操作時立即處理這些任務，保證 UI 的即時響應。
• 低優(yōu)先級任務：是那些后臺數(shù)據(jù)請求或非急需更新的任務。React 會在系統(tǒng)空閑時繼續(xù)執(zhí)行這些低優(yōu)先級任務，避免阻塞重要的交互任務。