大厂前端面试全解析：高频考题背后的原理与实战经验

从去年到现在，我前前后后面了不少大厂前端岗位，从字节、蚂蚁到美团、拼多多都走了一轮。最近正好在整理自己的面经笔记，发现很多题目和考察维度其实是高度重复的，关键在于你只是背了答案，还是真的理解了背后的原理。这篇大厂面经我会按面试的真实节奏，把基础八股、框架原理、工程化实战、项目深挖、算法手写这些环节挨个拆开讲，每个高频题都附上我整理过的详解答案，也把面试官追问时的考察点讲明白。不管你是准备跳槽的老前端，还是准备校招的应届生，这份面经应该都能帮你少走不少弯路。

1. 大厂前端面试到底在考什么

1.1 面试的底层逻辑：不是背答案，是验证你有没有真做过

很多同学问过我，大厂前端面试是不是就是刷八股文、背面试题。我一开始也这么以为，但面过几轮之后才明白，面试官真正想验证的从来不是你记住了多少知识点，而是你有没有在真实项目里解决过问题。比如一个很经典的题目“React 的 key 有什么用”，背答案的人会说“key 是用来标识列表项唯一性的，帮助 diff 算法复用节点”，但面试官紧接着会问“那 key 用 index 会有什么问题”，这时候如果只会背答案而没在项目里遇到过列表删除、排序后状态错乱的场景，基本就答不出来了。

所以整个大厂面试的设计逻辑，本质上是通过一个个由浅入深的问题，去还原你曾经做项目时的思考过程。一面基础题考的是你的知识体系完整性，二面框架题考的是你对自己用过的技术栈的理解深度，三面工程化和项目深挖考的是你有没有大规模复杂性问题的处理经验。这就像搭积木，如果底层的基础知识有一块是空的，面试官通过连续追问很快就能探到底。

1.2 面试轮次与考察重心分布

大厂前端的面试流程通常有三到五轮，每一轮考察的侧重点区别还是挺大的。我根据自己的面试经历和身边朋友的反馈，把各轮次的侧重点整理成了表：

这个分布不是绝对的，有时候一面就会直接问框架原理，二面就深入项目细节，但整体逻辑是从“点”到“线”再到“面”的过程。一面考的是单点知识，比如“URL 从输入到页面渲染发生了什么”；二面考的是系统能力，比如“你的项目里怎么做性能优化的，为什么选这个方案”；三面则更多是开放性的，考察你在没有标准答案的问题面前怎么拆解和分析。

1.3 怎么高效使用面经，而不是被面经带着走

这里先插一个重要提醒：面经只是线索，不是标准答案。我见过有的同学刷了几百道面经题，把答案背得滚瓜烂熟，但面试官稍微换个问法就露馅了。正确用法是把面经当作“知识地图”，去定位自己哪些地方没掌握，然后对着每个点去深挖原理，最好能用写文章或者讲给别人听的方式倒逼自己输出。

比如我看到面经里出现“事件循环”这道题，我不会只背答案，而是会打开控制台自己写几个 setTimeout、Promise 嵌套的代码，实际跑一遍看输出顺序，并且思考为什么是这个顺序。这样即使面试官换一道没见过的变体题，我也能根据对机制的理解推导出来。建议每个知识点都按照“是什么—为什么—怎么做—有什么坑”这四步去准备，面试时基本不会有盲区。

2. 基础八股：JS、浏览器、CSS 的高频考点详解

2.1 事件循环与宏任务微任务：一道经典题的完整推导

事件循环可以说是前端面试的基础题之王，但也是我见过翻车率最高的题。很多同学能背出“先执行微任务，再执行宏任务”，但遇到复杂嵌套就懵了。比较经典的题目是下面这段：

console.log('script start'); setTimeout(() => { console.log('setTimeout'); }, 0); Promise.resolve().then(() => { console.log('promise1'); }).then(() => { console.log('promise2'); }); console.log('script end');

