前端两年经验中大厂面经（上）
两年这个节点，说尴尬也尴尬，说关键也关键。项目做了不少，但深度往往经不起追问；八股文背得滚瓜烂熟，面试官换个问法就卡壳；简历投出去，中大厂理你的不少，但能走到终面的不多。这篇文章想把我这阵子面下来的实战记录整理出来，重点不是给你贴一套标准答案，而是还原面试官提问背后的逻辑——他们到底想通过这道题，判断你的什么能力。
先说清楚这篇面经的适用范围：两年左右经验、Vue/React 都写过但谈不上精通、目标是一线中大厂 P6 左右的前端岗位。我会按面试流程的完整链路来拆：一面考察核心基础、二面深挖项目细节、三面看工程视野与方案设计，外加一轮我踩过坑才总结出来的复盘清单。如果你正准备跳槽，可以拿着这篇文章当“考前串讲”来用。
这半个月我一共面了 4 家中大厂，拿到 2 个意向，1 个走完流程在排序，1 个挂在了二面。挂的那个让我反思了很久——不是技术不够，是思路表达太碎。所以这篇面经里，我不只写题目，更会把我当时怎么答的、哪里答得好、哪里答崩了，原原本本拆给你看。
1. 两年经验跳中大厂前：简历、项目与知识体系的优先级排序
很多人觉得面经是从自我介绍开始的，其实不是。真正决定你面试上限的，是你筛选简历、准备项目复盘、查漏补缺这三件事的优先级。如果这步没做好，现场超常发挥的概率约等于零。
1.1 简历编排：项目不是把需求写上去，是给面试官埋提问点
两年经验最容易犯的简历问题，是把项目写成“功能清单”：“负责 XX 模块开发，参与 XX 需求迭代，使用 Vue3 + TypeScript 完成页面开发”。这种描述对面试官来说，约等于什么都没写。
我花了一整个晚上改出来的版本，核心思路只有一个：每个项目都必须有技术挑战、有量化数据、有可追问的细节。比如我之前做过一个数据看板项目，初版简历只写了一句“实现了图表的动态渲染”。改成下面这样之后，面试官从头到尾都在追问这个项目：
- 使用 Web Worker 处理 5 万条以上的数据聚合，主线程阻塞时间从 2.3s 降到 300ms 以内。
- 封装通用图表配置解析层，将 ECharts 配置与业务数据通过 schema 映射解耦，新增图表类型不需要改动业务代码。
- 针对高频刷新场景做按帧渲染的 requestAnimationFrame 批处理，解决图表闪烁与卡顿，FPS 稳定在 55 以上。
改完之后你再看，每一条都是一个天然的追问点。“你这个 schema 映射是怎么设计的？”“为什么不用别的数据处理方式？”“FPS 是怎么测出来的？”——这些问题就是你向面试官展示深度的窗口，也是你准备阶段最该提前想清楚的。我把能预判到的追问全部写进了自己的项目文档里，一个问题对应一个回答，不用背，但要能讲明白。
1.2 项目复盘的深度：从“做了什么”升级到“为什么这么做”
简历上的每个项目，面试官大概率会挑一个追问到底。追问的深度一般分为三层：
- 第一层：项目背景和你的角色。这个基本都能答。
- 第二层：技术选型原因。这是分水岭。你会发现很多人答“因为项目需要”“大家都这么用”，这种回答在两年经验的面试里是致命的。
- 第三层：方案的演进与对比。面试官会问“你有没有考虑过别的方案？为什么没有用？如果数据量再增长十倍，你的方案还成立吗？”
我准备项目时给自己套了一个固定框架，每个核心方案都按这个结构去复盘：
背景 → 目标 → 方案选型与对比 → 落地细节 → 收益数据 → 如果重来会怎么做
举个例子，我那个项目用了 Web Worker，我会按框架拆成：背景是数据量太大导致页面卡顿；目标是降低主线程阻塞；方案对比了懒加载、虚拟滚动、Web Worker 三种；落地时遇到数据迁移和产物加载的问题；收益是阻塞时间降到 300ms；重来会考虑用 SharedArrayBuffer 做更高效的数据交换。这个框架打下来，面试官的追问基本都在你的射程范围内，即使超出，你也能顺着框架往下推。
1.3 知识体系查漏补缺：三个最快暴露短板的检测项
两年经验去面试，时间是最稀缺的资源。我没有时间去把《JavaScript 高级程序设计》再翻一遍，而是用一套“检测式”的方式定位短板：
- 打开一篇文章或文档，闭上眼，试着用自己的话把核心机制讲给一个新人听，讲不清楚的地方就是短板。
- 看高频面试题的追问链，比如“闭包是什么”答上来了，再问“闭包是如何回收的？为什么会有内存泄漏场景？”能不能接住。
- 直接做面经题，但做完必须能讲出“这题考察的是哪个知识点，面试官下一个问题可能是什么”。
我当时用这个方式检测下来，最薄弱的三块是：事件循环的宏任务/微任务边界、浏览器缓存协商细节、React 合成事件与原生事件的关系。这三块我第一版复习时以为都会，一追问就露馅。把它们单独列进重点清单之后，心里才踏实了一些。
2. 一面基础关：面试官不是要标准答案，是看你怎么组织思路
一面通常是一场 45~60 分钟的电话或视频面，考察范围是 JS 基础、CSS/浏览器、框架基础，再加上一两道代码输出题。我的体感是：两道经验以下的面可能偏背题，但中大厂的一面已经全面转向“理解深度 + 表达逻辑”。下面是我实际遇到的几个典型问题，我把当时的回答思路和面试官追问的节奏都还原出来。
2.1 “说说事件循环，宏任务和微任务的执行顺序”——从背答案到讲机制
这是个必考题，但不难拿分。很多人背的是“同步任务先执行，然后微任务，再宏任务”，这算 60 分。想拿高分，得把这个机制讲成一套完整的运转逻辑。
我当时的回答主线是这样的：JavaScript 是单线程的，为了避免代码阻塞，采用事件循环来调度任务。执行环境分为调用栈（call stack）、任务队列和微任务队列，同步代码直接入栈执行；遇到 Promise.then 会将其回调放入微任务队列；遇到 setTimeout 这类 API，浏览器会新起计时线程，到时间后将回调放入宏任务队列。每一轮事件循环，先处理完当前调用栈，然后清空整个微任务队列，最后才会取一个宏任务执行。每执行完一个宏任务，都要重新检查微任务队列。
面试官听完后会顺着追问一句：“那await后面的代码呢？是同步还是微任务？”这里有个常见误区，能把坑讲清楚才算真正理解了。await右侧的表达式会立即执行，但await之后的代码会被当作微任务处理。我当时是这么答的：await相当于Promise.resolve(x).then(...)的语法糖，所以await之后的代码在微任务队列中执行。如果右侧是一个立即 resolve 的 Promise，它的.then回调会在当前宏任务结束时执行，但await本身不会阻塞事件循环。
这道题我后来复盘时发现，面试官真正想验证的是你有没有形成“单线程 + 队列 + 调度机制”的心智模型，而不只是背会了顺序。所以我后来跟朋友交流时也反复强调：准备事件循环考点，不能只背口诀，要能把浏览器从解析到执行的机制串起来讲一遍，才真的稳。
2.2 代码输出题：想清楚变量提升、this 指向和作用域链的联动
场景化追问之后，面试官直接甩了一道代码输出题：
var a = 10; function foo() { console.log(a); var a = 20; } foo();这道题简单，输出是undefined，因为变量声明提升到了函数顶部，但赋值没有。真正容易翻车的是同一类题的进阶版：
var a = 10; function foo() { console.log(a); let a = 20; } foo();这段代码不是输出undefined，而是直接抛错。我在现场简单说了一下原因：let有暂时性死区，在声明之前访问会报 ReferenceError。面试官紧接着追问：“那如果用const呢？如果foo是在对象里，this指向会有影响吗？”
这个问题让我意识到，代码输出题在两年经验的面试里绝对不是背答案，而是连环套。你每回答一个问题，面试官就往底层再推一层。我的建议是：复习时不要只看题目本身，要把题目背后的知识点连成线。变量提升、块级作用域、暂时性死区、this 绑定规则、箭头函数、闭包，这是一条完整的知识链，任何一个环节断了，面试现场就会卡壳。
2.3 闭包的追问链：从定义到内存，再到实际应用场景
闭包算是我准备的比较好的一个点，所以面试官问多久我都不慌。但要注意，面试官绝不会只问“说说什么是闭包”。我当时遇到的是这样的连环问：
- “闭包是什么？”
- “闭包有哪些使用场景？”
- “闭包会造成内存泄漏吗？为什么？”
- “怎么解决闭包导致的内存泄漏？”
- “现在让你实现一个防抖函数，用闭包怎么设计？”
这五个问题是一个完整的递进。第一个答上来只是基础，第二三个看你有没有实际项目经验，第四个考察你是不是只“听说过”而没有真正踩过坑，第五个是现场写代码，直接把理论落地。
我当时在实现防抖函数时，答完基本实现之后还讲了一句“注意 this 的绑定”。这个细节面试官明显比较认可，因为他追问了一句：“为什么还要绑定 this？”我给出的理由是：如果不绑定，事件监听器中的 this 会指向 window，这在某些场景下会有问题；bind 可以让函数在调用时保持正确的上下文。
这里给一个实操建议：复习闭包时，不要只背“函数返回函数”这个表面定义，要用“词法作用域 + 函数引用 + 变量生命周期”三个维度去理解。这样无论面试官怎么追问，你都能抓住本质。
2.4 CSS 与浏览器渲染：从“知道”到“能说清楚”
可能因为我的项目里会遇到布局和渲染，所以一面也问了浏览器渲染相关的题目，我印象深的是：“从输入 URL 到页面渲染，中间发生了什么？如果页面出现白屏，你会怎么排查？”
这个问题本质是综合题，但不要从 URL 输入开始背诵。我当时的回答分了三段：网络请求阶段（DNS、TCP、TLS、HTTP 请求）、解析阶段（HTML 构建 DOM、CSS 构建 CSSOM、两者合成渲染树）、渲染阶段（布局、绘制、合成）。然后我主动把问题引向了白屏排查，因为这才是面试官真正想听的细节。
排查白屏我给出了一套链路：先看 Network 面板确认请求有没有发出、返回是否正常；如果是 JS 报错导致白屏，看 Console；如果请求正常但页面仍然空白，看渲染流程是否被阻塞，比如是否存在同步加载的脚本、CSS 在首屏是否形成阻塞；还可以借助 Performance 面板看关键指标，比如 FP、FCP、LCP。这一整套链条讲完，面试官基本不会再追问，因为答案已经覆盖了网络、渲染、性能三个层面。
这里有一个两年经验的人特别容易踩的坑：只关注“页面没渲染出来”而忘了“网络请求可能根本没发出去”。我在实际排查中遇到过 Service Worker 缓存导致的影响，后来再答这类问题时会专门提到，面试官会对这个细节印象深刻。
3. 二面项目深挖：技术选型的“为什么”才是真正的分水岭
二面基本就是你拿最核心的项目去讲，时间约 50 分钟。如果说一面是考察你会不会，二面就是考察你有没有真的做过、有没有自己的思考。这轮挂了的人，大概率不是死在代码能力上，而是死在“讲不清楚为什么”。
3.1 一个追问到底的项目问题是加分关键
我主讲的第一个项目是工作第一年的数据大屏项目，就是我在简历里写了 Web Worker 处理大数据量的那个。面试官扫完项目简介后，第一个问题直奔要害：“当时你们的图表工具是怎么选的？为什么选了 ECharts 而不是别的？你刚才提到封装了 schema 映射，具体是怎么设计的？”
选型问题必须提前准备好。我当时的回答是：我们对比过 ECharts、AntV G2 和 Highcharts。ECharts 胜在社区活跃、文档全、对组件化配置的支持好；G2 更适合统计图表定制但写法偏繁琐；Highcharts 需要授权，商用有风险。最重要的是，ECharts 的配置项体系非常适合“通过 schema 数据驱动渲染”这个设计思路，我们可以把配置拆成统一的结构。
当面试官继续问 schema 映射时，我讲了一个核心设计：前端定义一个统一的图表描述结构，包含图表类型、数据源、坐标轴配置、交互事件等字段，然后在渲染层根据 type 字段分发到对应的 ECharts 配置模板。新增图表类型时，只需要新增一个模板函数，不影响其他部分。为了让面试官更好理解，我还主动举例说明：同一个 schema 换了数据源，可以生成折线图，也可以生成柱状图，业务层不需要关心具体的 ECharts 配置项。
这轮讲完之后，面试官追问了几分钟“如果数据结构变了怎么兼容”“你们如何做版本迭代”，这种偏工程运维的问题只要不慌，按自己实际遇到的场景答就好。核心是要展示：你不是做了一个一次性工具，而是考虑了扩展性与维护性。
3.2 性能优化这个问题不能只背指标，得讲数据链路
两年经验的面试里，性能优化几乎必问，而且问法往往是：“你们项目做过哪些性能优化？具体收益是多少？”
我的建议是：把项目优化做成一条可量化的数据链路。不要只说“做了代码分割”“用了懒加载”，而是讲清楚：优化前是什么状态，优化后是什么状态，用了什么方法，影响面是什么。
我当时整理出来的一套回答模板是这样的：项目是一个面向运营的后台系统，首屏加载时间在 3G 网络下约为 4.5s。我们做了三件事：路由级代码分割，把首屏 JS 从 1.2MB 拆到 680KB（这是代码体积层面的变化）；把项目依赖的三方库通过 externals 结合 CDN 加载，减少打包体积；对首屏接口做并发请求合并，减少网络往返。最终首屏加载时间优化到约 2s 左右。
这里有个细节需要提前想清楚：面试官会追问“你是怎么测出 1.2MB 这个数的？是 gzip 之后还是之前？”如果你说不清，前面的量化就会变成减分项。我当时直接给出的是 gzip 之前产物 1.2MB、gzip 之后 460KB 这样一组实际数据，并且说明了用 webpack-bundle-analyzer 定位的大文件来源。这种“指标—定位—方案—收益”的完整链路，能让面试官直接认可你的工程能力。
3.3 讲项目时的沟通技巧：不要陷入无效细节
二面最耗时的部分很容易变成“面试官对着你没有头绪的代码抠细节”。我吃过一次亏：有一次我在讲一个组件时，面试官问“你的组件库为什么要有这个 API？”，我当时太想展示技术细节，结果绕进了一个并不重要的内部实现，越讲越乱。
后来我给自己立了一个规矩：每次回答都按“结论先行，细节按需展开”来组织。先告诉面试官：这个项目做了 A、B、C 三件事，分别解决了 X、Y、Z 问题。面试官对哪个感兴趣，再展开细节。这样可以有效把主动权握在自己手里，也能避免自己沉浸在无关的细节里出不来。这种结构化表达习惯，不仅是二面，后面的三面同样重要。
4. 三面系统设计与工程认知：两年经验也要有产品思维
三面一般由技术专家或部门负责人来做，题目开始脱离你简历里的具体项目，转向偏架构和场景设计。两年经验的人很容易在这一轮露怯，因为很多时候我们只负责实现某个模块，很少站在全局视角考虑问题。
4.1 一套通用的场景设计题答题框架
我遇到的三面题目是：“如果让你设计一个团队用的中后台前端脚手架，你会怎么设计？需要支持多项目复用、不同技术栈选择、可定制化。”这种题没有标准答案，但也不是让你天马行空地聊，而是要按一个逻辑框架来推。
我当时按五个维度展开，面试官的反馈还算积极：
- 需求边界：明确脚手架要解决什么问题，是搭一套 UI 组件库，还是包含工程化配置、代码规范、CI/CD 的完整开发流程。
- 技术选型：结合团队现状。如果团队已经重仓 Vue 3，脚手架默认模板用 Vue 3 + TypeScript + Vite；但同时保留一个 React 模板入口，避免未来技术转型时的迁移成本。
- 核心能力拆分：把脚手架拆成模板（template）、生成器（CLI）、配置层（preset）和插件机制。模板负责初始化项目结构；CLI 负责交互引导；preset 负责按选择生成不同配置；插件机制则让团队能够按需扩展。
- 可拓展性：设计组件库接入方案，让脚手架生成的项目能够一键接入统一登录、请求封装、权限路由等基础能力，而不是每个项目重新造轮子。
- 维护成本：提供 monorepo 管理脚手架与模板，方便持续发布新版本；用自动化工具做升级提示，减少团队升级成本。
讲完这个框架，面试官直接追问了一个工程问题：“你有没有考虑过团队里有一些项目用的是老版本 Webpack，你的新脚手架如何与之兼容？”我当时因为准备过 monorepo 和工程迁移，所以能接上：新老项目可以通过统一配置中心接入，老的 Webpack 项目先接业务层再逐步迁移构建链路，降低一次性迁移风险。
这类场景题的核心是让面试官看到你的思考结构，而不是具体某个方案。只要框架清晰，即使细节不够完善，也能拿到不错的印象分。
4.2 工程认知题：“怎么做前端稳定性建设”不能从零开始吹
三面另一个几乎躲不掉的题目是“聊聊你们团队的前端工程化建设”。我遇到的具体问法是：“如果让你负责一项前端稳定性建设，你打算怎么做？”
这个问题的坑在于：很多人会从“上线一个监控平台”开始讲，但面试官想听的其实是“你有没有系统性识别过稳定性风险，有没有改进过流程和工具”。我的回答分成三层：
- 监控层：通过采集 JS 错误、资源加载异常、接口请求报错，同时加上性能指标（FP、FCP、LCP、TTI），建立基础的可观测能力。在这上面还要做数据透出和告警，不然数据有了没人看，白搭。
- 预防层：依托代码审查规范、自动化测试、灰度发布来降低回归风险。前端侧可以增加冒烟测试插件，把核心链路的关键断言固化下来，每次发版前自动跑。
- 响应层：提供线上问题快速定位工具，比如把 source-map 上传到内部平台，做到生产环境报错能自动映射到源码位置。
我再三强调“基础的可观测能力”，是因为很多团队连这一步都没有做扎实，就在空谈稳定性。面试官常年听候选人画饼，听到一个扎实落地的方案反而会多给分。
4.3 算法与手写题实操：准备时间和剑走偏锋的技巧
中大厂基本都会有一轮算法手撕，但两年经验一般不会上来就是 hard 题。我实际遇到的有：实现一个快排、数组去重（要求至少三种方法并说明复杂度）、两数之和（双指针）、手写防抖节流。
我的建议是：如果时间紧张，不要盲目刷 200 道题，而是把重点放在高频且分类清晰的题目上，比如数组、字符串、指针、滑动窗口、基本排序。每道题尽量掌握至少两种解法，还要会分析时空复杂度。
我这次面试前特地把手写 Promise 系列（Promise.all、Promise.race、Promise.resolve）重新理了一遍，后面真的在一面中碰到了类似题。面试官会让你现场写代码时，一定要注意两点：首先，写之前和面试官确认一遍输入输出；其次，先写暴力解，再聊优化思路。这比憋着直接写最优解要安全得多，因为面试官想看你思考的过程，而不是只会背标准答案。
5. 复盘清单与给后来者的实战建议
这些天面下来，我最深的一个体会是：面经的价值不在“题会不会做”，而在于你能否通过别人的面试经历定位自己的短板，并且提前设计好应对策略。下面这份清单是从我的血泪经验里提炼出来的，你拿着可以直接对照使用。
5.1 面试节奏与状态管理
一天之内尽量不要安排超过两场面试，而且要保证两场之间至少休息两个小时。我第一篇面经里提到过体力消耗的问题——面到第三场，大脑短路概率会直线上升。每场面试后花 15 分钟把核心问题记录到备忘录，标注哪些答得好、哪些卡壳，这能显著提升下一场的表现。我在挂掉的那一面后复盘，发现就是凌晨连续开会精神太差，导致回答时语言组织混乱。
5.2 建立自己的高频考点白名单
梳理你投递岗位的 JD，把出现频率最高的技术关键词列出来，按优先级做成白名单。以“前端两年经验 + 中大厂”为例，我的白名单大概是：JavaScript 异步机制、浏览器缓存、闭包与内存、React/Vue 核心原理、性能优化、工程化与打包工具、微前端基础认知。每一项都要准备一个“为什么”层面的解释，而不仅仅是定义。
5.3 反问环节的加分技巧
很多面试官在最后会问“你有什么想问我的”，这是展示你思考深度的机会。千万不要说“没有”。我一般会问三个方向的问题：
- 团队目前在做的最有挑战的事情是什么？这能看出团队的业务方向和技术热情。
- 团队如何做技术决策与选型？这能判断团队的工程文化。
- 对这个岗位半年的期望是什么？这能侧面了解岗位的定位和产出要求。
问完这三个问题，面试官基本能感受到你不是只为了拿 offer，而是真的在认真思考“合不合适”。
5.4 准备面经时的资源整理方法
不要翻完十篇面经就开始背题，效率太低。我的方法是：把面经里的题目归类到自己的高频考点白名单中，每类知识点整理一个 3~5 分钟的自我介绍式讲解版。这既训练了表达，也顺带覆盖了大量考点。比如“事件循环”我整理了一版讲解稿；“项目性能优化”整理了一版量化的数据链路；每个都控制在可以口头讲完的篇幅。面试前只需反复过自己的讲解稿，比临时翻文档有效得多。
5.5 挂掉一轮之后的心态复盘
挂面并不可怕，可怕的是不知道挂在哪里。我挂掉二面后，第一时间联系内推人拿到了面试官反馈，核心是“技术深度足够，但表达过于零散，没有突出重点”。这个反馈直接改变了我后面面三面和四面的策略。所以建议大家：如果条件允许，一定要争取拿到真实反馈，哪怕只有一句话，也比自己瞎猜强十倍。
至于面经“上篇”，我准备得比较多的还是简历阶段、一面和二面的实战细节。三面之后的 HR 面、不同技术栈的考察差异（比如 React 和 Vue 的提问侧重点完全不同），以及 offer 谈判这些内容，我后续在下篇里再单独展开聊。如果你正在准备跳槽，先耐着性子把项目复盘做到位、把高频考点真正理解透，这两步比刷多少套题都管用。
