企业官网建设流程全解析

有些话我憋了几天，不写出来难受。前两天面试了一位工作八年多、简历上写着“精通 React”“深入理解浏览器渲染原理”的资深前端候选人。面试四十分钟，前面聊项目还说得过去，进入基础概念追问环节后，连续几个核心问题都接不住。最让我意外的是他自己也挺坦然：“我平时写的都是业务代码，这些原理确实没太研究。”

这句话我其实经常听到，但每次听到还是会很感慨。八年经验、做过大屏、做过后台、带过小团队，业务能力不差，可一旦绕过“用过什么”去问“为什么这样设计”“底层到底发生了什么”，就立刻断档。这让我觉得很有必要把这次面试复盘一下，顺便把前端真正的核心概念清单、面试官考察逻辑、以及系统补课路径都整理出来。相信对正在准备跳槽的人、负责招人的团队，以及每个想从“业务熟练工”往“工程师”走的人，都有一点参考价值。

1. 这次面试的来龙去脉：不是背不出八股，是真没理解

1.1 候选人画像与现场氛围

候选人背景放在市场上并不差：八年多经验，最近两家分别在互联网公司和外包驻场，做过的项目是典型的前端业务盘——管理后台、审批流、数据大屏，技术栈是 React + antd + ECharts。简历上有几条优化经历很亮眼，比如“首屏时间从 3.2 秒降到 1.8 秒”“大屏内存占用降低 40%”。说实话，看完简历我的第一印象是：这人应该很稳。

开场聊最近项目时，他确实能讲清业务逻辑：大屏有多少个图表、接口怎么对接、告警怎么推送。但我很快就发现一个问题——当问到“当初为什么用 WebSocket 做实时推送，而不是轮询”，他的回答是“一般做实时都用 WebSocket 吧，需求就是这么定的”。我接着问“有没有对比过轮询在低并发场景下的成本和延迟”，他愣了几秒，说“这个真没想过”。

到这里我还没有太在意。很多工程师确实不会主动质疑既定方案，这不算硬伤。真正的分水岭在后面：一旦我把话题从“项目经验”切到“核心概念”，整个对话就变得非常干瘪。他不是紧张，也不是表达能力差，而是真的没有建立起对前端底层机制的理解。

1.2 三个让我印象深刻的翻车现场

翻车现场一：React 渲染原理。

我问：“setState 之后，React 内部从调度到提交到底发生了什么？”

他答：“就是触发重新渲染，更新 DOM 呗。”

我追问：“那 React 怎么知道哪些组件需要更新？整个应用重新渲染吗？”

他开始支吾：“应该……是比较一下虚拟 DOM 吧，有 diff。”

我再追问：“diff 的 key 到底是干什么的？两个列表对比时拿来做什么？”

他说：“用来找差异的吧，让虚拟 DOM 能对上号。”

我接着问：“如果列表中间某项被删掉，key 用了 index，会出什么问题？”

他犹豫了一会儿，说：“可能整个列表都会重渲染。”

其实到这里我判断他已经踩到边了，但只是“记住结论”，没有把 key 与节点复用之间的关系真正理解透。等我把Fiber搬出来问：“React 16 为什么要引入 Fiber？它解决了什么问题？”他沉默了一下，回答“应该是架构升级吧”，然后就没有然后了。

翻车现场二：闭包与作用域。

我问：“你写一个节流函数吧，就按 scroll 事件高频触发的场景来。”

他写出来一个时间戳版本，功能基本对，但只处理了“第一次立即执行、后续间隔内不执行”这个逻辑。我追问：“如果用户一直滚动，最后一次滚动想让函数在停止后延迟再执行一次，你打算怎么办？”他答不出来。这不是刁钻问题，而是防抖与节流的核心区别：节流保证执行频率，防抖处理尾触发，两个函数结合才是最贴近真实业务的形态。