正确输出顺序是：script start -> script end -> promise1 -> promise2 -> setTimeout。原因在于，同步代码会先执行完毕，然后执行当前宏任务里的所有微任务，等微任务队列清空后，才会去取下一个宏任务执行。这里的关键是 Promise 的 then 是微任务，调回的是微任务队列，而 setTimeout 是宏任务，要等当前调用栈清空、微任务队列清空后才会执行。

面试官如果继续加深，会在任务里再塞一个 async/await，比如：

async function async1() { console.log('async1 start'); await async2(); console.log('async1 end'); } async function async2() { console.log('async2'); } async1(); new Promise((resolve) => { console.log('promise'); resolve(); }).then(() => { console.log('then'); });

这里容易错的地方在于，await 后面的代码相当于被放进了 Promise.then 里，所以 async1 start 和 async2 是同步输出的，然后输出 promise，随后微任务队列依次处理 async1 end 和 then，它们的执行顺序要看谁先进入微任务队列。这个问题想真正搞懂，建议把 microtask 队列和 macrotask 队列的概念完全画出来，并且要知道每调用一次 await 就会产生一个微任务。另外，Node.js 环境里还有 setImmediate、process.nextTick 的差异，面试官问到 Node 侧的话，要能区分 process.nextTick 实际上比 Promise.then 还要优先执行。

2.2 闭包与作用域链：从面试题到实际编码应用

闭包也是高频中的高频。面试官常问的是“什么是闭包，闭包有哪些应用场景和缺点”。基础回答是：闭包就是函数执行时，内部函数引用了外部函数的变量，导致外部函数执行结束后，变量没有被销毁，而是被内部函数持续持有。这个特性可以让函数拥有“私有变量”，但也容易造成内存泄漏。

我在项目里用得最多的场景是封装防抖节流函数。比如防抖的核心代码：

function debounce(fn, delay) { let timer = null; return function (...args) { if (timer) clearTimeout(timer); timer = setTimeout(() => { fn.apply(this, args); }, delay); }; }

这里的 timer 就是通过闭包被“记住”的变量，每次调用返回的函数时都能访问到上一次的 timer，从而实现取消和重置。面试官考察闭包时，往往会延伸到内存泄漏问题，这时要能说出如何释放闭包占用的内存，比如将 timer 置为 null，或者在组件卸载时调用清理函数。

还有一个经典陷阱：for 循环里用 var 声明变量并绑定事件，打印出来的却全是最后一个值。这就是闭包共享变量的经典问题。解决方案有改 var 为 let、包一层 IIFE、或者直接使用函数式编程的思路。能把这个问题讲清楚，再配合“为什么 let 可以解决”的解释（块级作用域产生了新的词法环境），闭包这一块基本就稳了。

2.3 浏览器渲染机制与缓存策略：输入 URL 到页面展示的全链路

这道题堪称大厂前端面试的“必杀技”，考察范围非常广，从网络到渲染再到性能都能覆盖。我常用的回答框架分成了五个阶段：DNS 解析与建连、HTTP 请求与响应、解析 HTML 构造 DOM 树、计算样式与布局、绘制与合成。

其中面试官容易深挖的点有三个。第一，CSS 和 JavaScript 的加载是否会阻塞渲染。CSS 默认会阻塞渲染，因为渲染需要样式计算；而 JavaScript 会阻塞 DOM 解析，因为脚本可能修改 DOM，所以 script 最好放到 body 底部或加 defer、async 属性。第二，回流（Reflow）和重绘（Repaint）的区别。回流是布局发生变化，比如改宽度、字体大小，需要重新计算元素位置和几何信息，开销大；重绘是样式变化但不影响布局，比如改颜色、背景。第三，浏览器缓存机制。强缓存优先，使用 Expires 或 Cache-Control；如果强缓存失效，则走协商缓存，通过 Last-Modified/If-Modified-Since 或 ETag/If-None-Match 询问服务器资源是否变化。

