两年前整理电脑文件时翻出一份同程2017年的校招前端笔试试卷，当时自己的批注还留在上面。那次笔试我记得很清楚，题目不算偏，但覆盖面很广，从基础的HTML/CSS到JavaScript闭包原型链，再到浏览器缓存和跨域方案，最后还有一道算法题。当时因为一道事件循环的输出顺序题纠结了很久，结果最后面试环节，面试官也追着那道题问了我十分钟。这几年陆续以面试官身份参与过校招出题和评审，回过头再看这类试卷，越发觉得其中很多考察点并不过时，只是换了一种问法继续出现在今天的前端面试里。
这篇文章想和你一起复盘这份试卷的完整考点，并结合我这些年实际做项目和面试候选人的经验，聊一聊哪些题目值得认真对待，哪些题目背后的设计思路才是真正的考察目的。不管你是在准备校招，还是已经工作两年想梳理基础，这篇文章应该都能给你一些参考。
1. 2017年同程前端笔试试卷的卷面结构与考察逻辑
1.1 整份试卷的题型分布与时间压力
先还原一下这份试卷的大致结构。整张卷子满分100分，考试时间90分钟，题型分为四块：
- 选择题：约15题，每题2分，共30分，覆盖HTML/CSS/JavaScript基础、浏览器、网络协议。
- 填空题：约10题，每题2分，共20分，偏重概念记忆和代码输出结果。
- 简答题：4题，每题5分，共20分，需要手写代码或简述原理，比如事件代理、闭包的作用、跨域解决方案。
- 编程题：2题，每题15分，共30分，一道是数组去重和排序，一道是DOM操作相关的功能实现。
90分钟做完全部题目，时间其实非常紧张。选择题基本要求一分钟之内出答案，填空题考验的完全是记忆的准确度，简答题和编程题则需要比较扎实的手写代码能力。
我在实际监考和批改试卷时发现，很多考生前面选择题做得不错，但到编程题就直接空着。原因倒不是完全不会写，而是时间分配出了问题——前面简答题写得太详细，每道题都恨不得把原理从头讲到尾，等做到编程题的时候只剩下二十分钟。
所以这张卷子的第一个隐藏考点其实是时间管理：你能不能识别哪些题值得深写、哪些题点到即止。这个能力放到今天的前端面试同样重要，特别是在两小时的机试限时环节里，合理的做题顺序往往比多掌握一个冷门API更有实际价值。
1.2 这份试卷在当年前端招聘里所处的位置
2017年正好处在前端行业的一个分水岭。React已经发布了16版本，Vue 2.x 也已经火了一年多，但很多学校的课程里教的还是 jQuery 那一套，大多数应届生简历上写的都是"熟悉jQuery、Bootstrap，了解AngularJS"。
同程这类OTA（在线旅游）公司，业务特点是页面多、交互密集、需要大量活动页和H5页面支撑运营需求。所以校招笔试的考察思路很明确：不追新框架，更看重基础是否扎实、能否快速上手业务开发。
这也解释了为什么这份试卷里几乎没有React或Vue相关的题目。倒不是说这些技术不重要，而是那个阶段校招的核心目的是筛选可培养的苗子——框架可以入职后再学，但JavaScript语言特性、浏览器工作原理、网络基础这类知识，靠短期突击很难真正理解透。
这个逻辑放到今天依然成立。虽然现在的前端面试必问框架源码、工程化、性能优化，但很多公司在校招第一轮仍然会先用基础题过滤一遍候选人。我见过不少简历上写着精通Vue的同学，问他flex布局和float布局在实际项目中你怎么选型，反而说不清楚。基础这关，永远绕不过去。
2. 基础三件套考点复盘：HTML/CSS/JavaScript各自问到了什么深度
2.1 HTML部分：语义化不是口号，是实实在在的页面结构能力
试卷里HTML相关的选择题大概有3-4道，主要围绕语义化标签、表单元素和HTML5新特性展开。
有一道题我记得很清楚：给出几个标签，让选择哪些是HTML5新增的语义化标签。选项里有header、nav、div、section、aside、span。这道题的陷阱在于section——它不是像div那样的纯容器，而是带有主题意义的内容区块，但很多教材里并没有强调这一点，导致很多考生把section标成了"不确定"或者干脆漏选。
另一道比较有意思的题是考察label标签的两种关联方式：一种是用for属性指向输入框的id，另一种是把输入框嵌套在label内部。这道题本身不难，但它背后的实际场景是表单可用性。我在写活动页时经常遇到表单校验报错信息要点击才能聚焦输入框的需求，如果HTML结构里没有正确使用label，这个交互就得靠JS手动绑定事件，麻烦不少。
填空题里还考了>function createCounter() { let count = 0; return function() { count += 1; return count; }; } const counter = createCounter(); counter(); // 1 counter(); // 2
这道题考察的不只是闭包的语法，而是闭包能保存变量的核心特性。如果候选人对闭包的理解停留在"函数里面返回函数"这个层面，那他在真实项目里很可能写出内存泄漏的代码——比如在setInterval里无脑挂载闭包函数，或者在一个长列表循环里反复创建匿名函数导致每次渲染都丢失DOM事件绑定。
原型链的考察方式是一段代码输出题，定义了构造函数和实例，然后问instance.hasOwnProperty('xxx')和'xxx' in instance的区别。前者只看实例自身属性，后者会沿着原型链查找。这道题背后考察的是对JavaScript继承机制的理解，也是后来面试官追问的重点。
事件循环方面，2017年的试卷考的是setTimeout、Promise的执行顺序，但当时的Promise还不是面试主流，更多是考setTimeout嵌套的时间计算。放到现在的标准看，事件循环的考察已经升级到微任务、宏任务、requestAnimationFrame执行时机等更细的维度，但基础逻辑没有变：理解JavaScript是单线程的，理解同步代码先执行、异步回调按队列顺序执行。
2.4 当年高频出错题：typeof null 与 instanceof 的关系
填充题里有一道非常经典又坑人的题：typeof null的输出结果是什么。答案是object，但这个结果其实是JavaScript语言设计上的一个历史bug。很多考生记住了答案，但不知道这个bug是怎么来的——在JavaScript最初实现中，对象类型的类型标签是0，而null表示空指针，在底层也是0，所以typeof null就误判成了object。
我在这里展开讲一下，因为这道题体现了一种面试态度：你只是背了答案，还是真正理解语言的设计和缺陷。今天的面试官同样喜欢问这类"反直觉"问题，比如[] == ![]的结果为什么是true，或者0.1 + 0.2 !== 0.3是因为浮点数精度问题。这类问题的价值不在于那个输出结果，而在于候选人是否具备从语言规范层面去分析问题的能力。
3. 浏览器与网络知识：分值不高但区分度最高的部分
3.1 HTTP状态码与前端缓存策略
试卷里有一道选择题列出几个HTTP状态码，让选择哪个表示永久重定向，哪个表示临时重定向。正确答案是301永久、302临时。这道题放到2026年来面试，我会追加一个问题：什么时候用301，什么时候用302？如果网站域名从http切换到https，你希望搜索引擎和设备端把旧地址永久导向新地址，就用301；如果只是临时维护页面，希望用户在维护结束后继续访问原链接，就用302。
更有区分度的是缓存策略的考察。试卷里问到Cache-Control和Expires的区别，答案是Expires返回的是绝对时间，如果客户端本地时间和服务器时间不一致就会出现缓存失效的问题；Cache-Control里的max-age是相对时间，以浏览器发起请求的时间为基准，不会受时钟偏差影响。既然Cache-Control更可靠，为什么还有Expires存在？因为老版本浏览器不支持Cache-Control，做降级兼容时需要同时携带两个头。
还有一类关于协商缓存的题：ETag和Last-Modified的区别。Last-Modified的粒度是秒级，如果文件在极短时间内被修改了两次，Last-Modified可能感知不到；ETag是基于文件内容生成的哈希值，能精确感知内容的变化。两种机制通常配合使用，浏览器发起请求时同时携带If-Modified-Since和If-None-Match，服务器端优先校验ETag，一致则返回304，不一致则返回200和新的资源。这套知识在校招层面的考察并不多，但真正参与过线上性能优化的前端都应该烂熟于心。
3.2 输入URL到页面展示，中间发生了什么
简答题里有一道"描述在浏览器地址栏输入一个URL并回车后发生了什么"，这道题现在看起来已经是前端面试的"传统艺能"了，但2017年时还不算烂大街。这道题考察的是候选人对整个Web链路的完整认知，从DNS解析、TCP连接、TLS握手、HTTP请求、服务端处理、响应返回、浏览器解析HTML、构建DOM树、加载CSS和JS、渲染页面，再到关闭连接。
我当时批改试卷时发现一个规律：能完整写出DNS解析和TCP三次握手的考生很多，但能把浏览器渲染过程说清楚的很少。很多人知道DOM树和CSSOM树合并成渲染树，但不知道为什么会有"DOMContentLoaded"和"load"两个事件，也不知道JS脚本放在body底部和用defer/async加载的区别。
这样一个题目其实有层次之分。初级回答：输入URL、DNS解析、发起请求、拿到HTML、解析渲染。中级回答会把缓存策略也加进去：先查浏览器缓存，命中就直接用，不发起网络请求。高级回答则会把现代浏览器的渲染流水线也纳入讨论——HTML解析、样式计算、布局、绘制、合成，以及每个阶段可能的优化点。
3.3 跨域问题的三种主流解法
跨域是当年简答题的必考内容，今年仍然是。2017年时主流方案是JSONP、CORS和反向代理（nginx层转发），现在则多了postMessage和WebSocket这些场景化的方案。
我比较建议用"什么是同源策略"来切入回答。同源策略是浏览器出于安全考虑提供的机制，它限制一个源的文档或脚本与另一个源的资源进行交互。所谓同源，是指协议、域名、端口三者一致。
JSONP的原理是<script>标签不受同源策略限制，所以可以通过动态插入script标签来加载跨域接口返回的JS脚本。但它只能发GET请求，而且它本质上是在执行一段远程代码，安全性需要靠服务端保证。CORS则是服务端在响应头里加Access-Control-Allow-Origin，告诉浏览器这个请求是被允许的。现在的主流方案基本就是CORS，配合withCredentials来处理携带Cookie的情况。
如果问"为什么不用JSONP来请求POST接口"，这个问题能区分出候选人是不是真的理解了JSONP的原理，而不是只知道这个名词。试卷里这个问题出现在简答题，批改时我看到最多的情况是：候选人写出了JSONP原理，但没有提到它只支持GET请求。这是个很典型的细节盲区。
4. 框架与工程化：2017年考得不深，但可以看出你是否具备现代前端意识
4.1 当时的框架题：jQuery 依旧在，MVVM 刚露头
这份试卷的框架相关考察并不难，主要是jQuery的选择器和事件绑定方式。有一道填空题是写出$(document).ready(function(){})和window.onload的区别，答案是前者在DOM树构建完成后就执行，后者要等页面所有资源（包括图片、样式、脚本）都加载完才触发。这个考点放到今天也是有用的，因为理解页面加载阶段的不同事件执行时机，是做性能优化和首屏渲染方案的基础。
值得一提的是，试卷里有一道开放性的简述题：谈谈你对前端框架的理解。这个题没有标准答案，批改时主要看候选人能不能说清楚框架解决的问题。当时比较优质的回答会提到数据驱动视图——不需要手动操作DOM，通过数据变化自动更新UI；组件化——页面拆分成可复用的独立单元；状态管理——复杂应用中数据和视图的一致性维护。如果能提到虚拟DOM的性能优化思路，基本就是这批候选人里的头部水平了。
放到2026年来看，这个开放性问题的考察逻辑依然适用。只是"谈谈你对前端框架的理解"在今天会更倾向于追问具体框架的源码实现，比如Vue的响应式原理、React的fiber调度、组件通信方式等。但底层逻辑没变：你在用一个框架，你要知道你用它来解决什么问题，它帮你省掉哪些工作，它又引入了哪些新的复杂度。
4.2 工程化萌芽：模块化与构建工具的初步考察
2017年时前端工程化已经萌芽，但校招笔试对这块的考察非常基础，只考了模块化的几种方案：AMD、CMD、CommonJS、ES6 Module。很多考生知道ES6 Module是标准，但说不清楚它和CommonJS的关键区别——ES6 Module是编译时静态分析，可以做到依赖静态解析，支持tree-shaking；CommonJS是运行时加载，模块导出的对象是值的拷贝，而不是引用。
实际开发中，这个区别带来的影响很直接：如果你在一个循环里动态require模块，CommonJS允许，但ES6 Module不行（它的import必须放在顶层）。反过来，ES6 Module因为静态分析可以做tree-shaking，CommonJS则不行。这些知识点在今天的前端构建优化里依然是核心概念，只是换了问法，比如"打包出来的代码里为什么会有死代码没有被移除"。
构建工具的考察只停留在概念层面，问了webpack是干什么用的。答案是好理解：模块打包、资源处理、开发服务器、代码分割。但如果今天面试再问webpack，我大概率会追加一个追问：webpack的loader和plugin有什么区别？loader负责对特定类型的文件进行转换（比如sass-loader把SCSS编译为CSS，babel-loader把ES6+编译为ES5），plugin则是在webpack构建流程的特定节点执行更复杂的任务（比如HtmlWebpackPlugin在打包完成后生成HTML文件）。
4.3 从同程的业务场景推测考点背后的意图
同程作为OTA公司，前端业务场景里大量涉及列表页、详情页、下单流程和多端适配这类需求。所以试卷里有一道很贴近业务的题：一个页面里有多个相同结构的列表项，如何给每一项绑定事件，可以做到性能最优。
这题考的就是事件代理。当时写答案的思路是：利用事件冒泡，在父容器上统一监听click事件，通过event.target判断点击的具体是哪个子元素，再做对应处理。这样做的好处是：减少内存占用（不需要给每个子元素都绑定事件）、动态添加的子元素不需要额外绑定事件。
这道题看起来简单，但我后来在面试里经常把它升级成"为什么要用事件代理"来考察候选人的性能意识。如果候选人能答出"动态列表在初始化时为空，等数据返回后再渲染节点，如果用循环绑定事件，每次渲染都要先解绑再绑定，不仅麻烦而且容易造成内存泄漏"这个层面，那他大概率是理解这个问题本质的。
这道题放到今天的价值依然很高。现在很多React/Vue应用里，开发者直接在组件里写onClick={() => handleClick(item)}，并不会意识到这个写法在长列表里会创建大量匿名函数，导致内存占用上升和渲染性能下降。虽然现代框架在虚拟DOM层面做了很多优化，但这个性能问题本身并没有消失。
5. 算法与逻辑题：校招笔试的硬骨头，也是面试追问的重灾区
5.1 数组去重与排序的多种解法
编程题第一题是：给一个数组，要求去重并按从小到大排序。这道题不限定算法，也不限定语法，给了很大的自由发挥空间。我批改时看到三种主流写法：
第一种是ES6的Array.from(new Set(arr))，简洁且正确，但也会暴露一个问题——考生如果只写过这种方法，让他现场换个思路（比如用双指针或者filter）就会卡壳。所以题目后面还有一个追问：如果不用Set，你会怎么写？
第二种是filter + indexOf组合：arr.filter((item, index) => arr.indexOf(item) === index)。这种写法能工作但时间复杂度较高，数组是修改过的，每次indexOf都要遍历一次原数组。如果数组长度在万级别，这种写法会明显卡顿。
第三种是"对象键名法"：用一个对象来记录已经出现过的元素。这个方案在ES5时代非常流行，但有一个坑：如果数组里同时存在数字1和字符串'1'，它们会被当作同一个键，导致去重错误。所以要配合typeof加类型前缀。能把这个坑说明白的候选人，说明他真的动手调试过细节。
排序方面，直接调用arr.sort((a, b) => a - b)是最常见的写法，但有些考生不知道sort默认的排序规则是按字符串UTF-16码元比较的，所以[10, 9, 8].sort()得到的是[10, 8, 9]而不是[8, 9, 10]。这个看似简单的知识点，正好能区分出候选人有没有踩过这个坑。
5.2 手写一个防抖函数
编程题第二题是手写一个防抖函数。这在当年已经算比较贴近实际开发的题目了。防抖（debounce）和节流（throttle）的区别是：防抖是事件停止触发后的一段时间内没有新事件才执行；节流是固定时间间隔内最多执行一次。
我当时写的是：
function debounce(fn, delay) { let timer = null; return function(...args) { clearTimeout(timer); timer = setTimeout(() => { fn.apply(this, args); }, delay); }; }要注意的是fn.apply(this, args)这里为什么用this。因为返回的函数是被调用时，内部this应该指向调用它的那个对象，比如button.addEventListener('click', debounce(handleClick, 300))，绑定事件后，回调函数里的this指向button元素，如果这里不把this绑定进去，回调函数里的this就会变成undefined（严格模式）或window。
除了防抖，面试官也常常追问节流，以及两者各自适合的场景。防抖适合搜索框输入联想、窗口resize后停止调整再计算；节流适合滚动事件里的无限加载、拖拽时的位置更新。每道算法题都要配套能落地的场景，不然面试官容易判断你只是背了代码模板。
5.3 逻辑题：不只是考"聪明"，也考沟通思路
试卷最后还有一道逻辑题，类似"有一个天平和一个已知重量的砝码，如何在若干次称量中找出唯一一个重量不同的球"。这类题目没有标准解题过程，面试官看重的是候选人如何拆解问题、如何在信息不完整的情况下提出合理的假设。
这种题在笔试里的作答质量很能看出一个人的思维方式。优秀的答案会把问题抽象成"用尽量少的比较次数找出异常元素"，然后设计决策树。普通的答案会从心算开始穷举。空白的答案说明候选人遇到没见过的题容易直接放弃，这也是一种信号——实际工作中你遇到的很多问题都不是教科书原题，能不能在压力下保持分析能力才是关键。
现在的前端算法面试已经更倾向于LeetCode风格的数据结构与算法题，但这道逻辑题的位置依然有意义：它提醒我们，笔试题可以考察的不只是知识点，还可以观察解题过程本身。
6. 从2017年的试卷看今天的面试：哪些考点会变，哪些底层逻辑不会变
6.1 已经过时或边缘化的考点
时代的痕迹在这份试卷里很明显。jQuery相关的内容今天基本不会再出现在校招笔试里了，除非少数老项目维护岗还在用。AMD、CMD模块化规范也被ES Module和打包工具彻底取代，现在的候选人打开webpack配置看到require的时候，对CommonJS还有印象已经算基础扎实了。
width和height解析盒模型的考法也在变。过去面试必问box-sizing: border-box和content-box的区别，现在这道题的存在感已经降低，因为主流样式方案里border-box基本是全局设置的默认选项。但换个角度说，正因为它是默认选项，很多候选人反而不理解它解决了什么问题——如果面试官追问"为什么现在默认用border-box"，很多人说不出"因为它能让padding和border包含在设定的宽高内，更容易实现预期布局效果"。
6.2 至今仍活跃在面试一线的核心考点
像事件循环、闭包、原型链、跨域、性能优化、模块化这类基础知识点，到今天依然是前端面试的核心盘。只是问法更灵活了，从"解释什么是闭包"变成了"这段代码里闭包导致的问题是什么，怎么解决"；从"说一下跨域的解决方法"变成了"这个线上页面为什么请求被拦截了，你会从哪些方面排查"。
这种变化本质上是在考察一个更底层的迁移能力：从背诵知识点到运用知识解决实际问题。2017年的试卷里，"描述URL输入到页面展示全过程"是一道简答题，今天的面试里，它可能被揉进一个更高层次的追问链：为什么这个页面首屏资源在弱网环境下要拆成两份加载？这涉及到TCP拥塞控制、HTTP/1.1的连接限制、CDN回源耗时、服务端渲染拆包策略等综合知识。
所以我的建议是：不要只刷"最近一年出现的面试题"。把2017年这份老试卷里的基础题认认真真啃一遍，再往后延伸思考"这个知识点在什么时候会出问题""出问题了怎么排查"，这种复习的深度远比刷十遍八股文更有底气。
6.3 我作为面试官，会怎么用一套基础题来判断候选人
这几年我参与校招评审时，一般会用一套组合拳来考察候选人，大致思路是这样：
- 笔试阶段基础题筛掉"完全没有动手写过代码"的简历选手；
- 技术面第一轮会从笔试错题切入，看候选人能不能现场复盘自己当时的思路并纠正；
- 第二轮会结合一个实际业务场景，让候选人现场设计方案，比如"列表页筛选功能怎么做，涉及哪些性能考虑"；
- 终面则看软素质、学习能力和团队协作意愿。
这套流程里最核心的原则是：笔试的分数不是目的，分数背后的思考过程才是。一道考察事件委托的选择题，两个人同样做对了，但一个是因为在项目里真的遇到列表渲染性能问题主动做了优化，另一个只是背过"事件代理能提升性能"这个结论。这两者在面对后续追问时的表现会天差地别。
所以我在批改试卷时，往往更关注那些"虽然结论错误，但推导过程里有合理假设"的答案——这种候选人往往只是缺一个正确的上下文，但分析框架是对的，培养起来会很快。
6.4 从基础题到架构思维的延伸
如果只把这份试卷的价值停在"刷题"层面，那格局就小了。它其实反映了前端面试的一个稳定趋势：基础决定下限，思维决定上限。
先看基础决定下限。一个候选人如果连flex布局都写不利索，连Promise.all和Promise.race都分不清，那把他招进来后，他看到现在的复杂业务界面，光是处理样式问题就会耗费大量时间，更别提让他独立负责一个模块。基础扎实意味着他不需要在琐碎问题上频繁求助，同事和导师可以聚焦在更高层次的设计指导上。
再看思维决定上限。一个候选人即使基础稍弱，但如果他能从一道"数组去重"的题延伸出时间复杂度、空间复杂度、边界条件、哈希碰撞、类型转换这些分析维度，那他大概率是个值得培养的好苗子。因为前端这个行业演进速度极快，今天的主流框架几年后可能就变成历史产物，真正留下来的是你分析和解决问题的能力。
从这份2017年的试卷来看，今天的前端面试并没有抛弃这些基础考察，只是把它们包装成了更复杂的业务场景。不管你是准备踏入前端的新人，还是工作几年想往上走的进阶者，把这份试卷当作一面镜子，对着它检验一下自己的知识体系是否还有盲区，是很有价值的动作。
7. 复盘完这套试卷后，我的一些实操建议
7.1 给正在准备前端校招的同学：怎么高效利用老试卷
老试卷最有价值的地方在于，它能帮你快速搭出一个知识框架。拿到一份试卷后，我建议先别看具体题目，自己先画出这个岗位需要掌握的知识地图，再对照试卷的考点去补漏。
以这份2017年同程试卷为例，基本知识地图应该是：
- HTML：语义化、表单、HTML5新特性、可访问性。
- CSS：选择器、盒模型、布局（浮动、定位、flex、grid）、响应式、动画。
- JavaScript：数据类型、作用域、闭包、原型链、异步（回调、Promise、async/await）、事件机制、DOM操作。
- 浏览器与网络：HTTP协议、缓存、跨域、渲染机制、性能优化。
- 框架：理解至少一个主流框架的核心思想。
- 工程化：模块化、打包工具、代码规范、测试。
- 算法与数据结构：数组、字符串、链表、树、排序、动态规划；以及至少能手写常见的前端工具函数。
对着这张地图把每一块的知识点都过一遍，再去找对应的笔试题练习，效率比盲目刷十套试卷要高得多。
7.2 给工作两三年想跳槽的前端：基础常看常新
很多有工作经验的前端容易陷入"框架源码看得飞起，但基础概念反而模糊"的状态。我在面试一些工作两三年的候选人时，经常遇到简历上写着精通性能优化，但问到浏览器缓存时只会说"浏览器自动缓存了"的人。
如果你属于这种情况，建议每半年做一次基础复盘。不用大块时间，像下面这种方式就很有效：
- 每周抽半天时间写一两个手写题：数组去重、防抖节流、深拷贝、Promise实现、instanceof实现。
- 把常用HTTP状态码（200、204、301、302、304、400、401、403、404、500、502、503）的含义和出现场景再过一遍。
- 打开Chrome DevTools的Network面板和Performance面板，重新分析一次自己的项目：资源大小、加载顺序、阻塞原因、缓存命中情况。
这些东西看起来基础，但它们才是你做性能优化的底层依据。你不理解304 Not Modified是怎么触发的，看到线上"304"就会以为请求出错了，接着就往错误的方向排查，浪费大量时间。
7.3 给面试官的一个建议：从错题里看思维，而不是只看对错
如果你也参与前端校招出题或评审，我想分享一个这几年实践下来的感受：批改试卷时减少"对错二分法"，多关注候选人写下的推导过程。
比如一份试卷里，候选人在编程题里用filter + indexOf实现了数组去重，虽然没有用上ES6的Set，但代码逻辑清晰、变量命名规范，还在注释里说明了时间复杂度。这类候选人实际工作上手速度往往比那些背了一个标准答案但一问三不知的候选人快得多。
反过来，如果候选人所有题都答对了，但问到他项目里遇到的问题是怎么排查时支支吾吾，那他在实际工作中的表现未必理想。笔试只能考察你知识点的覆盖度，真正决定职场表现的是把知识用出来的能力。
近年来我在技术社区里看到很多"前端面试八股文汇总"之类的资料，有人同意有人反对。我的态度是：与其说八股文没有价值，不如说它的价值在于"帮你建立知识索引"，而真正的理解必须靠你自己在项目里反复验证。就拿闭包来说，你看了十个"闭包是什么"的文章，不如自己去写一个会导致内存泄漏的组件，然后在排查过程中真正理解它背后的引用关系。
这份2017年同程前端笔试给我最大的启发是：无论技术和框架怎么迭代，对一个合格前端工程师的要求里，"扎实的计算机基础 + 清晰的逻辑思维 + 能落地的工程能力"这三个维度一直没有变。变的是考察方式，不变的是底层能力。希望这篇复盘能给你带来一些不一样的角度，也欢迎你在评论里聊聊最近一次前端面试里让你印象深刻的题目。