再往下问闭包本身：“闭包为什么能保存外部变量？闭包占用的内存什么时候释放？”他回答：“因为函数引用了外部变量，所以不会回收吧。”我问他怎么主动释放，他说“等页面关了应该就没了”。

最典型的一幕是他写完节流函数之后，我指着代码里的let问：“这里为什么要用 let 而不是 var？”他说“作用域的问题”。再追问：“var 和 let 在编译之后有什么区别？放在执行上下文里看呢？”他直接笑了，说这个真没深究过。其实这个问题只要能讲出词法环境和变量环境，就已经是合格答案，可惜他没接住。

翻车现场三：从输入 URL 到页面呈现。

这个题是前端面试最经典的综合题。他能从 DNS 解析、TCP 连接、HTTP 请求、服务器返回 HTML、然后渲染，说出来一个大概框架。但细节全崩。

我问：“HTML 解析过程中遇到同步 script，为什么会影响 DOM 解析？”

他答：“因为脚本要执行吧，所以会阻塞。”

我再问：“CSS 会不会阻塞渲染？”

他说：“会。”

我问：“那 CSS 加载慢的时候页面表现是什么？怎么去避免？”

他想了半天，没有提到骨架屏、没有提到把非关键 CSS 拆出来、没有提到preload，也没有提到 CSS 放头部背后的浏览器解析机制。我给了个提示“你遇到首屏白屏，一般第一步怎么定位”，他只能说出“看请求多不多”，再往后就没什么方向了。

这三个翻车现场连着出现之后，我心里基本有数了。他不是没有项目经验，而是多年经验停留在“API 调用 + 业务迭代”这个层面，没有往下一层去构建知识体系。面完我甚至觉得有点可惜——他会做很多事，但讲不清任何一件事背后的原理，这在今年这种越来越看重原理与场景结合的前端面试里，几乎是一票否决的。

1.3 “资深”两个字到底卡住了什么

这次面试完了之后，我在复盘笔记里写了三句话：

• 初级工程师负责把功能做出来，重点是会用 API。
• 中级工程师负责把功能做对，重点是理解机制与边界。
• 资深工程师负责把功能做透，重点是能解释“为什么”，还能带别人一起做对。

这三句话并不是面试官的标准答案，但基本是我判断一个人价值的方式。为什么核心概念这么重要？因为线上 99% 的疑难杂症，答案都藏在原理层里。页面卡顿要理解渲染机制，内存泄漏要理解引用关系和生命周期，列表优化要理解 diff 与 key，白屏问题要理解 HTML/CSS/JS 解析阻塞的先后顺序。一个不理解这些的人，遇到非典型问题就只能靠猜、靠试，而资深工程师靠的是定位。

所以我反复给候选人强调：面试官考核心概念，不是为了“背八股”，也不是想用犄角旮旯的题考倒你。真正的目的只有一个——看你遇到问题的时候，能不能从原理出发建立排查路径。这是资深和“面霸”之间最大的分界线。

2. 资深前端必须过关的核心概念清单

2.1 JavaScript 基础：闭包、原型链、Event Loop 的底层关系

先说 JavaScript 这一层，我把它当成语言内核。业务代码可以写得飞快，但语言内核不建立起来，后面学框架、学原理都是空中楼阁。

闭包是我最喜欢问的点，因为它能看穿一个人是否理解“作用域链”和“执行上下文”。闭包的成因很简单：函数内部引用了外部函数的自由变量，并且这个内部函数被返回了，导致外部函数执行完毕后，它的变量对象依然被内部函数引用，无法被垃圾回收。这就是闭包的本质，也是闭包占内存的来源。理解它之后就能理解两个问题：为什么要慎用闭包，以及闭包什么时候会释放内存——答案是当你把这个内部函数本身的引用也切断时。

闭包的真实应用场景非常多，不只在节流防抖里。柯里化、私有变量、模块化、React 里 Hooks 的 capture value，底层都依赖闭包机制。面试最佳实践是自己写一个useThrottle这样的自定义 Hook，把防抖节流和闭包串在一起演示一遍，比背概念强十倍。我平时处理这类问题也建议：写完代码后，一定要主动说出哪些变量被闭包保留了、生命周期终点在哪里、Codereview 时会不会提醒同事注意内存释放。能说到这一步，才算真正掌握闭包。