我面试的时候喜欢再补一个层叠上下文（Stacking Context）的概念，因为和渲染有关系。position 为 fixed、z-index 不为 auto、opacity 小于 1、transform 不为 none，这些属性都会创建新的层叠上下文，会影响元素在 z 轴上的层叠顺序。实际项目里用得比较多的场景是弹窗嵌套和动画层级，如果没掌握层叠上下文，调 z-index 调到怀疑人生都不知道问题出在哪。

2.4 CSS 布局与响应式：flex、grid、BFC 与垂直居中

CSS 这块，面试官一般不会问特别偏的用法，但会通过“垂直居中怎么做”这种开放题来考察你对各种布局方案的掌控程度。我总结过一行代码实现垂直居中的做法：flex 布局下，给父元素设置 display: flex; align-items: center; justify-content: center; 就同时解决了垂直和水平居中。如果你希望更兼容，也可以用绝对定位加 transform: translate(-50%, -50%)，但这种方案需要知道父容器有定位属性。

BFC（块级格式化上下文）也是面试里常出现的概念。面试官喜欢问“什么是 BFC，怎么创建 BFC，解决什么问题”。BFC 可以理解为一个独立的渲染区域，内部元素的布局不会影响外部元素。常见触发条件有：float 不为 none、position 为 absolute 或 fixed、display 为 inline-block 或 flex 或 grid、overflow 不为 visible。实际应用场景是清除浮动、防止外边距合并、阻止元素被浮动元素覆盖。我在项目里常用 overflow: hidden 触发 BFC，让容器内部的布局问题被隔离，不至于影响全局。

Grid 布局最近在面试里出现的频率也越来越高，面试官可能会问“grid 和 flex 分别适合什么场景”。我的经验是 flex 偏一维布局，适合导航栏、按钮组、列表这种在一条轴线上排列的场景；grid 偏二维布局，适合九宫格、仪表盘、整体页面框架这种需要同时控制行和列的场景。能分清楚这两个工具的适用场景，比背一堆属性更能让面试官认可。

3. React/Vue 框架面试题详解（重点章节）

3.1 React 高频题：Fiber、Hooks、受控组件与 key

React 是大多数前端大厂产品线的核心框架，所以这块的题量很大，考察也很深。很多人 React 用得熟练，但问到 Fiber 就卡住了。我的理解是：Fiber 是 React 16 引入的协调算法底层结构，把原本不可中断的递归渲染改造成了链表结构的可中断协调过程。每个组件都对应一个 Fiber 节点，这些节点通过 return、child、sibling 三个指针形成树状链表，这样 React 就能在渲染过程中随时暂停、继续或丢弃任务，配合优先级调度实现了时间切片。

Hooks 这边，面试官最爱问的是 useEffect 和 useLayoutEffect 的区别，以及自定义 Hooks 的设计。useEffect 是异步执行的，在绘制完成后触发；useLayoutEffect 是同步执行的，在 DOM 变更之后、浏览器绘制之前触发，可以用来测量布局或者避免闪烁。这里有个细节：如果你在 useLayoutEffect 里做了耗时操作，会阻塞页面渲染，所以大部分场景用 useEffect 就够了。

受控组件和非受控组件的区别也很常考。受控组件就是组件的渲染状态由 React state 控制，输入框每次变化都会通过 onChange 更新 state 然后再渲染回去；非受控组件则直接使用 DOM 自身的 defaultValue 或者通过 ref 获取值。受控组件的优势是数据流可追溯，适合需要校验、联动、表单管理的场景，但缺点是频繁 setState 会造成性能压力，所以需要结合 memo、useCallback 这些优化手段。

3.2 React 并发模式与优先级调度：新面试题的增长点

React 18 发布之后，并发模式相关的面试题明显变多了。比如“React 18 的自动批处理是怎么实现的”、“并发特性和传统渲染有什么区别”、“startTransition 是干什么的”。这些题如果只会用 React 而不了解设计思想，很难答得深入。

