前端面试高频考点整理
前端面试高频考点整理
面试这事儿，说简单也简单，说难也难。难的不是题目多高深，而是你明明会做，却总在关键时刻掉链子。前段时间帮朋友做模拟面，结果一顿操作猛如虎，最后被问到“说说从输入URL到页面展示发生了什么”，愣是卡壳了三秒。那三秒里，脑子里像放幻灯片一样闪过各种知识点，却拼不成一张完整的地图。后来复盘才意识到，前端面试考的往往不是“会不会”，而是“能不能说清楚、能不能落地、能不能兜底”。今天就把这些高频考点捋一顺，不整虚的，全是实战里会撞见的坑和路子。
先说最常被拿来“开刀”的JavaScript基础。很多面试官喜欢从变量、作用域和闭包切入，听起来老套，却最能照出底子。有次面一个自称三年经验的候选人，问“var、let、const的区别”，回答得很顺，说let有块级作用域、不能重复声明。到“闭包是什么”时，他说“函数里返回函数”。再往下问“闭包会导致什么问题”，就只剩“内存泄漏”四个字，具体怎么泄漏、怎么排查、怎么解，没下文。其实闭包真正让人头疼的，是它让变量的生命周期脱离了函数调用的自然节奏。比如一个事件处理函数里引用了外层的大对象，页面关了还在内存里占着，这时候光知道概念没用，得能拿出WeakMap、事件解绑、手动置null这些具体手段。还有this指向，别背“箭头函数不会改变this”这种结论，要能在call、apply、bind和new混用的场景里，说清楚每一步this到底落哪儿。面试不是默写文档，是看你能不能在业务代码里把坑提前填上。
再说异步和Promise，这几乎是前端绕不开的坎。现在项目里到处都是await和.then，但一问到“Promise如何实现链式调用”，很多人就开始背规范。真正能拿分的，是能画出一条时间线：executor里resolve的是一个普通值还是一个Promise、微任务队列和宏任务队列谁先清空、async函数里抛错怎么冒泡、去catch。实际项目里，最典型的坑是“幽灵加载”——多个请求并行却串行化了，或者竞态条件下旧结果覆盖了新结果。有个做商品详页的案例：用户快速切换规格，接口A比接口B慢，结果B先返回、A后到，页面展示的还是上一个规格的数据。解决思路不复杂，用AbortController取消上个请求，或者用标志位拦截过期回调，能在白板上说清楚这种设计，比背一百道Promise题更让人安心。
工程化和性能优化，也是高频重灾区。面试官最爱问“你是怎么提升首屏速度的”，如果只回答“压缩资源、用CDN、懒加载”，基本就到顶了。真正拉开差距的，是对链路每一环的量化理解。比如打包阶段，怎么用tree shaking把没用到的代码真正摇掉，而不是只配个mode=production就当完事；怎么拆分chunk，避免vendor包大到改一行业务代码就全量更新。运行时层面，缓存策略不只有强缓存和协商缓存，还得懂Service Worker怎么兜底、怎么做离线可用。更细一点，像字体文件阻塞渲染、内联关键CSS、图片按设备像素比下发，这些细节拼起来，才是性能优化的完整拼图。有次复盘一个H5项目，首屏慢了400毫秒，最后发现是第三方埋点脚本没加async，同步阻塞了DOM构建。改完之后数据立马好看，这种“在一个系统里找到最薄环节并动手改掉”的能力，才是面试最想看到的。
框架现在虽不像前几年那样追新，但React和Vue的核心机制依然绕不开。React重点不在“会写组件”，而在对渲染机制的理解：一次setState到底什么时候触发更新，Fiber架构为什么能中断和恢复，key为什么不能用数组下标。实际项目里，最常见的性能坑是无关的rerender把一个列表全刷一遍，这时候useMemo、useCallback不是“优化标配”，而是要能说出“哪些依赖不变、哪些计算昂贵”。Vue则更强调响应式原理和依赖收集，别只说“通过Object.defineProperty或Proxy劫持”，要能解释模板编译如何生成渲染函数、依赖如何精准收集、异步更新队列怎么合并。框架题最怕背概念，面试官真正想听的，是你在一个复杂页面里，怎么用这些机制把性能和可维护性兜住。
浏览器原理和网络基础，是很多候选人“觉得不重要，结果被暴击”的部分。你也许不天天写网络请求，但页面一上线，所有人都会受到网络的影响。比如HTTPS握手到底多花多少时间、TLS版本怎么影响性能、HTTP/2的多路复用在实际接口里到底能省多少RTT。再往深一点，跨域不只是“加个proxy”或“配CORS”，还要知道预检请求在什么时候发、cookie的SameSite和跨域怎么互动、CSRF和XSS的区别和防御。有个做支付的页面，报“接口偶尔失败”，最后发现是浏览器对同域名并发请求数限制，静态资源和接口排队导致超时。这种问题，光懂“同源策略”四个字没用，得懂浏览器对每个域名的连接池管理和排队逻辑。
另外，TypeScript和工程规范也越来越常被拿出来问。类型体操不是重点，重点是“怎么用类型约束降低沟通成本”。比如一个公共组件库，如何用泛型让props和事件类型一一对应，怎么用条件类型去掉可选字段，怎么在重构时用类型报错代替回归测试。更实际的，是lint、prettier、git hook和CI/CD怎么配合，保证团队代码风格一致、提交记录可回溯。面试时能说出“我们用husky拦截不符合规范的提交，并用自动化脚本生成CHANGELOG”，比能讲出“TypeScript支持交叉类型”更贴近真实工作。
最后想说的是，考点再多，也只是手段。真正决定你能走多远的，是“把问题落到具体场景”的能力。同样是问“缓存”，有人只说localStorage和sessionStorage，有人能聊到IndexedDB的容量上限、读写性能、事务模型，以及怎么用它做离线数据同步。同样是被问到“错误监控”，能说出“用window.onerror和unhandledrejection捕获”只是起步，真正拿分的是如何把错误和用户行为、版本号、接口路径关联起来，并在发布时做回归验证。
前端这行，工具和框架换得快，底层却一直在那里：JavaScript的执行机制、浏览器的渲染过程、网络的传输规则、工程的可维护性。把这些连成一张网，再把每个节点落到具体项目里，面试就不只是“被考”，而是一次梳理和展示。下次再被问到“从输入URL到页面展示发生了什么”，别急着背八股，先在心里画一张图：域名解析、TCP握手、TLS协商、请求发出、响应回来、解析HTML、构建DOM和CSSOM、布局、绘制、合成。每一步里可能发生什么、怎么优化、怎么兜底，讲清楚这些，面试的分数自然不会低。
说到底，高频考点只是路标，真正能带你走到终点的，是你踩过的坑、填过的坑，以及下一次还能绕开新坑的判断力。把每一次面试当成一次项目复盘，把每个考点当成一个可落地的改进项，前端的路会越走越稳。