拼多多一面，直接拿捏...
提起拼多多，大家想到的都是 “性價比商品” ，但是在 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)先級任務，避免阻塞重要的交互任務。