我的理解是，React 18 把 setState 的批处理范围从事件回调扩展到了 Promise、setTimeout、原生事件等所有场景，所以你在异步请求回来之后同时 set 多个 state，React 会把它们合并成一次渲染。这背后是 update lane 的机制，每个更新都会被分配一个优先级，React 根据优先级决定哪些更新是紧急的、哪些可以不紧急地延迟处理。

startTransition 的经典场景是搜索框：用户输入关键词这个更新是紧急的，需要立刻反馈；而根据关键词渲染大量候选列表是不紧急的，可以标记为 transition，让 React 在空闲时间再去渲染，避免输入卡顿。面试时如果能把这种“紧急更新和过渡更新的优先级区分”讲清楚，并配合实际项目经验，比如在哪个搜索场景中用了 startTransition 或者 useDeferredValue，面试官会认为你对 React 内部有真实的思考。

3.3 Vue 响应式原理：从 Object.defineProperty 到 Proxy

Vue 在字节、腾讯的一些部门里也还是很主流。Vue2 的响应式原理是基于 Object.defineProperty 对 data 的每个属性进行 getter/setter 劫持，在 getter 中收集依赖，在 setter 中触发更新。但这个方案有三个明显的痛点：无法监听对象新增和删除属性、无法直接监听数组索引的变化以及 length 的变化、对象层级较深时初始化需要递归遍历，性能差。

Vue3 改用了 Proxy 代理整个对象，可以拦截属性的读取、写入、删除、枚举等所有操作，所以新增属性、删除属性、数组下标修改都能被感知到。同时依赖收集和触发更新的粒度也更细，配合模块化编译优化，整体性能提升明显。面试时如果能把两者对比说清楚，并且补充“为什么 Proxy 性能反而可能更好”这个反直觉点，会很加分。

还有一个常考点是 computed 和 watch 的区别。我会这样答：computed 是基于响应式依赖进行缓存的，数据没有变化时多次访问直接返回旧值，适合做纯计算；watch 是监听某个数据的变化，触发回调，适合做异步操作、路由监听等有副作用的事情。能说出“computed 注重计算结果的缓存，watch 注重变化后的动作”这个总结，基本就覆盖了核心。

3.4 状态管理选型：Redux、Zustand、Pinia 怎么挑

项目里状态管理选型也是面试官爱深挖的点。Redux 是老牌答案，单例 store、单向数据流、reducer 纯函数这些设计思想非常清晰，但因为模板代码多、更新时组件容易不必要地重渲染，在中小型项目里反而显得笨重。

现在很多团队已经转向 Zustand 或 Pinia。Zustand 的核心特点是 store 是通过 create 创建的，组件可以用选择器订阅部分状态，selector 返回的引用没有变化时组件不会重渲染，这个机制大大减少了不必要的渲染。Pinia 是 Vue3 官方推荐的状态管理库，相比 Vuex 移除了 mutations，在组件里可以直接修改 state，写起来非常顺手。

面试时遇到状态管理选型题，我的回答思路是：如果项目复杂、有大量跨页面共享状态且需要中间件，选 Redux Toolkit；如果项目以组件树为主，希望轻量且对 TypeScript 友好，选 Zustand；如果用的是 Vue3 技术栈，优先选 Pinia，因为它本身就是为 Composition API 设计的。能结合具体项目的状态量、更新频率、跨模块复杂度来说明选型理由，比单纯背优劣势有用得多。

4. 工程化与微前端：面试官最爱的实战深水区

4.1 构建优化：webpack/vite 的分包、懒加载与 tree-shaking

工程化基础在大厂面试里属于必考，因为大厂的项目规模大，构建速度和产物体积是真实痛点。面试官常问“你们项目做了哪些构建优化”，这题需要你有实际数据支撑。我常用的优化思路有四个维度：减少模块解析范围、利用缓存、开启并行、优化产物输出。