原型链则是一条更古老的继承路线。每个函数都有prototype，每个实例都有__proto__指向构造函数的prototype，实例上找不到属性就往原型链上找，直到Object.prototype。所以方法放在原型上，是为了让所有实例共享同一份方法，省内存、也方便扩展。为什么new这么重要？因为new做的事就是：创建新对象、把新对象__proto__指向构造函数prototype、执行构造函数绑定this、返回该对象。每次我看到候选人只会用 class 而说不清 class 本质是原型链语法糖的时候，就知道基础没吃透。

Event Loop 是异步机制的总开关。宏任务和微任务的执行顺序是：同步代码执行完，清空微任务队列，微任务里新产生的微任务继续执行，再取一个宏任务……如此循环。setTimeout 为什么会不准时？因为它还要等微任务队列和其他任务排完，最多只能保证“不早于设定时间”执行。Promise、async/await 本质都在微任务队列里排队。让候选人分析一段含console.log、setTimeout、Promise、async函数的代码打印顺序，几乎能一瞬间看出他懂不懂事件循环。在真实场景里，高频界面卡顿往往就是因为微任务过多、主线程被不停插入的任务撑爆，这不是单纯的 API 问题。

这四样东西本质上其实是一件事——JavaScript 到底怎么把变量和函数组织起来的。作用域链和闭包是一套，原型链是另一套继承体系，Event Loop 是异步世界的运行规则。它们共同构成了语言的三根顶梁柱。能把这三点串起来讲的候选人，语言关基本过了；串不起来的，后面全是裂缝。

2.2 浏览器与网络：从输入 URL 到页面呈现的全链路

网上一搜“前端面试题 2026”，大概率少不了“输入 URL 到页面呈现”这道题。但大多数人回答这个问题的时候，只是把八股顺口溜一样背一遍，很少有人能讲到链路每一站为什么是那样设计的。我观察下来，能讲透的人通常是对网络和渲染机制分别建立过心智模型的。

网络链路这一半相对容易。DNS 解析负责域名到 IP 的转换，中间有缓存机制。TCP 三次握手的目的要能讲出“确认双方收发能力、防止历史连接初始化”这层含义。TLS 握手这些年越来越重要，证书验证、密钥交换，为什么 HTTPS 成本高但值得用，应该能说个大概。HTTP 协议演进也要跟上：HTTP/1.1 的队头阻塞、HTTP/2 的多路复用解决了一部分问题但没完全解决，HTTP/3 换到基于 UDP 的 QUIC，减少连接建立的往返次数。这些概念和工作关系不大，但决定了一个工程师能不能在“接口慢、请求多、连接建立占用时间长”这类问题里找到优化方向。

渲染链路这一半才是重头。浏览器拿到 HTML 之后开始解析，生成 DOM 树，同时解析 CSS 生成 CSSOM 树，两棵树合并成渲染树，然后进行布局计算、绘制、合成。重点在于解析过程中遇到同步脚本会阻塞 DOM 构建，CSS 放在头部、JS 放在底部就是基于这个机制；defer和async的区别则是：defer等文档解析完成后按顺序执行，async下载完立刻执行、可能乱序。重排是几何属性变化引起的布局重新计算，重绘是样式变化引起的绘制更新，减少重排的手段包括批量 DOM 操作、脱离文档流、使用transform触发合成而不是触发布局。

缓存策略也是必考点。强缓存和协商缓存的区别、服务端怎么配合下发、发布新版本时怎么避免客户端缓存旧文件，这里我整理过一个表，面试时挺好用的：

实际项目里最稳妥的做法是：静态资源用强缓存，文件名加 hash，确保内容一变文件名就变；HTML 入口文件用协商缓存或no-cache，保证每次发布后能拿到最新引用。这套方案我在多个后台系统和大屏项目里验证过，简单有效。

