2025年前端論文試題及答案一、單項(xiàng)選擇題（每題2分，共20分）1.以下哪項(xiàng)是WebAssembly（Wasm）在2025年前端場(chǎng)景中的核心應(yīng)用價(jià)值？A.完全替代JavaScript成為前端主要編程語(yǔ)言B.為復(fù)雜計(jì)算密集型任務(wù)提供接近原生的執(zhí)行性能C.簡(jiǎn)化跨平臺(tái)應(yīng)用的UI渲染邏輯D.直接操作DOM樹(shù)提升渲染效率答案：B解析：WebAssembly的設(shè)計(jì)目標(biāo)是作為JavaScript的補(bǔ)充，通過(guò)二進(jìn)制格式提供高性能計(jì)算能力，尤其適用于圖形處理、物理引擎、大數(shù)據(jù)分析等計(jì)算密集型場(chǎng)景。其無(wú)法直接操作DOM（需通過(guò)JS橋接），也不會(huì)替代JS的膠水語(yǔ)言和DOM操作優(yōu)勢(shì)。2.關(guān)于CSS容器查詢（ContainerQueries）的最新規(guī)范（2025年實(shí)施版），以下描述錯(cuò)誤的是？A.支持基于容器尺寸的響應(yīng)式樣式規(guī)則B.可以嵌套使用多個(gè)容器查詢條件C.完全替代媒體查詢（MediaQueries）實(shí)現(xiàn)布局控制D.支持通過(guò)@container規(guī)則定義查詢條件答案：C解析：容器查詢解決的是局部容器尺寸變化的響應(yīng)問(wèn)題，而媒體查詢關(guān)注視口整體尺寸，兩者適用場(chǎng)景互補(bǔ)。例如，卡片組件內(nèi)部的布局調(diào)整更適合用容器查詢，而全局導(dǎo)航欄的響應(yīng)式設(shè)計(jì)仍需媒體查詢。3.在React19（假設(shè)2025年主流版本）中，以下哪個(gè)特性最能體現(xiàn)“并發(fā)模式”對(duì)用戶體驗(yàn)的優(yōu)化？A.自動(dòng)批處理（AutomaticBatching）減少渲染次數(shù)B.懸念（Suspense）支持更細(xì)粒度的加載狀態(tài)管理C.時(shí)間分片（TimeSlicing）允許優(yōu)先級(jí)更高的更新中斷當(dāng)前渲染D.組件記憶化（React.memo）優(yōu)化重復(fù)渲染性能答案：C解析：并發(fā)模式的核心是通過(guò)可中斷的渲染機(jī)制，讓高優(yōu)先級(jí)任務(wù)（如用戶輸入）優(yōu)先執(zhí)行，避免長(zhǎng)任務(wù)阻塞主線程。時(shí)間分片技術(shù)正是這一機(jī)制的底層實(shí)現(xiàn)，直接提升交互流暢度。4.以下哪項(xiàng)是Vite5（2025年預(yù)期版本）在構(gòu)建優(yōu)化上的突破性改進(jìn)？A.基于esbuild的全量代碼壓縮替代TerserB.引入邊緣計(jì)算節(jié)點(diǎn)實(shí)現(xiàn)按需構(gòu)建（On-DemandBuild）C.支持WebAssembly加速的CSS預(yù)處理器D.內(nèi)置HTTP/3服務(wù)器提升開(kāi)發(fā)階段資源加載速度答案：B解析：隨著微前端和大型單頁(yè)應(yīng)用的普及，傳統(tǒng)全量構(gòu)建的耗時(shí)問(wèn)題愈發(fā)突出。Vite5通過(guò)與邊緣計(jì)算平臺(tái)集成，將非首屏依賴的構(gòu)建任務(wù)延遲到運(yùn)行時(shí)按需執(zhí)行，顯著降低冷啟動(dòng)時(shí)間。5.關(guān)于WebGPUAPI（2025年主流瀏覽器支持）的核心優(yōu)勢(shì)，以下描述正確的是？A.提供比WebGL更簡(jiǎn)單的著色器編程接口B.支持跨GPU架構(gòu)的統(tǒng)一抽象層，提升圖形計(jì)算效率C.直接替代Canvas2D實(shí)現(xiàn)所有2D繪圖需求D.強(qiáng)制要求使用WGSL（WebGPUShadingLanguage）替代GLSL答案：B解析：WebGPU通過(guò)抽象不同GPU硬件的底層差異（如Vulkan、Metal、DirectX），提供統(tǒng)一的高性能圖形和計(jì)算接口，尤其在并行計(jì)算（如圖像處理、物理模擬）場(chǎng)景下效率顯著高于WebGL。二、簡(jiǎn)答題（每題8分，共40分）1.簡(jiǎn)述現(xiàn)代前端工程化中“構(gòu)建產(chǎn)物優(yōu)化”的核心策略及其技術(shù)實(shí)現(xiàn)方式。答案：構(gòu)建產(chǎn)物優(yōu)化的核心目標(biāo)是降低資源體積、提升加載速度并保證運(yùn)行時(shí)性能，主要策略包括：（1）代碼拆分（CodeSplitting）：通過(guò)動(dòng)態(tài)導(dǎo)入（import()）或路由拆分（如React.lazy）將大文件拆分為按需加載的塊，結(jié)合預(yù)加載（<linkrel="preload">）優(yōu)化關(guān)鍵資源加載順序。Webpack5的SplitChunks插件、Vite的自動(dòng)拆分會(huì)根據(jù)依賴圖智能拆分。（2）壓縮與混淆：使用Terser（JS）、CSSNano（CSS）、ImageOptim（圖片）等工具壓縮代碼體積。2025年主流工具將支持Wasm加速的壓縮算法（如Brotli+Zstandard混合壓縮），壓縮率比gzip提升30%以上。（3）TreeShaking：基于ES模塊靜態(tài)分析（如Rollup、Vite）移除未使用的代碼，需配合副作用標(biāo)記（sideEffects:false）和嚴(yán)格的模塊規(guī)范（ES6+）實(shí)現(xiàn)。TypeScript的聲明文件（.d.ts）優(yōu)化可進(jìn)一步減少冗余類型信息。（4）資源類型優(yōu)化：將圖片轉(zhuǎn)換為AVIF/WebP格式（比JPEG節(jié)省50%體積），字體使用可變字體（VariableFonts）合并字重，CSS使用@layer控制優(yōu)先級(jí)減少冗余選擇器。2.對(duì)比分析Vue4與SolidJS在響應(yīng)式系統(tǒng)設(shè)計(jì)上的差異及各自適用場(chǎng)景。答案：Vue4延續(xù)了基于依賴跟蹤的響應(yīng)式系統(tǒng)，通過(guò)Proxy對(duì)象攔截?cái)?shù)據(jù)訪問(wèn)/修改，利用“響應(yīng)式對(duì)象-依賴收集-副作用觸發(fā)”的機(jī)制實(shí)現(xiàn)自動(dòng)更新。其特點(diǎn)是隱式依賴收集（開(kāi)發(fā)者無(wú)需顯式聲明依賴），適合快速開(kāi)發(fā)業(yè)務(wù)邏輯復(fù)雜的中后臺(tái)應(yīng)用，但可能因過(guò)多細(xì)粒度依賴導(dǎo)致性能損耗（需配合shallowRef等優(yōu)化）。SolidJS采用“信號(hào)-計(jì)算-副作用”（Signal-Computation-Effect）的顯式響應(yīng)式模型，通過(guò)createSignal創(chuàng)建獨(dú)立信號(hào)，開(kāi)發(fā)者需顯式調(diào)用信號(hào)讀取函數(shù)（如count()）來(lái)聲明依賴。這種設(shè)計(jì)避免了隱式依賴的性能問(wèn)題（依賴關(guān)系在編譯時(shí)確定），適合高交互、高性能要求的場(chǎng)景（如實(shí)時(shí)協(xié)作工具、游戲UI），但學(xué)習(xí)曲線較陡，需要開(kāi)發(fā)者主動(dòng)管理依賴。適用場(chǎng)景對(duì)比：Vue4更適合業(yè)務(wù)邏輯復(fù)雜、團(tuán)隊(duì)規(guī)模大的項(xiàng)目（隱式依賴降低開(kāi)發(fā)門檻）；SolidJS適合對(duì)性能敏感、交互頻繁的場(chǎng)景（顯式依賴提升可預(yù)測(cè)性和運(yùn)行效率）。3.說(shuō)明WebVitals2025版核心指標(biāo)的更新內(nèi)容及其對(duì)前端優(yōu)化的指導(dǎo)意義。答案：WebVitals2025版在原有LCP（最大內(nèi)容渲染）、FID（首次輸入延遲）、CLS（累積布局偏移）基礎(chǔ)上，新增兩個(gè)核心指標(biāo)：（1）INP（InteractiontoNextPaint，交互至下一次繪制）：替代FID，衡量用戶所有交互（點(diǎn)擊、滾動(dòng)、輸入）的響應(yīng)延遲，覆蓋更全面的用戶體驗(yàn)場(chǎng)景。（2）TTI+（TimetoInteractive+，完全可交互時(shí)間）：擴(kuò)展TTI指標(biāo)，增加對(duì)動(dòng)態(tài)內(nèi)容加載（如懶加載組件、異步數(shù)據(jù)填充）后交互響應(yīng)的評(píng)估。指導(dǎo)意義：INP要求優(yōu)化所有交互路徑的響應(yīng)速度，需關(guān)注事件處理函數(shù)的執(zhí)行時(shí)間（避免長(zhǎng)任務(wù)）、主線程空閑時(shí)間利用（如使用requestIdleCallback）、以及虛擬滾動(dòng)/懶渲染等技術(shù)減少即時(shí)計(jì)算量。TTI+強(qiáng)調(diào)應(yīng)用全生命周期的可交互性，需優(yōu)化異步資源加載策略（如優(yōu)先加載關(guān)鍵交互組件）、使用服務(wù)端渲染（SSR）或靜態(tài)站點(diǎn)提供（SSG）減少客戶端渲染時(shí)間，同時(shí)通過(guò)內(nèi)存管理（如避免閉包泄漏）保持長(zhǎng)期運(yùn)行的流暢性。4.描述使用WebWorkers實(shí)現(xiàn)前端“計(jì)算-渲染”分離架構(gòu)的關(guān)鍵步驟及注意事項(xiàng)。答案：關(guān)鍵步驟：（1）任務(wù)拆分：將計(jì)算密集型任務(wù)（如圖像處理、數(shù)據(jù)排序、物理模擬）從主線程剝離，通過(guò)postMessage發(fā)送到Worker線程。例如，地圖應(yīng)用的路徑規(guī)劃算法可移至Worker。（2）通信設(shè)計(jì)：使用結(jié)構(gòu)化克?。⊿tructuredClone）或Transferable對(duì)象傳遞數(shù)據(jù)，避免主線程阻塞。大數(shù)組推薦使用SharedArrayBuffer共享內(nèi)存（需配合Atomics原子操作），減少數(shù)據(jù)拷貝開(kāi)銷。（3）錯(cuò)誤處理：為Worker添加onerror事件監(jiān)聽(tīng)，捕獲計(jì)算過(guò)程中的異常；主線程需實(shí)現(xiàn)重試機(jī)制（如任務(wù)超時(shí)后重新發(fā)送）。（4）資源管理：Worker內(nèi)部可通過(guò)importScripts加載依賴庫(kù)（如Lodash），或使用ES模塊Worker（支持import語(yǔ)法）提升模塊化能力。注意事項(xiàng)：避免頻繁通信：每次postMessage都會(huì)觸發(fā)序列化/反序列化，應(yīng)批量處理小任務(wù)或合并數(shù)據(jù)傳輸。內(nèi)存限制：Worker有獨(dú)立的內(nèi)存空間，需及時(shí)終止空閑Worker（調(diào)用terminate()）避免內(nèi)存泄漏。瀏覽器兼容性：需處理不支持SharedArrayBuffer的舊版瀏覽器（如通過(guò)polyfill回退到結(jié)構(gòu)化克?。?。5.分析Svelte5（2025年預(yù)期版本）“零運(yùn)行時(shí)”架構(gòu)對(duì)前端開(kāi)發(fā)的影響及潛在挑戰(zhàn)。答案：影響：（1）更小的包體積：Svelte通過(guò)編譯時(shí)將響應(yīng)式邏輯轉(zhuǎn)換為原生JS代碼，無(wú)需引入運(yùn)行時(shí)庫(kù)（如React的react包、Vue的vue.runtime.esm-bundler），bundle體積可減少30%-50%，提升加載速度。（2）更簡(jiǎn)單的開(kāi)發(fā)體驗(yàn)：開(kāi)發(fā)者只需編寫聲明式模板（如{if}條件塊），編譯器自動(dòng)提供高效的更新代碼，無(wú)需手動(dòng)管理狀態(tài)（如useState、ref）或依賴（如useEffect的依賴數(shù)組）。（3）更好的性能：編譯時(shí)優(yōu)化（如細(xì)粒度DOM更新、死代碼消除）使渲染效率接近原生JS，尤其在頻繁更新的場(chǎng)景（如實(shí)時(shí)儀表盤）中表現(xiàn)突出。潛在挑戰(zhàn)：（1）編譯時(shí)復(fù)雜度：復(fù)雜邏輯（如動(dòng)態(tài)組件、循環(huán)中的條件更新）可能需要更智能的編譯器優(yōu)化，否則可能提供冗余代碼。Svelte5需增強(qiáng)對(duì)運(yùn)行時(shí)動(dòng)態(tài)性的支持（如$derived優(yōu)化計(jì)算屬性）。（2）調(diào)試難度：編譯后的代碼與源碼差異較大，開(kāi)發(fā)者調(diào)試時(shí)需依賴SourceMap，可能影響問(wèn)題定位效率。（3）生態(tài)兼容性：第三方庫(kù)需適配Svelte的編譯機(jī)制（如自定義指令、商店模式），現(xiàn)有React/Vue生態(tài)的組件無(wú)法直接復(fù)用，可能限制大型項(xiàng)目的技術(shù)選型。三、論述題（每題15分，共30分）1.結(jié)合2025年前端技術(shù)趨勢(shì)，論述“邊緣計(jì)算（EdgeComputing）”與前端開(kāi)發(fā)的深度融合路徑及典型應(yīng)用場(chǎng)景。答案：邊緣計(jì)算通過(guò)將計(jì)算資源部署在離用戶更近的邊緣節(jié)點(diǎn)（如CDN節(jié)點(diǎn)、智能設(shè)備），縮短數(shù)據(jù)傳輸延遲，提升響應(yīng)速度。與前端開(kāi)發(fā)的融合路徑主要體現(xiàn)在以下三個(gè)層面：（1）構(gòu)建階段融合：傳統(tǒng)前端構(gòu)建（如Webpack、Vite）需在本地或CI/CD服務(wù)器完成全量編譯，耗時(shí)隨項(xiàng)目規(guī)模增長(zhǎng)而增加。邊緣計(jì)算可提供“按需構(gòu)建”服務(wù)：開(kāi)發(fā)階段，開(kāi)發(fā)者僅構(gòu)建當(dāng)前修改的模塊，邊緣節(jié)點(diǎn)緩存歷史構(gòu)建結(jié)果，通過(guò)增量編譯減少等待時(shí)間；生產(chǎn)環(huán)境，邊緣節(jié)點(diǎn)根據(jù)用戶地域動(dòng)態(tài)編譯適配的資源（如不同地區(qū)的多語(yǔ)言包），降低主服務(wù)器壓力。（2）運(yùn)行時(shí)融合：前端應(yīng)用的動(dòng)態(tài)內(nèi)容（如個(gè)性化推薦、A/B測(cè)試）可在邊緣節(jié)點(diǎn)完成計(jì)算。例如，用戶訪問(wèn)電商頁(yè)面時(shí)，邊緣節(jié)點(diǎn)根據(jù)用戶IP獲取地理位置，動(dòng)態(tài)注入本地促銷信息，再將渲染后的HTML發(fā)送到客戶端。這種“邊緣渲染”模式（EdgeRendering）結(jié)合了SSR的首屏性能與CSR的交互體驗(yàn)，同時(shí)避免了中心服務(wù)器的高負(fù)載。（3）數(shù)據(jù)處理融合：前端產(chǎn)生的用戶行為數(shù)據(jù)（如點(diǎn)擊流、性能指標(biāo)）可在邊緣節(jié)點(diǎn)進(jìn)行初步清洗和聚合（如過(guò)濾無(wú)效數(shù)據(jù)、計(jì)算實(shí)時(shí)PV/UV），僅將匯總結(jié)果發(fā)送到中心數(shù)據(jù)庫(kù)。這減少了網(wǎng)絡(luò)傳輸量（降低50%-70%），同時(shí)邊緣節(jié)點(diǎn)的低延遲特性使實(shí)時(shí)分析（如熱點(diǎn)內(nèi)容追蹤）成為可能。典型應(yīng)用場(chǎng)景包括：實(shí)時(shí)協(xié)作工具：多人編輯時(shí)，邊緣節(jié)點(diǎn)處理沖突檢測(cè)和操作合并，減少中心服務(wù)器的同步延遲，提升協(xié)同體驗(yàn)。物聯(lián)網(wǎng)前端：智能設(shè)備的Web界面（如智能家居控制面板）通過(guò)邊緣節(jié)點(diǎn)處理設(shè)備狀態(tài)更新，避免直接與云端通信的高延遲。游戲前端：網(wǎng)頁(yè)游戲的物理計(jì)算（如碰撞檢測(cè)）在邊緣節(jié)點(diǎn)運(yùn)行，減少客戶端計(jì)算壓力，同時(shí)利用邊緣節(jié)點(diǎn)的低延遲特性提升操作響應(yīng)速度。2.從“技術(shù)選型”“架構(gòu)設(shè)計(jì)”“性能優(yōu)化”三個(gè)維度，論述如何構(gòu)建一個(gè)支持10萬(wàn)+并發(fā)用戶的高可用前端應(yīng)用。答案：（1）技術(shù)選型維度：框架選擇：優(yōu)先考慮輕量級(jí)、高渲染效率的框架。SolidJS的編譯時(shí)優(yōu)化或Preact（React兼容的輕量版）可減少運(yùn)行時(shí)開(kāi)銷；Svelte的零運(yùn)行時(shí)特性適合對(duì)包體積敏感的場(chǎng)景。避免使用重運(yùn)行時(shí)框架（如未優(yōu)化的Vue3+Pinia組合），除非業(yè)務(wù)邏輯復(fù)雜度要求。狀態(tài)管理：對(duì)于大規(guī)模用戶交互，選擇細(xì)粒度狀態(tài)管理方案（如Zustand的原子狀態(tài)、Jotai的可組合狀態(tài)），避免全局狀態(tài)導(dǎo)致的不必要渲染。復(fù)雜業(yè)務(wù)可結(jié)合ReduxToolkit的切片（Slice）機(jī)制拆分狀態(tài)域。通信協(xié)議：使用HTTP/3（基于QUIC）替代HTTP/2，減少連接建立延遲；長(zhǎng)連接場(chǎng)景（如實(shí)時(shí)通知）采用WebSockets或更輕量的Socket.IO（需配置心跳機(jī)制）。（2）架構(gòu)設(shè)計(jì)維度：微前端架構(gòu)：將應(yīng)用拆分為獨(dú)立子應(yīng)用（如用戶中心、交易模塊），通過(guò)主應(yīng)用（如Single-SPA或ModuleFederation）協(xié)調(diào)路由和狀態(tài)。子應(yīng)用可獨(dú)立開(kāi)發(fā)、部署，降低代碼耦合，提升團(tuán)隊(duì)協(xié)作效率。服務(wù)端渲染（SSR）與靜態(tài)提供（SSG）結(jié)合：核心頁(yè)面（如首頁(yè)、商品詳情頁(yè)）使用SSR提升首屏加載速度（LCP<1.5s）；靜態(tài)內(nèi)容（如幫助文檔、營(yíng)銷頁(yè)面）通過(guò)SSG提供純靜態(tài)文件，部署到CDN。動(dòng)態(tài)內(nèi)容（如用戶個(gè)人頁(yè)）采用客戶端渲染（CSR）+增量靜態(tài)再生（ISR），定期更新緩存。容錯(cuò)設(shè)計(jì)：實(shí)現(xiàn)前端降級(jí)策略（如網(wǎng)絡(luò)異常時(shí)展示緩存內(nèi)容）、限流（如限制短時(shí)間內(nèi)API請(qǐng)求次數(shù)）、熔斷（如某個(gè)接口失敗率超閾值時(shí)自動(dòng)切換到備用接口）。使用Sentry等工具監(jiān)控運(yùn)行時(shí)錯(cuò)誤，結(jié)合日志分析快速定位問(wèn)題。（3）性能優(yōu)化維度：資源加載優(yōu)化：關(guān)鍵CSS內(nèi)聯(lián)（CriticalCSS），非關(guān)鍵CSS延遲加載（使用media="print"+onload切換）；JS采用懶加載（defer/async），首屏關(guān)鍵JS通過(guò)preload優(yōu)先加載。圖片使用響應(yīng)式圖片（srcset+sizes），配合lazysizes庫(kù)實(shí)現(xiàn)懶加載（視口外圖片不加載）。渲染性能優(yōu)化：避免強(qiáng)制同步布局（如讀取DOM屬性后立即修改），使用requestAnimationFrame批量更新；列表組件使用虛擬滾動(dòng)（如react-virtualized、vue-virtual-scroller），僅渲染可視區(qū)域內(nèi)容。內(nèi)存管理：及時(shí)銷毀不再使用的事件監(jiān)聽(tīng)器、定時(shí)器；避免閉包引起的內(nèi)存泄漏（如回調(diào)函數(shù)引用DOM節(jié)點(diǎn)）；大型數(shù)據(jù)使用WeakMap/WeakSet存儲(chǔ)，允許垃圾回收機(jī)制自動(dòng)清理。四、實(shí)踐題（30分）要求：使用Vite5+React19技術(shù)棧，實(shí)現(xiàn)一個(gè)支持“自動(dòng)適應(yīng)容器寬度”“響應(yīng)式列數(shù)”“圖片懶加載”的電商商品網(wǎng)格組件（GridLayout），并給出關(guān)鍵代碼及優(yōu)化說(shuō)明。答案：1.組件需求分析：自動(dòng)適應(yīng)容器寬度：根據(jù)父容器寬度動(dòng)態(tài)調(diào)整列數(shù)（如寬度<600px時(shí)1列，600-1200px時(shí)2列，≥1200px時(shí)3列）。響應(yīng)式列數(shù)：使用CSS容器查詢（ContainerQueries）實(shí)現(xiàn)，兼容不支持的瀏覽器時(shí)回退到媒體查詢。圖片懶加載：視口內(nèi)圖片加載，使用IntersectionObserverAPI，支持占位圖（如灰色背景）。2.關(guān)鍵代碼實(shí)現(xiàn)：（1）Vite配置（vite.config.ts）：```typescriptimport{defineConfig}from'vite';importreactfrom'@vitejs/plugin-react-swc';importcontainerQueriesfrom'@csstools/postcss-container-queries';exportdefaultdefineConfig({plugins:[react()],css:{postcss:{plugins:[containerQueries()]//啟用容器查詢PostCSS插件}},build:{assetsInlineLimit:4096,//4KB以下圖片內(nèi)聯(lián)為base64chunkSizeWarningLimit:1000//分塊大小警告閾值設(shè)為1000KB}});```（2）GridLayout組件（GridLayout.tsx）：```tsximport{useRef,useEffect,useState}from'react';import{LazyImage}from'./LazyImage';//自定義懶加載組件interfaceGridItem{id:string;imageUrl:string;title:string;}exportconstGridLayout=({items}:{items:GridItem[]})=>{constcontainerRef=useRef<HTMLDivElement>(null);const[containerWidth,setContainerWidth]=useState(0);//監(jiān)聽(tīng)容器寬度變化useEffect(()=>{constresizeObserver=newResizeObserver(entries=>{constwidth=entries[0]?.contentRect.width||0;setContainerWidth(width);});if(containerRef.current){resizeObserver.observe(containerRef.current);}return()=>resizeObserver.disconnect();},[]);//計(jì)算列數(shù)（兼容容器查詢不支持的場(chǎng)景）constgetColumns=()=>{if(containerWidth>=1200)return3;if(containerWidth>=600)return2;return1;};return(<divref={containerRef}className="grid-container"style={{gridTemplateColumns:`repeat(${getColumns()},1fr)`}}>{items.map(item=>(<divkey={item.id}className="grid-item"><LazyImagesrc={item.imageUrl}alt={item.title}placeholder={<divclassName="placeholder"/>}/><pclassName="title">{item.title}</p></div>))}</div>);};//懶加載組件（LazyImage.tsx）exportconstLazyImage=({src,alt,placeholder})=>{constimgRef=useRef<HTMLImageElement>(null);const[isLoaded,setIsLoaded]=useState(false);useEffect(()=>{constobserver=newIntersectionObserver(([entry])=>{if(entry.isIntersecting&&!isLoaded){//加載圖片constimg=newImage();img.src=src;img.onload=()=>{if(i