具体到落地，webpack 项目里可以做：用 resolve.alias 缩短模块查找路径，用 noParse 跳过不需要解析的库，用 thread-loader 或 esbuild-loader 做并行转译和压缩，用 SplitChunksPlugin 把 node_modules 中的公共依赖提取成单独的 chunk，同时给 vendor 文件设置合理的缓存策略。懒加载方面，通过 React.lazy 和动态 import 做路由级别的代码分割，让首屏只加载当前页面需要的 JS 和 CSS，其他路由的页面模块等用户跳转时才去加载。

Vite 的构建优化思路和 webpack 不太一样，它开发环境走 esbuild 预构建依赖，生产构建用 Rollup 做打包，但相同的是都需要关注分包策略。Vite 4 之后还有自动按需加载依赖的特性，使用体验好了很多。我在讲解构建优化时，习惯用一个例子来说明收益：一个初始化三秒钟的项目，加了 thread-loader 和缓存之后，热更新能降到一秒钟以内，这个数据在面试时非常加分，因为说明你有真实的性能意识和优化指标。

4.2 微前端：qiankun/single-spa/Module Federation 怎么答

微前端是大厂前端面试的高频议题，因为很多大厂的业务系统多、团队多、技术栈杂，微前端是解决多人协作、独立发版、渐进式迁移的常用方案。面试官会问“什么是微前端，为什么要用微前端，你们是怎么做的”，也会问“微前端的通信方案、样式隔离、js 隔离机制是什么”。

我建议的答题主线是：微前端是把一个大应用拆分成多个可以独立开发、独立部署、独立运行的小应用，运行时再组合成一个整体。常见的实现方案有 single-spa、qiankun、micro-app、Module Federation。qiankun 是基于 single-spa 封装的，通过 HTML entry 的方式加载子应用，并且基于 Proxy 实现了 js 沙箱，样式隔离则通过给子应用样式加 scoped 属性或者 shadow DOM 方案实现。

样式隔离这里有个经典坑：qiankun 默认的样式隔离不是严格隔离，如果你在全局样式里写了一个 class 名，子应用里也有同名 class，可能互相覆盖。我们项目当时的解法是约定子应用统一使用带前缀的样式命名，同时在入口文件里手动隔离全局样式。另外子应用间通信可以采用 props 传递、全局状态管理、或者基于浏览器自定义事件，关键在于设计好通信契约，避免子应用之间紧耦合。

4.3 性能监控与错误上报：从埋点到告警的完整链路

大厂的产品日活高，性能监控和错误上报就非常重要，所以这个方向的题也经常出现。面试官会问“线上页面报错了，你们是怎么发现和定位的”或者“首屏性能怎么监控”。

错误上报的通用思路是：采集 window.onerror 捕获的运行时错误、unhandledrejection 捕获的未处理的 Promise 异常，以及 Vue 的 errorHandler 或 React 的 ErrorBoundary 捕获的组件层错误。把这些错误信息组合成一条包含时间、页面地址、UA、报错堆栈、用户身份等信息的日志，再通过创建的 image 标签或 Beacon API 发送到日志服务端，不影响用户正常请求。

性能监控方面，关键指标有 FCP、LCP、INP、CLS 这些 Core Web Vitals，可以通过 PerformanceObserver 去监听和采集。需要注意的一个坑是，在 componentDidMount 或 onMounted 里用 performance.getEntriesByType('paint') 获取的 FCP 有可能拿不到或者为零，原因是浏览器在某些情况下不会返回 paint 类型条目，这时候要退回到官方推荐的 PerformanceObserver 方式，持续监听条目回调。

如果面试问得再深一点，可以谈谈 SourceMap 错误还原。生产环境的代码经过了压缩混淆，报错堆栈基本不可读，所以上线时只把 SourceMap 上传到私有的错误监控平台，在平台上还原原始文件的行列号，定位到具体组件和代码位置。这里注意 SourceMap 绝不能被线上用户直接下载到，否则等同于暴露源码，这也是大厂安全审查里容易踩到的点。

5. 项目深挖与加分项：大文件上传、AI 结合、源码阅读

