2025年高頻互聯(lián)網(wǎng)前端面試題及答案React中Hooks的依賴數(shù)組是如何實(shí)現(xiàn)依賴追蹤的？Hooks的依賴數(shù)組實(shí)現(xiàn)依賴于閉包和React的狀態(tài)管理機(jī)制。以u(píng)seEffect為例，當(dāng)組件渲染時(shí)，React會(huì)為當(dāng)前執(zhí)行的useEffect提供一個(gè)依賴數(shù)組的快照。在組件更新時(shí)，React會(huì)比較新渲染周期中useEffect的依賴數(shù)組與上一次的快照：如果所有依賴項(xiàng)的引用或值都未變化（通過Object.is比較），則跳過副作用函數(shù)的執(zhí)行。這種機(jī)制的關(guān)鍵在于，每個(gè)Hooks在組件渲染時(shí)按順序被記錄在組件實(shí)例的memoizedState鏈表中，依賴數(shù)組作為鏈表節(jié)點(diǎn)的一部分被存儲(chǔ)。需要注意的是，依賴數(shù)組中若遺漏必要狀態(tài)會(huì)導(dǎo)致閉包捕獲舊值，而包含過多無關(guān)依賴則可能導(dǎo)致副作用頻繁執(zhí)行。實(shí)際開發(fā)中，推薦使用eslint-plugin-react-hooks的exhaustive-deps規(guī)則自動(dòng)檢測(cè)依賴完整性。Vue3組合式API相比選項(xiàng)式API有哪些設(shè)計(jì)優(yōu)勢(shì)？組合式API（CompositionAPI）通過setup函數(shù)和邏輯組合（如自定義hook）解決了選項(xiàng)式API（OptionsAPI）在復(fù)雜組件中邏輯分散的問題。選項(xiàng)式API將數(shù)據(jù)（data）、方法（methods）、生命周期（mounted等）按類型拆分，當(dāng)組件涉及多個(gè)獨(dú)立邏輯（如表單驗(yàn)證、數(shù)據(jù)請(qǐng)求、用戶交互）時(shí)，相同邏輯的代碼會(huì)散落在不同選項(xiàng)中，導(dǎo)致可維護(hù)性下降。組合式API允許開發(fā)者按邏輯功能組織代碼，例如將數(shù)據(jù)請(qǐng)求和加載狀態(tài)封裝為useFetch函數(shù)，在setup中引入后直接暴露響應(yīng)式變量和方法。此外，組合式API通過響應(yīng)式系統(tǒng)（ref/reactive）顯式管理狀態(tài)，避免了選項(xiàng)式API中this指向的隱式依賴問題，更利于TypeScript類型推導(dǎo)和TreeShaking（未使用的組合邏輯可被構(gòu)建工具移除）。Vite相比Webpack在開發(fā)階段的性能優(yōu)化核心是什么？Vite的開發(fā)服務(wù)器性能優(yōu)勢(shì)主要源于“按需編譯”和“原生ES模塊支持”兩大策略。傳統(tǒng)打包工具（如Webpack）在啟動(dòng)時(shí)需要對(duì)整個(gè)項(xiàng)目進(jìn)行完整編譯，提供bundle文件，這在大型項(xiàng)目中耗時(shí)較長。Vite利用現(xiàn)代瀏覽器對(duì)ES模塊（ESModules）的原生支持，開發(fā)階段不打包代碼，而是直接通過HTTP服務(wù)器按模塊加載請(qǐng)求。當(dāng)瀏覽器請(qǐng)求某個(gè)模塊時(shí)，Vite才通過esbuild（Go語言編寫，速度是傳統(tǒng)JS打包工具的10-100倍）對(duì)該模塊進(jìn)行實(shí)時(shí)編譯（僅處理當(dāng)前請(qǐng)求的模塊及其依賴），并通過HTTP頭（如Cache-Control）緩存已編譯模塊，減少重復(fù)計(jì)算。此外，Vite的HMR（熱更新）基于ESM的模塊依賴圖，僅需更新修改的模塊及其直接依賴，無需重新加載整個(gè)應(yīng)用，實(shí)現(xiàn)毫秒級(jí)更新。如何解決React中長列表渲染的性能問題？React長列表性能優(yōu)化需結(jié)合虛擬滾動(dòng)（VirtualScrolling）、數(shù)據(jù)分片（Chunking）和組件優(yōu)化三方面。虛擬滾動(dòng)的核心是僅渲染視口內(nèi)可見的列表項(xiàng)，通過計(jì)算滾動(dòng)位置動(dòng)態(tài)更新渲染范圍。常用庫如react-virtualized或react-window通過測(cè)量列表容器高度、項(xiàng)高度（固定或動(dòng)態(tài)），計(jì)算當(dāng)前滾動(dòng)偏移量對(duì)應(yīng)的起始和結(jié)束索引，只渲染該范圍內(nèi)的項(xiàng)。數(shù)據(jù)分片適用于數(shù)據(jù)量極大但無需一次性加載的場(chǎng)景，通過IntersectionObserver監(jiān)聽滾動(dòng)到底部事件，觸發(fā)分頁加載（如每次加載50條），并使用React的useMemo緩存已加載數(shù)據(jù)，避免重復(fù)渲染。組件優(yōu)化方面，需確保列表項(xiàng)為純組件（使用React.memo包裹），避免不必要的重渲染；若項(xiàng)內(nèi)容復(fù)雜，可將其拆分為更小的組件，利用useCallback緩存事件處理函數(shù)，減少父組件狀態(tài)變化對(duì)項(xiàng)的影響。實(shí)際項(xiàng)目中，還需注意滾動(dòng)容器的CSS屬性（如overflow:auto）和項(xiàng)的高度計(jì)算準(zhǔn)確性（動(dòng)態(tài)高度需預(yù)加載占位符或測(cè)量緩存）。TypeScript中如何實(shí)現(xiàn)一個(gè)通用的深拷貝函數(shù)？深拷貝函數(shù)需處理原始類型、對(duì)象、數(shù)組、函數(shù)、日期、正則等特殊對(duì)象，同時(shí)避免循環(huán)引用。通用實(shí)現(xiàn)可基于遞歸和類型判斷，結(jié)合Map緩存已處理對(duì)象。示例如下：```typescripttypeAnyObject=Record<string|symbol,any>;functiondeepClone<T>(target:T,cache=newMap<object,any>()):T{//處理原始類型和null/undefinedif(target===null||typeoftarget!=='object')returntarget;//處理特殊對(duì)象類型if(targetinstanceofDate)returnnewDate(target)asT;if(targetinstanceofRegExp)returnnewRegExp(target)asT;if(targetinstanceofSet)returnnewSet([...target])asT;if(targetinstanceofMap)returnnewMap([...target])asT;//檢查循環(huán)引用if(cache.has(target))returncache.get(target);//處理數(shù)組和普通對(duì)象constisArray=Array.isArray(target);constcloneObj=isArray?[]:{}asAnyObject;cache.set(target,cloneObj);constentries=isArray?target.entries():Object.entries(target)as[keyofT,T[keyofT]][];for(const[key,value]ofentries){cloneObj[keyasstring|number]=deepClone(value,cache);}returncloneObjasT;}```關(guān)鍵點(diǎn)：使用Map緩存已克隆的對(duì)象，避免循環(huán)引用導(dǎo)致棧溢出；通過instanceof判斷特殊對(duì)象類型并調(diào)用構(gòu)造函數(shù)；數(shù)組和對(duì)象分別處理鍵的遍歷（數(shù)組用entries獲取索引和值，對(duì)象用Object.entries）。需注意函數(shù)類型（function）通常不建議深拷貝，因?yàn)闀?huì)丟失作用域綁定，實(shí)際使用中可根據(jù)需求決定是否跳過函數(shù)（如添加判斷`if(typeofvalue==='function')returnvalue`）。瀏覽器中事件循環(huán)（EventLoop）的微任務(wù)（Microtask）和宏任務(wù)（Macrotask）執(zhí)行順序是怎樣的？事件循環(huán)的核心是協(xié)調(diào)同步代碼執(zhí)行、微任務(wù)隊(duì)列和宏任務(wù)隊(duì)列的處理。執(zhí)行順序如下：1.執(zhí)行全局同步代碼，形成執(zhí)行棧。2.同步代碼執(zhí)行完成后，檢查微任務(wù)隊(duì)列（MicrotaskQueue），按入隊(duì)順序執(zhí)行所有微任務(wù)（如Promise.then、MutationObserver回調(diào)）。3.微任務(wù)執(zhí)行完畢后，進(jìn)行一次UI渲染（僅當(dāng)瀏覽器認(rèn)為有必要時(shí)，如布局變化）。4.從宏任務(wù)隊(duì)列（MacrotaskQueue）中取出一個(gè)宏任務(wù)執(zhí)行（如setTimeout、setInterval、XMLHttpRequest回調(diào)、用戶點(diǎn)擊事件）。5.重復(fù)步驟2-4，形成循環(huán)。需注意：微任務(wù)在每次宏任務(wù)執(zhí)行前（包括初始同步代碼執(zhí)行后）會(huì)被批量處理，因此微任務(wù)的執(zhí)行優(yōu)先級(jí)高于宏任務(wù)。同一個(gè)事件循環(huán)中，若微任務(wù)執(zhí)行過程中又添加了新的微任務(wù)，這些新任務(wù)會(huì)被追加到當(dāng)前微任務(wù)隊(duì)列末尾，并在本次循環(huán)中繼續(xù)執(zhí)行，直到隊(duì)列為空。宏任務(wù)每次只取一個(gè)執(zhí)行（除了setImmediate等特殊API），避免單個(gè)宏任務(wù)長時(shí)間阻塞事件循環(huán)。例如，以下代碼輸出順序?yàn)椋篳``javascriptconsole.log('sync');setTimeout(()=>console.log('macro'),0);Promise.resolve().then(()=>{console.log('micro1');Promise.resolve().then(()=>console.log('micro2'));});//輸出：sync→micro1→micro2→macro```如何優(yōu)化SPA（單頁應(yīng)用）的首屏加載時(shí)間？首屏加載優(yōu)化需從資源體積、加載順序、緩存策略三方面入手：1.資源體積優(yōu)化：代碼分割（CodeSplitting）：使用React.lazy或Vue的import()動(dòng)態(tài)導(dǎo)入非首屏組件，結(jié)合webpackChunkName提供有意義的chunk名，減少首屏JS體積。TreeShaking：配置構(gòu)建工具（如Webpack的optimization.usedExports）移除未使用的代碼，ES模塊（import/export）的靜態(tài)結(jié)構(gòu)使TreeShaking更高效。圖片優(yōu)化：首屏圖片使用WebP格式（比JPEG小25-35%），小圖片轉(zhuǎn)為base64內(nèi)聯(lián)（減少HTTP請(qǐng)求），大圖片使用懶加載（IntersectionObserver觸發(fā)加載）。壓縮混淆：開啟Gzip或Brotli壓縮（服務(wù)器配置），構(gòu)建時(shí)啟用Terser壓縮JS、CSSNano壓縮CSS。2.加載順序優(yōu)化：關(guān)鍵CSS內(nèi)聯(lián)：將首屏所需的CSS通過<style>標(biāo)簽內(nèi)聯(lián)在HTML中，避免外部CSS文件的阻塞渲染（可使用critters-webpack-plugin提取關(guān)鍵CSS）。預(yù)加載（Preload）：通過<linkrel="preload">聲明關(guān)鍵資源（如首屏JS），告知瀏覽器優(yōu)先加載。延遲非關(guān)鍵資源：將非首屏腳本的defer或async屬性設(shè)置為true，避免阻塞HTML解析。3.緩存策略：強(qiáng)緩存：設(shè)置Cache-Control:max-age=31536000，讓瀏覽器直接使用本地緩存（需配合內(nèi)容哈希文件名，如app.abc123.js，修改內(nèi)容時(shí)哈希變化，避免緩存失效）。協(xié)商緩存：對(duì)無法長期緩存的資源（如用戶數(shù)據(jù)接口），使用ETag和Last-Modified頭，服務(wù)器驗(yàn)證資源是否更新后返回304NotModified。ServiceWorker：注冊(cè)ServiceWorker緩存靜態(tài)資源，實(shí)現(xiàn)離線訪問和更快的二次加載（需注意首次加載時(shí)ServiceWorker需要安裝，可能延遲緩存生效）。實(shí)際項(xiàng)目中，可通過Lighthouse工具分析首屏性能瓶頸，針對(duì)性優(yōu)化。例如，若LCP（最大內(nèi)容ful填充時(shí)間）過長，可能是首屏圖片或大JS文件加載慢，需檢查圖片格式和代碼分割策略；若FCP（首次內(nèi)容渲染時(shí)間）過長，可能是CSS阻塞，需內(nèi)聯(lián)關(guān)鍵CSS。WebAssembly在前端中的典型應(yīng)用場(chǎng)景有哪些？WebAssembly（Wasm）作為二進(jìn)制指令格式，可在瀏覽器中以接近原生的性能運(yùn)行，適合計(jì)算密集型任務(wù)。典型應(yīng)用場(chǎng)景包括：1.圖形處理：如3D建模（Three.js結(jié)合Wasm加速網(wǎng)格計(jì)算）、圖像編輯（WebAssembly實(shí)現(xiàn)的濾鏡算法比JS快數(shù)倍）。2.科學(xué)計(jì)算：數(shù)值模擬（如有限元分析）、加密算法（AES/RSA的Wasm實(shí)現(xiàn)替代JS庫，提升安全性和性能）。3.游戲引擎：將C/C++編寫的游戲引擎（如Unity）編譯為Wasm，在瀏覽器中運(yùn)行高性能游戲，避免JS的單線程限制（結(jié)合WebWorkers實(shí)現(xiàn)多線程）。4.音視頻處理：音頻編解碼（如Opus）、視頻轉(zhuǎn)碼（FFmpeg的Wasm版本ffmpeg.wasm可在瀏覽器中實(shí)現(xiàn)視頻剪輯）。5.復(fù)雜業(yè)務(wù)邏輯：如金融領(lǐng)域的高頻交易計(jì)算、CAD軟件的幾何算法，通過Wasm將核心邏輯從JS遷移，減少主線程阻塞。需注意，Wasm與JS的交互存在性能開銷（如數(shù)據(jù)類型轉(zhuǎn)換），因此應(yīng)將計(jì)算密集的核心邏輯封裝為Wasm模塊，僅通過接口傳遞必要參數(shù)（如數(shù)組指針、數(shù)值），避免頻繁交互。目前主流瀏覽器（Chrome、Firefox、Safari、Edge）均已支持Wasm，且WebAssembly2.0規(guī)范正在推進(jìn)，將支持多線程（SharedArrayBuffer）和SIMD（單指令多數(shù)據(jù)）指令，進(jìn)一步擴(kuò)展應(yīng)用場(chǎng)景。ReactServerComponents（RSC）解決了哪些問題？ReactServerComponents（RSC）通過將部分組件在服務(wù)器端渲染，解決了傳統(tǒng)SPA（客戶端渲染）在首屏加載、SEO和資源體積上的痛點(diǎn)：1.減少客戶端JS體積：RSC在服務(wù)器端渲染后直接返回HTML，相關(guān)組件的JS代碼不會(huì)被打包到客戶端bundle中。例如，一個(gè)依賴大量數(shù)據(jù)的儀表盤組件，其數(shù)據(jù)獲取和渲染邏輯在服務(wù)器完成，客戶端只需加載交互相關(guān)的組件代碼，顯著降低首屏JS體積（可能減少50%以上）。2.提升首屏加載速度：RSC可在服務(wù)器端并行獲取數(shù)據(jù)（利用Node.js的異步I/O），避免客戶端組件樹逐層請(qǐng)求數(shù)據(jù)導(dǎo)致的瀑布流加載。服務(wù)器將渲染后的HTML和必要的客戶端交互代碼（如事件處理函數(shù)）一起發(fā)送到客戶端，用戶可見內(nèi)容（HTML）的加載早于客戶端JS的完全下載，改善LCP指標(biāo)。3.優(yōu)化SEO：RSC提供的是完整的HTML內(nèi)容，搜索引擎爬蟲可直接抓取到渲染后的內(nèi)容，無需等待客戶端JS執(zhí)行（傳統(tǒng)SPA需通過SSR或預(yù)渲染解決SEO問題，但RSC是更原生的服務(wù)器渲染方案）。4.支持訪問服務(wù)器資源：RSC運(yùn)行在服務(wù)器環(huán)境，可直接訪問數(shù)據(jù)庫、文件系統(tǒng)等客戶端不可用的資源，無需通過API接口中轉(zhuǎn)，減少網(wǎng)絡(luò)開銷（如直接從數(shù)據(jù)庫查詢數(shù)據(jù)并渲染到組件中）。需要注意的是，RSC需要與客戶端組件（ClientComponents）配合使用，客戶端組件通過'useclient'指令聲明，可使用狀態(tài)（useState）、副作用（useEffect）和瀏覽器API。RSC本身是無狀態(tài)的，不能使用Hooks（除use），其設(shè)計(jì)更偏向于純數(shù)據(jù)渲染和資源訪問。如何實(shí)現(xiàn)一個(gè)高性能的Vue響應(yīng)式系統(tǒng)？Vue3的響應(yīng)式系統(tǒng)基于Proxy和Reflect實(shí)現(xiàn)，核心是通過track（依賴收集）和trigger（觸發(fā)更新）機(jī)制管理響應(yīng)式對(duì)象與副作用函數(shù)的依賴關(guān)系。高性能實(shí)現(xiàn)