最后提醒一个容易忽视的点：白屏问题的定位路径。看到白屏不要慌张，先按顺序看——请求是否返回正常、网络面板里有没有红色失败、Console 有没有 JS 报错、DOM 树里关键节点是否存在、CSS 是否有资源加载失败。大多数白屏不是单一原因，而是 JS 报错 + 样式缺失 + 接口异常叠加导致的，能按链路结构化排查，才算真正掌握渲染机制。

2.3 框架原理：React 和 Vue 不是“拿来用”就行

框架这一层是市场行情价的分水岭。能用 React 写页面的人遍地都是，能讲清 React 从状态变化到 UI 更新全链路的人少得多。

先说 React。JSX 会被编译成React.createElement调用，生成 element 对象，也就是我们常说的虚拟 DOM。状态变化之后，React 会生成新的 element 树，和新旧两棵树做 diff，找出变化点，再更新真实 DOM。这里有个经典陷阱：虚拟 DOM 不一定比直接操作 DOM 快，它的价值在于隔离了浏览器差异、让更新以最小代价落在真实 DOM 上，同时为跨端渲染提供了基础。面试的时候如果只会说“虚拟 DOM 更快”，我会立刻扣分。

key 的作用要从节点复用角度理解。新旧列表对比时，React 通过 key 判断同一个节点能否复用，而不是重新创建。如果用 index 当 key，列表项顺序一变，React 会误认为所有节点都变了，导致本该复用的状态被重置、大量节点被重建，性能损耗非常明显。这也是为什么官方一直强调 key 要稳定、唯一、不推荐 index。

Fiber 是 React 走向现代化的关键。它的核心目标是让渲染变成可中断的，通过链表结构把整个更新过程拆成一个个小任务，配合调度器决定哪些优先级高、先执行，避免长时间占用主线程导致页面掉帧。能讲清“可中断渲染”和“任务优先级”，就超过了大部分只会用 React 的人。

Hooks 机制也特别能体现理解深度。为什么 Hooks 不能在循环、条件里调用？因为 Hooks 依赖内部调用顺序来关联状态，每次渲染都要按固定顺序执行，顺序变了状态就全乱了。为什么 useEffect 里会有闭包陷阱？因为 effect 捕获了这次渲染时的变量值，如果依赖没写对，它拿到的永远是旧值。这些问题在真实开发中酿成的 bug 数不胜数，理解原理之后很多“玄学 bug”当场就能定位。

再说 Vue。Vue 2 的响应式靠Object.defineProperty逐条劫持对象的属性，所以新增、删除属性是检测不到的，需要专门的 API 处理。Vue 3 换成 Proxy，可以直接监听整个对象，也可以监听数组索引和 length 变化。理解 Proxy 的代理能力之后，很多 Vue 2 时代的“为什么改了这个值视图不变”的问题会自动消失。

我判断一个人框架是“真懂”还是“假懂”，通常只看三个问题：

1. 列表渲染为什么需要 key，去掉 key 一定会出问题吗？
2. 状态更新后，从数据到 DOM 的链路里，你能够做哪些环节的优化？
3. 某个复杂组件渲染很慢，你的排查路径是什么？

这三个问题光靠背“八股文答案”过不去，必须真正写过、调过、被坑过才能答得立体。

2.4 工程化与性能：资深和初级的真正分水岭

如果语言基础和框架原理是“建楼的地基和框架”，那工程化与性能就是“把楼交付给客户之前的整套验收体系”。这也是很多“资深前端”翻车最多的地方——业务做了很多年，但始终停留在“页面能跑”的水平，完全没有建立起工程化视角。