5.1 大文件上传完整方案：分片、并发、断点续传

这一段特别想展开讲，因为大文件上传几乎是我面试里被问次数最多的项目题。很多同学简历上写了“文件上传”，被面试官追问到分片和并发控制时就答不深了。先说一下完整的大文件上传思路：

第一步，前端拿到 File 对象后，用固定的大小（比如 5MB）把文件切成多个 Blob 切片，每个切片用文件 hash 加序号命名。切片之前要生成文件指纹，最简单的方式是计算整个文件的 md5，但大文件计算 md5 可能耗时较长，所以实践中会用增量算法，或者只取文件头部、中间、尾部的数据块做组合后计算 hash，提高计算速度。

第二步，上传前先向服务端发一个查询请求，服务端返回哪些分片已经上传过，前端跳过这些分片，只上传缺失的分片，这就是断点续传的思路。第三步，控制并发数，比如每次最多同时上传 3 个分片，使用一个任务队列维护待上传分片，每完成一个就从队列中取一个。分片全部上传完成后，前端再发一个合并请求，由服务端把所有分片按顺序拼接成完整文件。

关于并发控制，我在面试中讲解时会给出一段精简版代码：

async function uploadFile(file, chunkSize = 5 * 1024 * 1024, concurrency = 3) { const chunks = []; let start = 0; while (start < file.size) { chunks.push(file.slice(start, start + chunkSize)); start += chunkSize; } const queue = [...chunks]; const workers = Array.from({ length: concurrency }, async () => { while (queue.length) { const chunk = queue.shift(); // 这里发送单个分片的请求，带自定义头标识 await uploadChunk(file, chunk); } }); await Promise.all(workers); await mergeChunks(file); }

这个方案里还有一个面试官很容易追问的点：为什么用 Web Worker。大文件在计算 hash、读取切片、上传过程中，主线程的 UI 如果长时间被占用，会出现卡顿甚至白屏。使用 Worker 上传大文件，就可以把读文件、算 hash 等耗时操作放到后台线程，主线程只负责进度更新和用户交互。我在项目里是把文件切片和 hash 计算放到 Worker 里做，上传还是用主线程的 XMLHttpRequest，进度事件源源不断地返回，体验顺畅很多。

5.2 前端结合 AI 的实践：从 LLM 应用到 RAG 与 Agent

近两年大厂面试明显增加了 AI 相关的问题，毕竟大家都在做 AI 应用，前端作为用户入口，必然要掌握接入 AI 的方式。面试官可能问“有没有用过 AI 编程工具”“你们的项目里有没有 AI 功能”，或者直接给一个场景让你设计交互方案。

先说 AI 前端应用的典型形态。最常见的是聊天式交互，前端通过 SSE（Server-Sent Events）接收大模型流式返回的文本，逐字渲染到界面上。这比用 WebSocket 要简单，因为大模型返回本来就是单向流式的，SSE 天然支持，而且自动重连、事件字段解析都有规范。我在实际项目里就是通过 fetch 请求一个 POST 接口，设置 stream: true，然后从 response.body 的 ReadableStream 里读取数据块，用 TextDecoder 解码出文本增量，再追加到页面。这里有个细节：流式数据可能会被切割到半路，如果拿到的 chunk 末尾是不完整的 JSON，要先缓存拼接成完整数据再解析，不能图省事直接 JSON.parse。

再深入一层是 RAG（检索增强生成）的场景。当用户问“我们公司的请假制度是什么”时，大模型本身不知道公司内部文档，所以前端需要先从用户的输入中提取查询词，调用内部搜索接口取回相关文档片段，再把这些片段组装成 Prompt，随用户问题一起发送给大模型，让大模型基于这些片段作答。Anything-LLM 这类开源项目就做了类似的知识库问答应用，前端部分可以借鉴的设计包括：文档管理界面、向量数据库配置界面、对话页面、引用来源展示。

前端和 AI Agent 结合也越来越多。Agent 的核心是让 LLM 根据任务拆解步骤，调用外部工具（Tools），前端往往负责编排这些工具的调用入口和展示执行过程。你可以理解为原来只能聊天的 LLM 变成了一个有手有脚的执行者：用户说“帮我订一张明天早上从北京到上海的机票”，Agent 先调用航班查询工具，再调用预订工具，最后反馈结果，前端需要设计工具状态的可视化流程，让用户知道当前执行到哪一步。如果你做过类似的设计或开发，放在简历里属于非常强的加分项目。

5.3 大型开源项目怎么读：从 HZero 到微前端框架

面试官经常问“平时有没有读源码的习惯，读过哪些开源项目”。这个问题不是看你能不能把 React 源码背下来，而是考察你有没有一套读源码的方法论。我自己的实践是：先看项目文档和整体架构，然后从入口文件出发，沿着一条核心链路追踪代码，比如 React 的首次渲染流程，是从 ReactDOM.createRoot 到 render、beginWork、completeWork、commit 这整个过程。

如果想读一个大型企业级项目，HZero 是一个不错的例子，它是一个开源的企业级前端开发平台，集成了微前端、权限控制、字典管理、工作流等企业级能力。读这类项目的收获在于，你能看到真实业务里如何处理权限系统、如何处理数据字典、如何组织多模块结构。比如“前端系统管理下的字典管理一般有什么用”，其实答案是：字典管理用于维护和管理系统中可复用的枚举数据，比如性别、状态、类型等，通过前端配置字典项，业务页面能直接下拉选择，不需要每次修改都发布新版本。这类项目的代码量很大，不建议一行行读，而是找自己熟悉的功能模块，从功能入口逐步追踪到数据流向。

读源码的时候我强烈建议配合调试工具做断点，在关键函数上打 console.log 或者 debugger，观察变量在真实运行时的值，比光看代码容易理解得多。另外一个技巧是：先看类型定义和接口定义，再读实现。TypeScript 的类型声明几乎就是项目的“目录结构”，能帮你快速定位每个文件的作用。

6. 算法与手写题避坑指南

6.1 高频手写题：防抖节流、深拷贝、Promise、new、数组扁平化

手写题是大厂前端一面和二面里几乎跑不掉的环节，而且往往是在面试最后突然来一道，专门测试你的临场编码能力。我整理过一份高频手写题清单，下面这些基本可以闭着眼睛写出来：

• 防抖（debounce）和节流（throttle）：要能现场实现，并且能说清楚两者各自适合的场景。防抖适合搜索输入停顿后再请求，节流适合滚动事件和 resize 事件，保证每隔一段时间至少执行一次。
• 深拷贝：考察你对该写递归、如何处理循环引用、如何处理 Date、RegExp、Map、Set 等特殊类型有完整的实现思路。简单写法是利用 JSON.parse(JSON.stringify())，但缺点是不能处理函数、undefined、Symbol、循环引用，面试时要能说清楚。
• Promise 的手写：不一定要求写全 Promise/A+ 规范，但至少能实现一个简易的 Promise，包含 resolve、reject、then、catch 以及链式调用的基本原理。
• new 操作符实现：要能手写一个 _new 函数，步骤是创建新对象、将新对象的原型指向构造函数的 prototype、执行构造函数并把 this 绑定到新对象、返回对象或构造函数显式返回的对象。
• 数组的扁平化和去重：数组扁平化可以用递归、reduce、正则、flat 循环等方法实现，去重可以用 Set、filter、reduce 等。

我分享一个现场的技巧：手写题不要闷头写，先和面试官确认需求。比如深拷贝是否要处理循环引用、是否要处理 Symbol 属性。先确认再动手，既能展示你的沟通能力，也避免自己坐到一半发现漏掉了需求而改代码。

6.2 算法题备考建议：刷哪些题、怎么刷、怎么分析

前端面试的算法难度整体低于后端，但大厂核心团队依然会出 LeetCode 原题或变体。我的建议是刷题重点放在数组、字符串、链表、栈、队列、二叉树、哈希表、双指针、滑动窗口这几个高频类型上，动态规划可以掌握基础题，比如爬楼梯、最长递增子序列、背包问题，但不需要刷到困难级别。

刷题的方法论比数量重要。我通常是先独立思考 20 分钟，如果完全没有思路就看题解，理解后关掉编辑器，自己重新从零写一遍，然后再去随机找两道同类型的题目加深印象。这样刷一周左右，比一天刷二十道但是全部直接抄题解有效得多。

面试现场写算法题时，时间复杂度和空间复杂度的分析不能漏掉。很多同学能写出正确代码，却无法解释为什么这个解法是 O(n) 的、空间优化是怎么做的，这在评价维度上可能会降一档。常见套路是：先给出暴力解法并分析复杂度，再逐步优化到最优解，最后说一下有没有更优的方案。这个逐步递进的过程，面试官比直接看到正确答案更感兴趣，因为考察的是你的思维过程。

7. 面试过程中的常见问题与避坑技巧

7.1 项目介绍怎么讲：用 STAR 法则讲清楚业务背景和难点

项目深挖是大厂面试的压轴戏，也是很多候选人发挥不稳定的环节。我的经验是，一个项目讲 3 分钟左右比较合适，不要超过 5 分钟，关键在于逻辑链条要清晰。我用的框架是 STAR 法则，也就是背景（Situation）、任务（Task）、行动（Action）、结果（Result）。

比如我讲一个和性能优化相关的项目时，会说：“这个系统是面向运营用户的报表平台，最初首屏加载需要 8 秒（背景），我的任务是优化到 3 秒内（任务）。我做了三件事：路由懒加载、图片 WebP 化、接口并发请求合并（行动）。优化后首屏时间降到 2.4 秒，LCP 提升 65%（结果）。”这样讲完，面试官很容易抓到重点，也知道从哪里开始追问。

项目里一定要准备一两个可以深入讨论的“技术亮点”，比如复杂交互、大规模数据渲染、异常处理机制、权限设计。准备好“为什么选这个方案”“有什么备选方案”“如果重新做你会怎么改”这三个维度的答案，基本上项目深挖这一轮就能稳住。

7.2 不会的问题怎么处理：承认不会但展示思路

面试中一定会遇到不会的问题，这是正常的。我的处理方式分三步：第一，先确认自己对问题本身的理解没有偏差，可以复述一遍题目；第二，把能想到的相关知识先说一部分；第三，如果确实完全不会，直接说“这块我没有深入研究过”，避免乱编。

乱编在大厂面试里是大忌。面试官对某个领域非常熟悉，你编出来的答案很容易被抓住破绽，一旦被拆穿，影响的不只是这一题，而是整个面试评价。相反，如果你能诚实地承认不会，但把话题引向你熟悉的相关领域，比如“Promise 的细节我记不太清了，但我平时经常处理异步流程，可以讲一下我如何设计一个带并发限制的异步队列”，反而能让面试官看到你的应变能力和学习能力。

7.3 面试后的复盘与节奏：两轮面试之间应该做什么

面试后的复盘比多投几家简历更重要。我每一轮面试结束后，当天就会把被问到的问题记录到笔记里，标注哪些答得好、哪些答得不好、答得不好的原因是什么（是知识盲区还是表达失误），然后针对性地补充复习。两轮面试之间通常有几天到一周的时间，我会把上一轮暴露的问题集中突破。

有一个我踩过的坑想提醒大家：太过于相信“面经”里别人描述的答案，而忽视了对方可能是从更高阶的视角回答的。比如面经里有人说“性能优化的关键是减少请求数”，但实际面试官追问的是“你们怎么用 PerformanceObserver 去测量和量化优化效果”，这完全是两个层次。所以面经只能给你划定边界，真正的深度要靠自己去实践和积累。每次面试都是对知识体系的一次检阅，保持“把不懂的搞懂”的心态，才是面试之旅最有价值的收获。