年前那阵子我把自己关在书房里干了一件看起来有点傻的事把过去五年写前端攒下来的所有知识全部推倒重来整理成了一份面试自用笔记。刚开始只是想列个大概结果越写越收不住最后愣是写到了十万字。这份笔记没有公开发过最初的受众只有一个——准备跳槽的我自己。现在回头看看真正值钱的其实不是那十万字而是整理过程中被迫想清楚的那些为什么。这篇文章就把这份笔记的架构、核心考点、答案组织方式以及我踩过的坑一次讲清楚。先说说这份笔记解决了什么问题。五年经验的前端业务能力通常不缺真正尴尬的是你明明会写却讲不清楚。面试官问从输入URL到页面展示发生了什么你心里知道大概但嘴上一片混乱问你React的setState到底是同步还是异步你隐约记得在事件里是异步却答不上来为什么更答不上来React 18之后发生了什么变化。这份笔记就是用来解决这类问题的——它不追求堆砌题目而是把每个高频考点拆到原理层让你不光知道答案还能接得住追问。适合正在准备跳槽的初中级前端也适合那些想把自己从熟练工提升到能讲清原理的开发者。1. 五年经验的舒适区陷阱为什么我把自己重新按在地上摩擦1.1 业务代码写得飞起面试却连基础题都说不利索我在原公司一直处于能干活而且干得不错的状态。迭代排期、性能优化、基础组件抽取这些东西每天在做看起来经验值一直在涨。直到有一次去一家大厂面试前面聊项目聊得挺好到了技术面面试官问了一个特别基础的问题你说一下浏览器缓存里的强缓存和协商缓存Cache-Control里的no-cache和no-store有什么区别我当时的回答是no-cache就是不使用缓存no-store也是不使用缓存一个是不检查直接不用一个是不存……说到一半自己都觉得不对。其实no-cache的真实含义是可以使用缓存但每次使用前必须向服务器校验资源是否新鲜是一个用之前先问问的策略而no-store才是真正的不存储任何缓存副本。那次面试我当然挂了但挂了之后我想明白一件事我多年积累的是怎么把代码跑通的经验而不是把机制讲清楚的能力。这两者之间的差距在面试这种场景下会被瞬间放大。1.2 面试官追问的那句然后呢逼我重新定义会前端面试和平时写代码最大的不同在于它有一条追问链条。平时你写完一个组件能跑、能用、能过评审这事就结束了。但面试官不会停在你用过什么这一步他会一级一级往下追。你说了我用React.memo做了组件缓存他马上会问memo在什么情况下会失效你说了我用Web Worker处理了耗时的计算任务他马上会问Worker和主线程之间通信有性能开销吗你考虑过Transferable Objects吗。这种追问模式让我意识到所谓五年经验不应只是踩过更多坑而应该是每个决策背后都有一套可解释的原理。整理笔记的过程本质上就是把这套原理从头到尾补全。我不再满足于知道memo能缓存组件而是去搞清楚了memo本质上是做了一次浅比较如果父组件每次渲染都创建新的对象字面量作为props传下去那memo等于白写——该重渲染照样重渲染。1.3 整理笔记这件事本身就成了最好的复习方式很多人觉得整理笔记浪费时间但我的体会恰好相反写下来的过程就是第一遍复习回看的过程就是第二遍复习面试前翻一遍关键章节就是第三遍。这份十万字笔记写完之后我对自己的知识盲区有了一个非常清晰的扫描结果。我把所有题目分成三类能秒答但不理解原理的、能说出大概但细节含糊的、以及完全不知道的。第一类比如盒子模型、闭包很快就能过第二类比如事件循环、Fiber调度需要花时间重新啃第三类比如部分跨域方案的边界条件、不同存储方案在隐私模式下的行为差异就得靠查资料、写Demo来补。整理的过程让我把这些分类逐项清零这种踏实感是背题库给不了的。2. 十万字笔记的整体架构按知识域和题目来源双维度组织2.1 四个核心知识域覆盖面试的技术主线笔记的第一层架构我按知识域来划分整个前端面试的技术主线其实可以压缩成四个域。第一个是JavaScript语言与运行时包括作用域和闭包、this绑定规则、原型链、事件循环、Promise原理、微任务宏任务队列以及V8的实现机制比如Hidden Class和垃圾回收算法。第二个是浏览器原理与Web API包括页面加载渲染流程、HTTP缓存、同源策略与跨域方案、Web Storage与Cookie的边界、各种安全攻击的防御手段。第三个是框架与状态管理以React为主兼顾Vue的核心思路包括组件渲染机制、Hooks原理、Fiber架构、diff算法、状态管理的设计模式。第四个是工程化与性能优化包括模块化与打包工具原理、Tree Shaking机制、热更新原理、构建体积优化、以及首屏渲染性能的各项指标。这四个域并不是平均用力的。根据我的观察面试中权重最高的是第二个和第三个域尤其是浏览器原理和React的底层机制。因为这两个部分最能区分用过框架的人和理解框架的人。笔记里我把这两个域的篇幅扩到最大每个高频考点都往下挖了两到三层。2.2 一条题目记录应该长什么样笔记的第二层架构是按题目来源和记录格式来组织的。我给自己规定了一条题目记录必须包含五个部分题目原文、我的第一版答案、面试官可能的追问方向、我收集整理的更优答案、以及参考资料链接。这个格式非常有效因为单纯列问题答案的笔记会被面试官一个追问就打回原形。只有把追问方向也提前想好才能在面试现场形成预判。举个例子我笔记里有一条关于事件循环的记录。题目原文是说说setTimeout和Promise的执行顺序。我的第一版答案写得很啰嗦罗列了一堆现象。后来我换成了一张时间轴的描述方式脚本执行时先将setTimeout回调放入宏任务队列将Promise的then回调放入微任务队列当前宏任务执行完后微任务队列会清空再取出下一个宏任务执行。追问方向我记了三条微任务里又产生微任务怎么办、Node.js里的事件循环和浏览器有什么区别、如何用代码验证这一套逻辑。这一条记录写下来比单纯背十个相关题目都有用。2.3 用链接关系代替死记硬背十万字的笔记如果只是线性堆叠复习效率会非常低。我采用的是中心节点链接的组织方式。每个核心概念是一个节点节点之间用批注互相指路。比如浏览器缓存这个节点会链接到HTTP报文结构、CDN与缓存的关系、资源指纹与hash命名、Service Worker缓存策略等多个子节点。这种组织方式的好处是面试时不管从哪个角度切入你都能沿着链接把相关知识点串起来。比如面试官问为什么打包时要给文件名加hash你可以顺着这个链接引到浏览器协商缓存依赖文件变更后的新URL、强缓存过期时间的权衡、打包工具的runtime维护,如果你答完了这些面试官会觉得你不是在背题而是在脑中构建了一套完整的技术地图。这套地图的价值在面试中远远大于孤立的知识点。3. 高频考点完整答案的拆解示范3.1 从输入URL到页面展示面试最爱的一条链路这个问题几乎场场必问但它难就难在链路过长涵盖网络、浏览器进程、渲染管线、JavaScript执行四个层面。如果你的回答只停留在先DNS解析再发起HTTP请求然后HTML解析出来渲染那只能算及格线都不到。我笔记里把这条链路拆成了表格按阶段记忆阶段发生了什么容易被追问的点DNS解析域名到IP的解析依次查浏览器缓存、系统缓存、路由器缓存、递归DNS服务器DNS缓存命中率、DNS over HTTPS、CDN如何利用DNS就近调度TCP连接三次握手建立连接HTTP/1.1默认持久连接三次握手为什么不是两次、TCP的队头阻塞问题TLS握手HTTPS在TCP之上协商密钥证书链校验RSA与ECDHE握手区别、Session Ticket的复用HTTP请求发送构建请求报文、携带Cookie、缓存的强缓存校验GET和POST差异、请求头优先级、cookie携带策略服务器返回协商缓存通过ETag/Last-Modified判断命中的话返回304no-cache与no-store的语义差异HTML解析字节流转token、构建DOM树同步解析遇到CSS会阻塞、遇到script无defer会阻塞preload/prefetch的区别、async与defer的区别渲染管线DOM树与CSSOM合并为RenderTree计算布局绘制、合成Layout和Paint的区别、哪些CSS属性触发Layout还是Composite页面交互JavaScript引擎执行脚本事件监听就绪用户开始交互长任务监测、First Input Delay模型每一个阶段我都配了一段详细的文字解释比如HTML解析阶段我特别标注了解析器遇到没有defer或async的script标签时会停止解析、下载并执行JS这就是为什么把script放body底部的原因而CSS在默认情况下会阻塞渲染因为渲染必须先有完整的CSSOM。这样到了面试现场你不需要临场组织语言只需要把笔记里的结构讲出来并顺着面试官的追问进入对应子节点即可。3.2 React的setState到底是同步还是异步这道题是React方向的钉子户。很多人只记得React是异步的但你细问他为什么在setTimeout里setState行为会不一样他就卡住了。我笔记里把这道题的答案分成了三个层次现象层、机制层、变化层。现象层很简单在React事件处理器中连续调用两次setStateReact只触发一次渲染且此时state不会立刻更新拿到的还是旧值。机制层要讲到批量更新和调度在legacy模式下React通过一个batchedUpdates标志位来决定是否将更新纳入批处理事件处理器开始时开启批处理标志位结束时统一flush但在setTimeout、Promise回调、原生事件监听中这个标志位没被打开所以每次setState都会立即触发一次同步更新。到了React 18的createRoot下情况又变了React引入了自动批量更新无论在哪里触发setState默认都会合并批处理。为了让这个答案可验证我笔记里还存了一段测试代码import { createRoot } from react-dom/client class App extends React.Component { state { count: 0 } handleClick () { this.setState({ count: this.state.count 1 }) this.setState({ count: this.state.count 1 }) console.log(this.state.count) // 0事件处理器内是批量更新 Promise.resolve().then(() { this.setState({ count: this.state.count 1 }) // legacy模式这里是同步更新count已经是2 // React 18 createRoot这里仍然批量更新count还是1 }) } } const root createRoot(document.getElementById(root)) root.render(App /)这段代码简单但极具说服力。面试官问完原理之后你当场写出这段代码说明实验现象基本就稳住了。这也是我在笔记里强调的原则一切答案都必须具备可验证性能写Demo证明的知识比背书得来的记忆牢固十倍。3.3 性能优化从指标到落地动作的映射性能优化是五年经验候选人绝对绕不开的话题。面试官通常不会直接问你怎么做性能优化那太宽泛了他更可能给一个场景我们产品首屏加载很慢用户反馈白屏时间特别长你怎么排查和优化。这类场景题最怕的是零散作答想到图片压缩说图片想到懒加载说懒加载没有任何体系感。我笔记里把性能优化按指标来组织形成了指标—瓶颈—动作的映射表指标衡量的内容常见的瓶颈对应优化动作TTFB首字节时间后端接口慢、服务器离用户远、缓存未命中开启CDN、降低TTFB超时时间、边缘计算LCP最大内容绘制首屏核心元素的渲染时间图片加载慢、资源阻塞图片preload、使用现代图片格式、压缩体积CLS布局偏移总量图片无宽高占位、广告位动态插入、字体加载突变为图片设宽高、预留广告位、font-display调整INP交互响应时间长任务阻塞主线程、频繁的布局抖动拆分长任务、进行子任务调度、减少强制同步布局转化率用户从进入到可交互的耗时JS执行时间过长、组件树过深代码分割、按需加载、减少不必要的渲染这种表格化的组织方式让我在面试时拿到一个性能问题先判断它属于哪个指标再顺着映射表讲对应的瓶颈判断和优化动作。面试官听到你在用指标语言描述问题而不是笼统地说加载慢就压缩图片就会知道你是有方法论沉淀的而不是临时背了几个优化点。4. 笔记里沉淀下来最有价值的四十个问题清单4.1 按考察维度分类标注难度与追问方向光讲方法和原理还不够我把笔记里最典型的四十个问题整理成了一份清单按考察维度分成六类每类标注了常见追问方向和参考优先级。以下是我认为覆盖度最完整的清单结构分类代表性问题常见追问方向准备优先级JavaScript核心事件循环的执行顺序怎么证明闭包一定导致内存泄漏吗深拷贝在JSON.stringify里有哪些坑微任务嵌套、V8垃圾回收如何清理闭包引用的外层变量极高浏览器原理从URL到页面展示全流程HTTP缓存两种策略的适用场景Cookie与Storage和IndexedDB的边界no-cache与no-store的区别、隐私模式下Storage是否可用极高React机制setState同步还是异步useEffect和useLayoutEffect的区别useMemo和useCallback真的能提升性能吗自定义Hooks的闭包陷阱、StrictMode为什么执行两次render极高Vue对比computed和watch的本质区别nextTick原理Vue3响应式为什么比Vue2快Composition API与Options API的取舍、更新颗粒度中工程化Webpack构建流程中loader和plugin分别解决什么问题热更新HMR如何做到局部更新tree shaking的副作用条件、为什么产物vodka体积减小不明显高场景题设计一个支持大量列表项滚动流畅的组件如何做前端权限控制的方案设计大型表单如何设计才不卡方案增删改查的时间复杂度、极端数据下的兜底策略高我准备这份清单的原则是宁缺毋滥。与其列两百个题目让人不知所措不如把四十个真正高频的题按这种方式理清确保每一个都吃透。面试时你会发现很多新题本质上只是这些核心题目的变体。4.2 场景题和开放题为什么比八股文更决定offer实话说到了五年经验这个级别八股文的比重会逐步降低场景题和系统设计题才是区分度最大的部分。八股题你背了就会但场景题考的是你解决问题时有没有完整的思维框架。比如我记录过一道典型的场景题如果你负责一个后台管理系统表格里要渲染一万条数据怎么保证不卡第一层回答是虚拟滚动这算及格第二层要分析卡顿的根源是DOM节点过多还是JavaScript计算过多是长列表的渲染本身还是频繁更新的交互第三层要给方案选型虚拟滚动是必然选择还是过度设计如果数据结构不复杂、渲染频率不高直接简单分段渲染就行虚拟滚动带来的复杂度和测量误差反而得不偿失最后一层还要验证收益用Performance面板对比优化前后的FPS和渲染时长。我的笔记里把场景题的作答模板固定成了目标-制约-方案-验证四步先说清楚要优化到什么样的目标再列出当前体系的制约条件然后给方案并说明为什么选它而不选别的最后说明如何验证方案有效。这套模板在真正面试的时候救了我好几次因为它保证无论面对多么开放的问题我的回答都是结构化的不会东一句西一句。5. 让答案经得起验证源码、Demo和面试复盘5.1 每个答案都要能追溯到源码整理笔记的过程中我给自己立了一条规矩凡是机制类的答案必须能找到源码或官方文档的出处不能只靠二手博客。这条规矩一开始执行起来很痛苦但坚持到中期效果特别明显。以React为例我在读调度相关的源码时把scheduler的更新队列和优先级模型划了重点理解了为什么高优先级的更新可以打断低优先级的渲染读useEffect源码时搞清楚了它和useLayoutEffect在commit阶段的区别一个是passive effect在layout之后异步执行一个是同步阻塞布局。这些理解写进笔记后我在面试中说到React的并发特性时能自然地讲出可中断渲染和优先级调度到底是怎么落地的而不是停留在概念名词的套用上。面试官立刻能感觉到你不是只看了几篇渲染原理的文章而是真正读过代码。5.2 模拟面试是检验笔记质量最好的方式我整理笔记的时期每周会请一位同行扮演面试官针对笔记里的重点章节提问每次一小时。第一次模拟时候我被问到一个我自己写过答案的问题但当场讲出来的效果和笔记里写的完全不是一回事——我又回到了东拉西扯的状态。后来我复盘发现原因是笔记里的答案是书面语句子结构太复杂口头表达跟不上。从那之后我在笔记里给每个核心答案增加了一段口语化版本把长句拆成短句把复杂逻辑拆成分步。比如事件循环的书面版可以写当前宏任务执行完毕后清空微任务队列再执行下一个宏任务口语版我就记成三步先看本轮宏任务完事清空微任务清空了再拿下一个宏任务。这种变化在模拟面试中效果立竿见影口头表达的流畅度提升了一大截。模拟面试的价值就在于你会发现自己以为会了和真能讲出来之间的鸿沟。5.3 面试后的复盘-增补-重答闭环每次真实面试结束我都会做一件事把现场没答好或答得磕巴的题记进错题清单并在当天晚上重新整理答案、补充追问方向第二天再对着镜子把这道题讲一遍。这个闭环看起来笨但特别有效。我有一次在面谈中遇到一个关于Web Worker的问题面试官问Worker和主线程之间到底应该传数据还是传节流之后的控制消息我当时答得很模糊只说了Worker处理完计算再传回来。回来后我查资料发现其实对于高频计算任务正确的思路是减少传递的消息数量把计算和任务调度尽量都放在Worker内部完成通过批量回报或者采样回报来降低通信成本。我把这条经验补充进笔记还写了一段为什么大量数据传输会让主线程阻塞更严重的分析。后来在另一场面试中又遇到类似问题我直接给出了完整的答案还顺带讲了如何用Transferable Objects把数据的所有权转移给Worker来优化。这时候我意识到面试本身就是最好的补充教材只要你愿意在做完题之后回头补笔记。6. 五年前端面试的临场经验如何把笔记优势发挥出来6.1 简历的写法决定了面试官问你什么很多人的简历写的是一串参与了XX系统开发负责XX模块这种写法看起来在事无巨细但实际上面试官从中根本提炼不出什么有效问题只能去问通用的基础题。基础题范围太广你准备得再充分也难免有盲区。我在更新简历的时候意识到简历其实是你给面试官划的重点写什么面试官就大概率问什么。我把简历里每个项目都改成了矛盾-方案-结果的句式。比如后台报表查询在数据量突破千万级后出现白屏通过拆解长任务、接入Web Worker并行渲染、实现虚拟表格将首屏加载时间从8秒降到1.2秒。这样一个描述面试官自然会顺着追问千万级数据量为什么会导致白屏、Web Worker怎么并行渲染的、虚拟表格的实现原理是什么。这三个问题恰好都是我笔记里准备最充分的章节。让面试官问你会的问题不是投机取巧而是筛选信息、展示你最擅长的领域。6.2 追问链条的应对结论先行再给证据大厂面试官有一个统一的爱好就是往下追问。你给出一个结论后他会追为什么然后你再抛出一个更深层的概念他又追底层怎么实现的。应对这条追问链条我总结出一套固定打法先一句话说结论再分步骤给依据最后给一个可验证的例证。举个例子被问到为什么说React的diff算法是高效但仍有局限性的我会先说结论因为diff是在同层级内进行复杂度从树形递归的O(n³)降到了O(n)但降复杂度的代价是跨层移动节点需要走删除重建而不是移动。然后下一步具体说老三样也就是同类型节点比对、key的作用、props变更触发的更新最后举一个例子说明为什么把一个节点从树的顶层挪到深层React会先销毁再创建而不会直接移动。这个三步结构能确保即使面试官不断追问我也始终踩在自己的逻辑线上而不是越追越乱。6.3 准备周期与体力分配最后说一下体力问题。整理十万字笔记真正的时间投入比想象中大得多。我的节奏是把准备周期分成两个阶段第一个阶段约三到四周每天下班后花两小时左右按知识域逐个击破每周末留出一整个下午做模拟面试和复盘第二个阶段是面试期间不再新增知识只翻笔记里的关键词和错题清单保持状态。面试本身是很耗体力的一天安排两场已经是上限。从我的实际经验看上午的面试状态通常比下午更容易调动起来所以尽量把最重要的面试放在上午场。还有一个小经验每次面试前提前一小时看一遍自己笔记里最核心的一页不求临时记住什么就是为了让思维提前进入讲技术的模式。准备工作做到这个程度考验你的就不再是记忆力和临场发挥而是情绪和体力管理了。最后再说几句实在话。整理笔记和面试准备这件事真正改变我的不是拿到了offer而是让我重新审视了自己自认为很熟的知识体系。以前写代码遇到问题能解决就过去了很少去追问底层机制到底是什么。现在我不太一样了看到任何一个API或者框架特性都会习惯性地问一句它为什么这样设计它的边界条件是什么如果面试官再多问两层我能不能接得住这份笔记后来我也没有再按十万字的规模去维护因为核心的知识框架已经牢牢长在我脑子里了。就跟健身一样增肌的过程很痛苦但一旦肌肉形成了日常维持只需要少量训练就行。如果你也在准备跳槽我建议你别直接拿来背任何面试题集而是从自己最薄弱的知识域开始亲手写一份专属笔记。别人整理好的答案永远代替不了你自己推导出来的理解面试官也一眼就能分辨出你的答案是背出来的还是长在脑子里的。
年前那阵子我把自己关在书房里干了一件看起来有点傻的事把过去五年写前端攒下来的所有知识全部推倒重来整理成了一份面试自用笔记。刚开始只是想列个大概结果越写越收不住最后愣是写到了十万字。这份笔记没有公开发过最初的受众只有一个——准备跳槽的我自己。现在回头看看真正值钱的其实不是那十万字而是整理过程中被迫想清楚的那些为什么。这篇文章就把这份笔记的架构、核心考点、答案组织方式以及我踩过的坑一次讲清楚。先说说这份笔记解决了什么问题。五年经验的前端业务能力通常不缺真正尴尬的是你明明会写却讲不清楚。面试官问从输入URL到页面展示发生了什么你心里知道大概但嘴上一片混乱问你React的setState到底是同步还是异步你隐约记得在事件里是异步却答不上来为什么更答不上来React 18之后发生了什么变化。这份笔记就是用来解决这类问题的——它不追求堆砌题目而是把每个高频考点拆到原理层让你不光知道答案还能接得住追问。适合正在准备跳槽的初中级前端也适合那些想把自己从熟练工提升到能讲清原理的开发者。1. 五年经验的舒适区陷阱为什么我把自己重新按在地上摩擦1.1 业务代码写得飞起面试却连基础题都说不利索我在原公司一直处于能干活而且干得不错的状态。迭代排期、性能优化、基础组件抽取这些东西每天在做看起来经验值一直在涨。直到有一次去一家大厂面试前面聊项目聊得挺好到了技术面面试官问了一个特别基础的问题你说一下浏览器缓存里的强缓存和协商缓存Cache-Control里的no-cache和no-store有什么区别我当时的回答是no-cache就是不使用缓存no-store也是不使用缓存一个是不检查直接不用一个是不存……说到一半自己都觉得不对。其实no-cache的真实含义是可以使用缓存但每次使用前必须向服务器校验资源是否新鲜是一个用之前先问问的策略而no-store才是真正的不存储任何缓存副本。那次面试我当然挂了但挂了之后我想明白一件事我多年积累的是怎么把代码跑通的经验而不是把机制讲清楚的能力。这两者之间的差距在面试这种场景下会被瞬间放大。1.2 面试官追问的那句然后呢逼我重新定义会前端面试和平时写代码最大的不同在于它有一条追问链条。平时你写完一个组件能跑、能用、能过评审这事就结束了。但面试官不会停在你用过什么这一步他会一级一级往下追。你说了我用React.memo做了组件缓存他马上会问memo在什么情况下会失效你说了我用Web Worker处理了耗时的计算任务他马上会问Worker和主线程之间通信有性能开销吗你考虑过Transferable Objects吗。这种追问模式让我意识到所谓五年经验不应只是踩过更多坑而应该是每个决策背后都有一套可解释的原理。整理笔记的过程本质上就是把这套原理从头到尾补全。我不再满足于知道memo能缓存组件而是去搞清楚了memo本质上是做了一次浅比较如果父组件每次渲染都创建新的对象字面量作为props传下去那memo等于白写——该重渲染照样重渲染。1.3 整理笔记这件事本身就成了最好的复习方式很多人觉得整理笔记浪费时间但我的体会恰好相反写下来的过程就是第一遍复习回看的过程就是第二遍复习面试前翻一遍关键章节就是第三遍。这份十万字笔记写完之后我对自己的知识盲区有了一个非常清晰的扫描结果。我把所有题目分成三类能秒答但不理解原理的、能说出大概但细节含糊的、以及完全不知道的。第一类比如盒子模型、闭包很快就能过第二类比如事件循环、Fiber调度需要花时间重新啃第三类比如部分跨域方案的边界条件、不同存储方案在隐私模式下的行为差异就得靠查资料、写Demo来补。整理的过程让我把这些分类逐项清零这种踏实感是背题库给不了的。2. 十万字笔记的整体架构按知识域和题目来源双维度组织2.1 四个核心知识域覆盖面试的技术主线笔记的第一层架构我按知识域来划分整个前端面试的技术主线其实可以压缩成四个域。第一个是JavaScript语言与运行时包括作用域和闭包、this绑定规则、原型链、事件循环、Promise原理、微任务宏任务队列以及V8的实现机制比如Hidden Class和垃圾回收算法。第二个是浏览器原理与Web API包括页面加载渲染流程、HTTP缓存、同源策略与跨域方案、Web Storage与Cookie的边界、各种安全攻击的防御手段。第三个是框架与状态管理以React为主兼顾Vue的核心思路包括组件渲染机制、Hooks原理、Fiber架构、diff算法、状态管理的设计模式。第四个是工程化与性能优化包括模块化与打包工具原理、Tree Shaking机制、热更新原理、构建体积优化、以及首屏渲染性能的各项指标。这四个域并不是平均用力的。根据我的观察面试中权重最高的是第二个和第三个域尤其是浏览器原理和React的底层机制。因为这两个部分最能区分用过框架的人和理解框架的人。笔记里我把这两个域的篇幅扩到最大每个高频考点都往下挖了两到三层。2.2 一条题目记录应该长什么样笔记的第二层架构是按题目来源和记录格式来组织的。我给自己规定了一条题目记录必须包含五个部分题目原文、我的第一版答案、面试官可能的追问方向、我收集整理的更优答案、以及参考资料链接。这个格式非常有效因为单纯列问题答案的笔记会被面试官一个追问就打回原形。只有把追问方向也提前想好才能在面试现场形成预判。举个例子我笔记里有一条关于事件循环的记录。题目原文是说说setTimeout和Promise的执行顺序。我的第一版答案写得很啰嗦罗列了一堆现象。后来我换成了一张时间轴的描述方式脚本执行时先将setTimeout回调放入宏任务队列将Promise的then回调放入微任务队列当前宏任务执行完后微任务队列会清空再取出下一个宏任务执行。追问方向我记了三条微任务里又产生微任务怎么办、Node.js里的事件循环和浏览器有什么区别、如何用代码验证这一套逻辑。这一条记录写下来比单纯背十个相关题目都有用。2.3 用链接关系代替死记硬背十万字的笔记如果只是线性堆叠复习效率会非常低。我采用的是中心节点链接的组织方式。每个核心概念是一个节点节点之间用批注互相指路。比如浏览器缓存这个节点会链接到HTTP报文结构、CDN与缓存的关系、资源指纹与hash命名、Service Worker缓存策略等多个子节点。这种组织方式的好处是面试时不管从哪个角度切入你都能沿着链接把相关知识点串起来。比如面试官问为什么打包时要给文件名加hash你可以顺着这个链接引到浏览器协商缓存依赖文件变更后的新URL、强缓存过期时间的权衡、打包工具的runtime维护,如果你答完了这些面试官会觉得你不是在背题而是在脑中构建了一套完整的技术地图。这套地图的价值在面试中远远大于孤立的知识点。3. 高频考点完整答案的拆解示范3.1 从输入URL到页面展示面试最爱的一条链路这个问题几乎场场必问但它难就难在链路过长涵盖网络、浏览器进程、渲染管线、JavaScript执行四个层面。如果你的回答只停留在先DNS解析再发起HTTP请求然后HTML解析出来渲染那只能算及格线都不到。我笔记里把这条链路拆成了表格按阶段记忆阶段发生了什么容易被追问的点DNS解析域名到IP的解析依次查浏览器缓存、系统缓存、路由器缓存、递归DNS服务器DNS缓存命中率、DNS over HTTPS、CDN如何利用DNS就近调度TCP连接三次握手建立连接HTTP/1.1默认持久连接三次握手为什么不是两次、TCP的队头阻塞问题TLS握手HTTPS在TCP之上协商密钥证书链校验RSA与ECDHE握手区别、Session Ticket的复用HTTP请求发送构建请求报文、携带Cookie、缓存的强缓存校验GET和POST差异、请求头优先级、cookie携带策略服务器返回协商缓存通过ETag/Last-Modified判断命中的话返回304no-cache与no-store的语义差异HTML解析字节流转token、构建DOM树同步解析遇到CSS会阻塞、遇到script无defer会阻塞preload/prefetch的区别、async与defer的区别渲染管线DOM树与CSSOM合并为RenderTree计算布局绘制、合成Layout和Paint的区别、哪些CSS属性触发Layout还是Composite页面交互JavaScript引擎执行脚本事件监听就绪用户开始交互长任务监测、First Input Delay模型每一个阶段我都配了一段详细的文字解释比如HTML解析阶段我特别标注了解析器遇到没有defer或async的script标签时会停止解析、下载并执行JS这就是为什么把script放body底部的原因而CSS在默认情况下会阻塞渲染因为渲染必须先有完整的CSSOM。这样到了面试现场你不需要临场组织语言只需要把笔记里的结构讲出来并顺着面试官的追问进入对应子节点即可。3.2 React的setState到底是同步还是异步这道题是React方向的钉子户。很多人只记得React是异步的但你细问他为什么在setTimeout里setState行为会不一样他就卡住了。我笔记里把这道题的答案分成了三个层次现象层、机制层、变化层。现象层很简单在React事件处理器中连续调用两次setStateReact只触发一次渲染且此时state不会立刻更新拿到的还是旧值。机制层要讲到批量更新和调度在legacy模式下React通过一个batchedUpdates标志位来决定是否将更新纳入批处理事件处理器开始时开启批处理标志位结束时统一flush但在setTimeout、Promise回调、原生事件监听中这个标志位没被打开所以每次setState都会立即触发一次同步更新。到了React 18的createRoot下情况又变了React引入了自动批量更新无论在哪里触发setState默认都会合并批处理。为了让这个答案可验证我笔记里还存了一段测试代码import { createRoot } from react-dom/client class App extends React.Component { state { count: 0 } handleClick () { this.setState({ count: this.state.count 1 }) this.setState({ count: this.state.count 1 }) console.log(this.state.count) // 0事件处理器内是批量更新 Promise.resolve().then(() { this.setState({ count: this.state.count 1 }) // legacy模式这里是同步更新count已经是2 // React 18 createRoot这里仍然批量更新count还是1 }) } } const root createRoot(document.getElementById(root)) root.render(App /)这段代码简单但极具说服力。面试官问完原理之后你当场写出这段代码说明实验现象基本就稳住了。这也是我在笔记里强调的原则一切答案都必须具备可验证性能写Demo证明的知识比背书得来的记忆牢固十倍。3.3 性能优化从指标到落地动作的映射性能优化是五年经验候选人绝对绕不开的话题。面试官通常不会直接问你怎么做性能优化那太宽泛了他更可能给一个场景我们产品首屏加载很慢用户反馈白屏时间特别长你怎么排查和优化。这类场景题最怕的是零散作答想到图片压缩说图片想到懒加载说懒加载没有任何体系感。我笔记里把性能优化按指标来组织形成了指标—瓶颈—动作的映射表指标衡量的内容常见的瓶颈对应优化动作TTFB首字节时间后端接口慢、服务器离用户远、缓存未命中开启CDN、降低TTFB超时时间、边缘计算LCP最大内容绘制首屏核心元素的渲染时间图片加载慢、资源阻塞图片preload、使用现代图片格式、压缩体积CLS布局偏移总量图片无宽高占位、广告位动态插入、字体加载突变为图片设宽高、预留广告位、font-display调整INP交互响应时间长任务阻塞主线程、频繁的布局抖动拆分长任务、进行子任务调度、减少强制同步布局转化率用户从进入到可交互的耗时JS执行时间过长、组件树过深代码分割、按需加载、减少不必要的渲染这种表格化的组织方式让我在面试时拿到一个性能问题先判断它属于哪个指标再顺着映射表讲对应的瓶颈判断和优化动作。面试官听到你在用指标语言描述问题而不是笼统地说加载慢就压缩图片就会知道你是有方法论沉淀的而不是临时背了几个优化点。4. 笔记里沉淀下来最有价值的四十个问题清单4.1 按考察维度分类标注难度与追问方向光讲方法和原理还不够我把笔记里最典型的四十个问题整理成了一份清单按考察维度分成六类每类标注了常见追问方向和参考优先级。以下是我认为覆盖度最完整的清单结构分类代表性问题常见追问方向准备优先级JavaScript核心事件循环的执行顺序怎么证明闭包一定导致内存泄漏吗深拷贝在JSON.stringify里有哪些坑微任务嵌套、V8垃圾回收如何清理闭包引用的外层变量极高浏览器原理从URL到页面展示全流程HTTP缓存两种策略的适用场景Cookie与Storage和IndexedDB的边界no-cache与no-store的区别、隐私模式下Storage是否可用极高React机制setState同步还是异步useEffect和useLayoutEffect的区别useMemo和useCallback真的能提升性能吗自定义Hooks的闭包陷阱、StrictMode为什么执行两次render极高Vue对比computed和watch的本质区别nextTick原理Vue3响应式为什么比Vue2快Composition API与Options API的取舍、更新颗粒度中工程化Webpack构建流程中loader和plugin分别解决什么问题热更新HMR如何做到局部更新tree shaking的副作用条件、为什么产物vodka体积减小不明显高场景题设计一个支持大量列表项滚动流畅的组件如何做前端权限控制的方案设计大型表单如何设计才不卡方案增删改查的时间复杂度、极端数据下的兜底策略高我准备这份清单的原则是宁缺毋滥。与其列两百个题目让人不知所措不如把四十个真正高频的题按这种方式理清确保每一个都吃透。面试时你会发现很多新题本质上只是这些核心题目的变体。4.2 场景题和开放题为什么比八股文更决定offer实话说到了五年经验这个级别八股文的比重会逐步降低场景题和系统设计题才是区分度最大的部分。八股题你背了就会但场景题考的是你解决问题时有没有完整的思维框架。比如我记录过一道典型的场景题如果你负责一个后台管理系统表格里要渲染一万条数据怎么保证不卡第一层回答是虚拟滚动这算及格第二层要分析卡顿的根源是DOM节点过多还是JavaScript计算过多是长列表的渲染本身还是频繁更新的交互第三层要给方案选型虚拟滚动是必然选择还是过度设计如果数据结构不复杂、渲染频率不高直接简单分段渲染就行虚拟滚动带来的复杂度和测量误差反而得不偿失最后一层还要验证收益用Performance面板对比优化前后的FPS和渲染时长。我的笔记里把场景题的作答模板固定成了目标-制约-方案-验证四步先说清楚要优化到什么样的目标再列出当前体系的制约条件然后给方案并说明为什么选它而不选别的最后说明如何验证方案有效。这套模板在真正面试的时候救了我好几次因为它保证无论面对多么开放的问题我的回答都是结构化的不会东一句西一句。5. 让答案经得起验证源码、Demo和面试复盘5.1 每个答案都要能追溯到源码整理笔记的过程中我给自己立了一条规矩凡是机制类的答案必须能找到源码或官方文档的出处不能只靠二手博客。这条规矩一开始执行起来很痛苦但坚持到中期效果特别明显。以React为例我在读调度相关的源码时把scheduler的更新队列和优先级模型划了重点理解了为什么高优先级的更新可以打断低优先级的渲染读useEffect源码时搞清楚了它和useLayoutEffect在commit阶段的区别一个是passive effect在layout之后异步执行一个是同步阻塞布局。这些理解写进笔记后我在面试中说到React的并发特性时能自然地讲出可中断渲染和优先级调度到底是怎么落地的而不是停留在概念名词的套用上。面试官立刻能感觉到你不是只看了几篇渲染原理的文章而是真正读过代码。5.2 模拟面试是检验笔记质量最好的方式我整理笔记的时期每周会请一位同行扮演面试官针对笔记里的重点章节提问每次一小时。第一次模拟时候我被问到一个我自己写过答案的问题但当场讲出来的效果和笔记里写的完全不是一回事——我又回到了东拉西扯的状态。后来我复盘发现原因是笔记里的答案是书面语句子结构太复杂口头表达跟不上。从那之后我在笔记里给每个核心答案增加了一段口语化版本把长句拆成短句把复杂逻辑拆成分步。比如事件循环的书面版可以写当前宏任务执行完毕后清空微任务队列再执行下一个宏任务口语版我就记成三步先看本轮宏任务完事清空微任务清空了再拿下一个宏任务。这种变化在模拟面试中效果立竿见影口头表达的流畅度提升了一大截。模拟面试的价值就在于你会发现自己以为会了和真能讲出来之间的鸿沟。5.3 面试后的复盘-增补-重答闭环每次真实面试结束我都会做一件事把现场没答好或答得磕巴的题记进错题清单并在当天晚上重新整理答案、补充追问方向第二天再对着镜子把这道题讲一遍。这个闭环看起来笨但特别有效。我有一次在面谈中遇到一个关于Web Worker的问题面试官问Worker和主线程之间到底应该传数据还是传节流之后的控制消息我当时答得很模糊只说了Worker处理完计算再传回来。回来后我查资料发现其实对于高频计算任务正确的思路是减少传递的消息数量把计算和任务调度尽量都放在Worker内部完成通过批量回报或者采样回报来降低通信成本。我把这条经验补充进笔记还写了一段为什么大量数据传输会让主线程阻塞更严重的分析。后来在另一场面试中又遇到类似问题我直接给出了完整的答案还顺带讲了如何用Transferable Objects把数据的所有权转移给Worker来优化。这时候我意识到面试本身就是最好的补充教材只要你愿意在做完题之后回头补笔记。6. 五年前端面试的临场经验如何把笔记优势发挥出来6.1 简历的写法决定了面试官问你什么很多人的简历写的是一串参与了XX系统开发负责XX模块这种写法看起来在事无巨细但实际上面试官从中根本提炼不出什么有效问题只能去问通用的基础题。基础题范围太广你准备得再充分也难免有盲区。我在更新简历的时候意识到简历其实是你给面试官划的重点写什么面试官就大概率问什么。我把简历里每个项目都改成了矛盾-方案-结果的句式。比如后台报表查询在数据量突破千万级后出现白屏通过拆解长任务、接入Web Worker并行渲染、实现虚拟表格将首屏加载时间从8秒降到1.2秒。这样一个描述面试官自然会顺着追问千万级数据量为什么会导致白屏、Web Worker怎么并行渲染的、虚拟表格的实现原理是什么。这三个问题恰好都是我笔记里准备最充分的章节。让面试官问你会的问题不是投机取巧而是筛选信息、展示你最擅长的领域。6.2 追问链条的应对结论先行再给证据大厂面试官有一个统一的爱好就是往下追问。你给出一个结论后他会追为什么然后你再抛出一个更深层的概念他又追底层怎么实现的。应对这条追问链条我总结出一套固定打法先一句话说结论再分步骤给依据最后给一个可验证的例证。举个例子被问到为什么说React的diff算法是高效但仍有局限性的我会先说结论因为diff是在同层级内进行复杂度从树形递归的O(n³)降到了O(n)但降复杂度的代价是跨层移动节点需要走删除重建而不是移动。然后下一步具体说老三样也就是同类型节点比对、key的作用、props变更触发的更新最后举一个例子说明为什么把一个节点从树的顶层挪到深层React会先销毁再创建而不会直接移动。这个三步结构能确保即使面试官不断追问我也始终踩在自己的逻辑线上而不是越追越乱。6.3 准备周期与体力分配最后说一下体力问题。整理十万字笔记真正的时间投入比想象中大得多。我的节奏是把准备周期分成两个阶段第一个阶段约三到四周每天下班后花两小时左右按知识域逐个击破每周末留出一整个下午做模拟面试和复盘第二个阶段是面试期间不再新增知识只翻笔记里的关键词和错题清单保持状态。面试本身是很耗体力的一天安排两场已经是上限。从我的实际经验看上午的面试状态通常比下午更容易调动起来所以尽量把最重要的面试放在上午场。还有一个小经验每次面试前提前一小时看一遍自己笔记里最核心的一页不求临时记住什么就是为了让思维提前进入讲技术的模式。准备工作做到这个程度考验你的就不再是记忆力和临场发挥而是情绪和体力管理了。最后再说几句实在话。整理笔记和面试准备这件事真正改变我的不是拿到了offer而是让我重新审视了自己自认为很熟的知识体系。以前写代码遇到问题能解决就过去了很少去追问底层机制到底是什么。现在我不太一样了看到任何一个API或者框架特性都会习惯性地问一句它为什么这样设计它的边界条件是什么如果面试官再多问两层我能不能接得住这份笔记后来我也没有再按十万字的规模去维护因为核心的知识框架已经牢牢长在我脑子里了。就跟健身一样增肌的过程很痛苦但一旦肌肉形成了日常维持只需要少量训练就行。如果你也在准备跳槽我建议你别直接拿来背任何面试题集而是从自己最薄弱的知识域开始亲手写一份专属笔记。别人整理好的答案永远代替不了你自己推导出来的理解面试官也一眼就能分辨出你的答案是背出来的还是长在脑子里的。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