Webpack 核心要理解几条主线：entry是打包起点，module是模块，chunk是打包产物，loader负责转换文件内容，plugin负责参与打包生命周期里更复杂、更全局的任务。举个例子，babel-loader 是转换器，把 ES6+ 语法转成兼容代码；而mini-css-extract-plugin是插件，在打包过程中把 CSS 单独抽成文件。它们分工不同，不能混为一谈。Tree Shaking 的原理是依赖 ES Module 的静态分析能力，在编译阶段标记出未被引用的导出，再在压缩阶段删除，这也是为什么工具库必须保持 ESM 格式才能被摇树优化。

工程化还绕不开代码分割。路由懒加载、UI 组件按需引入、第三方库单独分包，这些手段的本质都是把一个庞大的 bundle 拆成多个小块，让首屏只加载必要资源。微前端解决的是多团队、多技术栈团队协作下的独立开发与部署问题，Monorepo 解决的则是“多个包共享依赖、统一版本管理”的问题。这俩不是一个概念，但都是当前大厂前端面试的高频话题。不要只背名词，要结合自己的项目说清楚“我们团队有几个人、几个系统、发布频率多高、为什么需要它”，这个比背书有效十倍。

性能优化这一块，资深的差距体现在“量化”二字上。衡量首屏加载有 FCP（首次内容绘制）、LCP（最大内容绘制），衡量交互顺畅有 TTI（可交互时间）、TBT（主线程阻塞时间），衡量稳定性有 CLS（累计布局偏移）。Core Web Vitals 是 Google 推荐的三大核心指标。优化不能只凭感觉“页面好像快了”，要有优化前后的指标对比数据。比如做列表虚拟滚动之前，先量一下滚动帧数是多少，优化后再量一次，用数字说话。做首屏优化之前，先拆出每个请求的大小和耗时，找出真正拖后腿的资源，再去定方案。这是我见过初级和资深之间最直观的区别——一个是“改改试试”，一个是“先量化再改再验证”。

性能之外还要加上监控。前端错误要能主动捕获：window.onerror抓运行时错误，unhandledrejection抓 Promise 异常，还要配合 SourceMap 做错误堆栈还原。白屏问题要有检测机制，核心思路是定时检查页面关键节点是否渲染出来，如果达到阈值就上报。这样做不是增加工作量，而是给线上质量装一个仪表盘，出了问题不用等用户投诉，系统自己先报警。能做到这个层面，才算真正把前端当成一个可观测、可回放的工程系统，而不是“写写页面而已”。

3. 站在面试官视角聊聊：怎么判断一个人是真资深还是面霸

3.1 好答案长什么样

很多候选人以为面试是在考“标准答案”，其实面试官想听的是思考过程。同一个问题：“为什么用 WebSocket 而不是轮询？”

背书式回答是：“WebSocket 支持服务端推送，性能比轮询好。”

好的回答是：“因为这是我们内部的告警通知场景，消息频率大概几秒一条，需要实时触达。第一次方案也考虑过轮询，但算了下，60 个在线用户、5 秒轮询一次，一天就是 100 多万次请求，大部分都是空响应，成本和延迟都亏。所以换成了 WebSocket 长连接。同时考虑到服务端可能重启、网络可能抖动，还加了心跳检测和断线自动重连，消息层面做了一版离线补偿。”

看出来差别了吗？好的回答有场景、有数据、有取舍、有演进过程。它不需要完美无缺，但它展示了一个人的决策树：从问题出发，列出方案，对比成本，做出选择，再考虑异常兜底。

在面试中只要能听到这样的思考链路，我对候选人的技术深度评分会立刻拉高。因为他证明了自己不是“照着需求书写代码的人”，而是“能参与技术决策的人”。

3.2 我常用的命题追问方式

具体操作时，我喜欢对每个核心方案做四连问：

1. 为什么选这个方案？—— 考察需求分析和背景判断。
2. 还有没有更简单的替代方案？—— 考察知识面和技术敏感度。
3. 最坏情况下会发生什么，怎么兜底？—— 考察风险意识和异常处理经验。
4. 你亲自量化过效果吗？—— 考察是否只是“听说过”还是“亲手验证过”。

