2025年高频互联网前端面试题及答案

2025年高频互联网前端面试题及答案React中Hooks的依赖数组是如何实现依赖追踪的？Hooks的依赖数组实现依赖于闭包和React的状态管理机制。以useEffect为例，当组件渲染时，React会为当前执行的useEffect提供一个依赖数组的快照。在组件更新时，React会比较新渲染周期中useEffect的依赖数组与上一次的快照：如果所有依赖项的引用或值都未变化（通过Object.is比较），则跳过副作用函数的执行。这种机制的关键在于，每个Hooks在组件渲染时按顺序被记录在组件实例的memoizedState链表中，依赖数组作为链表节点的一部分被存储。需要注意的是，依赖数组中若遗漏必要状态会导致闭包捕获旧值，而包含过多无关依赖则可能导致副作用频繁执行。实际开发中，推荐使用eslint-plugin-react-hooks的exhaustive-deps规则自动检测依赖完整性。Vue3组合式API相比选项式API有哪些设计优势？组合式API（CompositionAPI）通过setup函数和逻辑组合（如自定义hook）解决了选项式API（OptionsAPI）在复杂组件中逻辑分散的问题。选项式API将数据（data）、方法（methods）、生命周期（mounted等）按类型拆分，当组件涉及多个独立逻辑（如表单验证、数据请求、用户交互）时，相同逻辑的代码会散落在不同选项中，导致可维护性下降。组合式API允许开发者按逻辑功能组织代码，例如将数据请求和加载状态封装为useFetch函数，在setup中引入后直接暴露响应式变量和方法。此外，组合式API通过响应式系统（ref/reactive）显式管理状态，避免了选项式API中this指向的隐式依赖问题，更利于TypeScript类型推导和TreeShaking（未使用的组合逻辑可被构建工具移除）。Vite相比Webpack在开发阶段的性能优化核心是什么？Vite的开发服务器性能优势主要源于“按需编译”和“原生ES模块支持”两大策略。传统打包工具（如Webpack）在启动时需要对整个项目进行完整编译，提供bundle文件，这在大型项目中耗时较长。Vite利用现代浏览器对ES模块（ESModules）的原生支持，开发阶段不打包代码，而是直接通过HTTP服务器按模块加载请求。当浏览器请求某个模块时，Vite才通过esbuild（Go语言编写，速度是传统JS打包工具的10-100倍）对该模块进行实时编译（仅处理当前请求的模块及其依赖），并通过HTTP头（如Cache-Control）缓存已编译模块，减少重复计算。此外，Vite的HMR（热更新）基于ESM的模块依赖图，仅需更新修改的模块及其直接依赖，无需重新加载整个应用，实现毫秒级更新。如何解决React中长列表渲染的性能问题？React长列表性能优化需结合虚拟滚动（VirtualScrolling）、数据分片（Chunking）和组件优化三方面。虚拟滚动的核心是仅渲染视口内可见的列表项，通过计算滚动位置动态更新渲染范围。常用库如react-virtualized或react-window通过测量列表容器高度、项高度（固定或动态），计算当前滚动偏移量对应的起始和结束索引，只渲染该范围内的项。数据分片适用于数据量极大但无需一次性加载的场景，通过IntersectionObserver监听滚动到底部事件，触发分页加载（如每次加载50条），并使用React的useMemo缓存已加载数据，避免重复渲染。组件优化方面，需确保列表项为纯组件（使用React.memo包裹），避免不必要的重渲染；若项内容复杂，可将其拆分为更小的组件，利用useCallback缓存事件处理函数，减少父组件状态变化对项的影响。实际项目中，还需注意滚动容器的CSS属性（如overflow:auto）和项的高度计算准确性（动态高度需预加载占位符或测量缓存）。TypeScript中如何实现一个通用的深拷贝函数？深拷贝函数需处理原始类型、对象、数组、函数、日期、正则等特殊对象，同时避免循环引用。通用实现可基于递归和类型判断，结合Map缓存已处理对象。示例如下：```typescripttypeAnyObject=Record<string|symbol,any>;functiondeepClone<T>(target:T,cache=newMap<object,any>()):T{//处理原始类型和null/undefinedif(target===null||typeoftarget!=='object')returntarget;//处理特殊对象类型if(targetinstanceofDate)returnnewDate(target)asT;if(targetinstanceofRegExp)returnnewRegExp(target)asT;if(targetinstanceofSet)returnnewSet([...target])asT;if(targetinstanceofMap)returnnewMap([...target])asT;//检查循环引用if(cache.has(target))returncache.get(target);//处理数组和普通对象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;}```关键点：使用Map缓存已克隆的对象，避免循环引用导致栈溢出；通过instanceof判断特殊对象类型并调用构造函数；数组和对象分别处理键的遍历（数组用entries获取索引和值，对象用Object.entries）。需注意函数类型（function）通常不建议深拷贝，因为会丢失作用域绑定，实际使用中可根据需求决定是否跳过函数（如添加判断`if(typeofvalue==='function')returnvalue`）。浏览器中事件循环（EventLoop）的微任务（Microtask）和宏任务（Macrotask）执行顺序是怎样的？事件循环的核心是协调同步代码执行、微任务队列和宏任务队列的处理。执行顺序如下：1.执行全局同步代码，形成执行栈。2.同步代码执行完成后，检查微任务队列（MicrotaskQueue），按入队顺序执行所有微任务（如Promise.then、MutationObserver回调）。3.微任务执行完毕后，进行一次UI渲染（仅当浏览器认为有必要时，如布局变化）。4.从宏任务队列（MacrotaskQueue）中取出一个宏任务执行（如setTimeout、setInterval、XMLHttpRequest回调、用户点击事件）。5.重复步骤2-4，形成循环。需注意：微任务在每次宏任务执行前（包括初始同步代码执行后）会被批量处理，因此微任务的执行优先级高于宏任务。同一个事件循环中，若微任务执行过程中又添加了新的微任务，这些新任务会被追加到当前微任务队列末尾，并在本次循环中继续执行，直到队列为空。宏任务每次只取一个执行（除了setImmediate等特殊API），避免单个宏任务长时间阻塞事件循环。例如，以下代码输出顺序为：```javascriptconsole.log('sync');setTimeout(()=>console.log('macro'),0);Promise.resolve().then(()=>{console.log('micro1');Promise.resolve().then(()=>console.log('micro2'));});//输出：sync→micro1→micro2→macro```如何优化SPA（单页应用）的首屏加载时间？首屏加载优化需从资源体积、加载顺序、缓存策略三方面入手：1.资源体积优化：代码分割（CodeSplitting）：使用React.lazy或Vue的import()动态导入非首屏组件，结合webpackChunkName提供有意义的chunk名，减少首屏JS体积。TreeShaking：配置构建工具（如Webpack的optimization.usedExports）移除未使用的代码，ES模块（import/export）的静态结构使TreeShaking更高效。图片优化：首屏图片使用WebP格式（比JPEG小25-35%），小图片转为base64内联（减少HTTP请求），大图片使用懒加载（IntersectionObserver触发加载）。压缩混淆：开启Gzip或Brotli压缩（服务器配置），构建时启用Terser压缩JS、CSSNano压缩CSS。2.加载顺序优化：关键CSS内联：将首屏所需的CSS通过<style>标签内联在HTML中，避免外部CSS文件的阻塞渲染（可使用critters-webpack-plugin提取关键CSS）。预加载（Preload）：通过<linkrel="preload">声明关键资源（如首屏JS），告知浏览器优先加载。延迟非关键资源：将非首屏脚本的defer或async属性设置为true，避免阻塞HTML解析。3.缓存策略：强缓存：设置Cache-Control:max-age=31536000，让浏览器直接使用本地缓存（需配合内容哈希文件名，如app.abc123.js，修改内容时哈希变化，避免缓存失效）。协商缓存：对无法长期缓存的资源（如用户数据接口），使用ETag和Last-Modified头，服务器验证资源是否更新后返回304NotModified。ServiceWorker：注册ServiceWorker缓存静态资源，实现离线访问和更快的二次加载（需注意首次加载时ServiceWorker需要安装，可能延迟缓存生效）。实际项目中，可通过Lighthouse工具分析首屏性能瓶颈，针对性优化。例如，若LCP（最大内容ful填充时间）过长，可能是首屏图片或大JS文件加载慢，需检查图片格式和代码分割策略；若FCP（首次内容渲染时间）过长，可能是CSS阻塞，需内联关键CSS。WebAssembly在前端中的典型应用场景有哪些？WebAssembly（Wasm）作为二进制指令格式，可在浏览器中以接近原生的性能运行，适合计算密集型任务。典型应用场景包括：1.图形处理：如3D建模（Three.js结合Wasm加速网格计算）、图像编辑（WebAssembly实现的滤镜算法比JS快数倍）。2.科学计算：数值模拟（如有限元分析）、加密算法（AES/RSA的Wasm实现替代JS库，提升安全性和性能）。3.游戏引擎：将C/C++编写的游戏引擎（如Unity）编译为Wasm，在浏览器中运行高性能游戏，避免JS的单线程限制（结合WebWorkers实现多线程）。4.音视频处理：音频编解码（如Opus）、视频转码（FFmpeg的Wasm版本ffmpeg.wasm可在浏览器中实现视频剪辑）。5.复杂业务逻辑：如金融领域的高频交易计算、CAD软件的几何算法，通过Wasm将核心逻辑从JS迁移，减少主线程阻塞。需注意，Wasm与JS的交互存在性能开销（如数据类型转换），因此应将计算密集的核心逻辑封装为Wasm模块，仅通过接口传递必要参数（如数组指针、数值），避免频繁交互。目前主流浏览器（Chrome、Firefox、Safari、Edge）均已支持Wasm，且WebAssembly2.0规范正在推进，将支持多线程（SharedArrayBuffer）和SIMD（单指令多数据）指令，进一步扩展应用场景。ReactServerComponents（RSC）解决了哪些问题？ReactServerComponents（RSC）通过将部分组件在服务器端渲染，解决了传统SPA（客户端渲染）在首屏加载、SEO和资源体积上的痛点：1.减少客户端JS体积：RSC在服务器端渲染后直接返回HTML，相关组件的JS代码不会被打包到客户端bundle中。例如，一个依赖大量数据的仪表盘组件，其数据获取和渲染逻辑在服务器完成，客户端只需加载交互相关的组件代码，显著降低首屏JS体积（可能减少50%以上）。2.提升首屏加载速度：RSC可在服务器端并行获取数据（利用Node.js的异步I/O），避免客户端组件树逐层请求数据导致的瀑布流加载。服务器将渲染后的HTML和必要的客户端交互代码（如事件处理函数）一起发送到客户端，用户可见内容（HTML）的加载早于客户端JS的完全下载，改善LCP指标。3.优化SEO：RSC提供的是完整的HTML内容，搜索引擎爬虫可直接抓取到渲染后的内容，无需等待客户端JS执行（传统SPA需通过SSR或预渲染解决SEO问题，但RSC是更原生的服务器渲染方案）。4.支持访问服务器资源：RSC运行在服务器环境，可直接访问数据库、文件系统等客户端不可用的资源，无需通过API接口中转，减少网络开销（如直接从数据库查询数据并渲染到组件中）。需要注意的是，RSC需要与客户端组件（ClientComponents）配合使用，客户端组件通过'useclient'指令声明，可使用状态（useState）、副作用（useEffect）和浏览器API。RSC本身是无状态的，不能使用Hooks（除use），其设计更偏向于纯数据渲染和资源访问。如何实现一个高性能的Vue响应式系统？Vue3的响应式系统基于Proxy和Reflect实现，核心是通过track（依赖收集）和trigger（触发更新）机制管理响应式对象与副作用函数的依赖关系。高性能实现