这套追问的杀伤力很大。背过八股但没有真实经验的人，通常第一个问题答得还行，第二个问题开始卡壳，第三个问题就支支吾吾，第四个问题要么回避，要么含糊其辞“听同事说大概有提升”。而真正做过工程实践的人，哪怕是失败了，也能讲出“当时预期是什么、结果差距在哪、后来怎么修正”，效果远比背诵式发挥好得多。

我还要强调一点：面试官并不期待候选人回答“最优解”，更期待你答“当时的选择和复盘”。技术永远在变，但一个人分析问题和修正错误的方式，是长期稳定的能力。

3.3 几个容易刷掉“伪资深”的实战场景

除了问原理，我更爱用开放场景题来检验一个人的真实功力。考的不是“这是什么”，而是“你会怎么做”。

第一个经典场景是白屏应急。我会说：“线上某个页面突然大面积白屏，假设你是这个项目的前端负责人，你现在人在外面用手提电脑排查，请告诉我第一步做什么、第二步做什么，直到定位到原因。”这题没有标准答案，但我能立刻看出对方是结构化的排查者，还是靠直觉乱试的人。合格的回答路线是：先看监控系统有没有自动上报最近是否出现 JS 错误、再拉最近 30 分钟的发布记录、检查接口和静态资源状态、复现并看 Console 和 Network，逐步缩小范围。不合格的回答是：“我先刷新一下页面看是不是偶发。”这种心态当一线工程师可以，当资深负责人严重不够。

第二个场景是国际化改造。假设一个老项目全部文案都是中文硬编码，现在要支持英语和日语，你会怎么设计改造方案。这里考察的是工程思维：是引入i18n库统一处理，还是先梳理文案提取工具，还是按模块渐进式改造，怎么控制回归风险。答案没有对错，但一个有经验的人会主动提出“渐进式改造”“老文案兼容”“翻译资源按需加载”“不改业务逻辑，只改展示层”这些关键点。

第三个场景是性能问题。一万行数据的表格，拖动滚动条卡成 PPT，你怎么处理。这道题极容易区分“会不会”。真做过虚拟列表的人会讲数据窗口化、行高确定与不定高处理、合并单元格的影响、骨架屏过渡；没做过的人只能说出“上虚拟列表”这个名词，但讲不出关键难点在哪里。

这三个场景抛出去，是真做过项目还是背过面试题，五分钟内就原形毕露了。我一直觉得，面试不是背课文比赛，是让候选人展示“他如何在真实世界解决真实问题”的一场模拟。

4. 想进阶的前端，怎么系统补上这些核心概念

4.1 别背八股，把概念链路串起来

网上一搜“前端面试题 2026 及答案”，能看到大量碎片化题库。我的建议是别照着刷，效率低，而且背完就忘。更有效的方式是按“概念链路”组织知识。

什么叫概念链路？就是你每学一个知识点，都挂在具体场景主干上，像给大树添枝叶。比如“从输入 URL 到页面呈现”是整个浏览器知识的主干，DNS、TCP、HTTP、渲染、脚本执行、缓存每一项都是主干上的节点。遇到具体问题时再往节点下挂子节点：遇到图片加载慢，挂在 HTTP 和缓存节点下；遇到滚动卡顿，挂在渲染节点下。这样知识不是孤立的，而是沿着真实问题路径自然生长。

还有一个特别好的自检方法：用大白话把你懂的知识讲给不懂前端的同事听。如果能让他听懂，说明你真的懂了；如果讲的时候发现自己绕不过去，那个绕不过去的地方就是知识盲区。我这些年用这个方式检查自己，十次有九次能精准暴露薄弱点，比刷一百道选择题都管用。

实操层面，可以利用 DevTools 来验证理论。比如你看到“重排影响性能”，就去 Performance 面板录一段增删 DOM 的页面操作，观察 Layout 耗时；你学到“闭包导致内存不释放”，就用 Memory 面板抓一下堆快照，看看保留的对象是谁。理论落到工具上，知识才真正变成肌肉记忆。

4.2 源码阅读的路径与方法

很多人一听读源码就头大，觉得工程巨大、无从下手。我的经验是：永远不要从头到尾一行行读，要在具体目标的指引下跳读。

读 React 源码，不要第一眼就冲进 reconciler。先看官方架构说明，了解 React 分为 reconciler、renderer、scheduler 三层，然后带着问题去找代码。比如你刚理解“Fiber 是链表”，就去搜 FiberNode 的定义，看它的return、child、sibling三个字段是怎么串起来的。比如你想理解调度，就去找 scheduler 里performWorkUntilDeadline的实现，看它如何利用 MessageChannel 和requestIdleCallback的差异。读源码不是比翻页速度，是验证你已经形成的概念模型。

读 Vue 3 源码有更温和的起点。响应式相关代码集中在reactivity模块，核心就是 Proxy 拦截 + 依赖收集 + 触发更新，几百行代码就能理解大半。而且 Vue 3 是用 TypeScript 写的，类型标注就是最好的注释。找相关的单元测试跑一跑，比自己瞎猜行为高效得多。

我在这儿加一条忠告：看源码时注意版本，不要拿 Vue 2 的资料去读 Vue 3，也不要拿旧版 React 的类组件生命周期文章硬套现在函数组件时代的架构。现在的网上资料鱼龙混杂，认准官方文档和靠谱平台的版本化内容，才能保证知识不过期。

4.3 面试前准备自己的“项目深挖文档”

最后说一个我自己招人时非常看重的习惯：候选人有没有对自己的项目做过结构性复盘。

我一直建议身边想进阶的朋友，把简历上每一个项目都写成一份“项目深挖文档”，固定包含五块内容：

1. 业务背景：这个项目解决什么问题，为什么值得做？
2. 技术选型：方案为什么是这个而不是那个，当时对比过哪些候选？
3. 核心难点：项目中最难啃的骨头是什么，为什么难，怎么攻克的？
4. 量化结果：性能指标、业务数据、稳定性数据，能列多少列多少。
5. 复盘改进：如果重新做一遍，哪些地方你会用完全不同的方式？

这份文档不是为了给别人看的，而是帮你把“做过”变成“思考过”。写完之后，再拿它对照本节前面那些核心概念，比如 React 项目在“状态更新链路”上有没有值得深挖的点、性能优化项目在“指标采集与验证”上有没有形成闭环。一旦完成这个映射练习，面试中被问到原理时，你自然就能从项目里的真实问题出发去回答，而不是临场背诵。

我身边见过太多简历写得漂亮、项目做得不少，但一被追问就垮掉的候选人。他们缺的不是项目，是复盘。项目经验是原料，复盘才是把原料加工成能力的工序。没有这道工序，工作十年者和工作三年的差异，往往只有简历上的数字而已。

说到底，前端这个行业最迷人的地方也在这里——技术更新很快，但底层的原理几十年都没变过。把闭包、事件循环、渲染、框架机制、工程化这件事想透，你应对的就不只是眼前这场面试，而是未来任何一次技术变迁。那些只会背题的人会被时间筛掉，真正理解问题本质的人，才配得上简历上那“精通”二字。希望每个准备跳槽的前端，都能在面试前把自己的知识体系认真打磨一遍，别等面试官来帮你做体检。

最后再分享一点我个人的体会：面试这几年下来，我发现每次面试对面试官同样是学习过程。同一个概念，一百个候选人就有一百种理解方式，有人讲得透彻，有人讲得模糊，这比看文档更能校准你对核心概念重要性的判断。所以我也越来越愿意在面试结尾给候选人一句真诚的建议：今天没答上来的问题，回去花一周把它弄明白，它一定会成为你下一份工作的敲门砖。技术面试的意义不是淘汰你，而是让你在暴露短板之后，第一次认真对待那些早就该补上的核心概念。