1. 题目概览与考点地图
1.1 我印象里的这份卷子长什么样
提起小米2018秋招前端笔试题，老前端应该多少都有点印象。那年的题目风格和现在动辄"手写Promise/A+"或者"用TS实现一个类型工具"的路子不太一样，整体更偏基础功底和工程落地能力的考察，覆盖面比较广，但每一道题单拎出来都不算偏门。用一句话总结就是：它考的不是你背了多少新名词，而是你平时写代码的时候，到底有没有把底层逻辑吃透。
当时我做完这套题的第一个感觉是，出题人应该是个实战派，因为卷子里有几道题明显是"工作中踩过坑，才会拿来考别人"的类型。比如闭包和定时器结合的那道经典循环输出题，还有关于事件循环执行顺序的题目，这些知识点看起来基础，但真到面试现场，能完整、准确、有层次地答出来的人其实不多。这份卷子对后续准备其他大厂笔试也很有参考价值，考点覆盖面广，难度梯度合理，从"热身题"到"区分度题"都有。
1.2 整套题的难度梯度与出题逻辑
我个人把这份卷子大致分为三个梯度。第一梯度是送分题，主要是基础的HTML/CSS/JS语法题，比如数据类型判断、作用域、选择器优先级这些，这部分只要基础扎实，基本不会丢分。第二梯度是拉分题，集中在闭包、异步、原型链、手写函数等JS核心机制上，这部分考察的是"你真的理解"还是"你只是见过"。第三梯度是拔高题，包括浏览器渲染机制、性能优化策略、框架原理等，这部分没有标准答案，考的是知识面的广度和思考问题的深度。
值得强调的一点是，小米这套题的出题逻辑很务实——它不追求题目本身的新奇，而是追求"能不能通过题目筛出真正能干活的人"。所以很多题目背后都藏着一个实际业务场景，比如问"如何实现图片懒加载"，其实是在考察你对页面性能优化的理解；问"跨域有哪些方案"，其实是在考察你平时对接后端接口时有没有真正处理过这类问题。理解了这层逻辑，你备考的时候就不会死记硬背，而是会去思考"出题人想通过这道题知道我有没有这方面的实战经验"。
2. JS基础题：别以为简单就能拿满分
2.1 数据类型与判断：typeof、instanceof、Object.prototype.toString 的三层递进
这道题几乎是所有前端笔试的必备菜，小米2018也没落下。题目通常会这样问：typeof null的结果是什么？typeof []的结果是什么？instanceof的判定原理是什么？如何准确判断一个变量的类型？
坦率说，第一问很多人能答对，但第二问和第三问就开始露馅了。typeof null返回"object"，这是JS语言设计之初留下的bug，但直到现在也没有修复——因为修复它会破坏大量现有代码。typeof []返回"object"，这同样是typeof的局限，它无法区分数组、对象、null这些"引用类型"内部的具体差异。
真正能拿到满分的回答是三层递进：第一层，用typeof判断基础类型（string、number、boolean、undefined、symbol、bigint），注意typeof null是"object"；第二层，用instanceof判断引用类型的具体构造函数，它的原理是通过原型链查找，看构造函数的prototype是否出现在对象的原型链上；第三层，用Object.prototype.toString.call()做终极判断，它会返回"[object Array]"、"[object Object]"、"[object Null]"这类精确结果。
我当时备考时专门整理过一段代码，可以直接回答"如何实现一个通用的类型判断函数"：
function getType(value) { const type = typeof value; if (type !== "object") { return type; // 基础类型直接返回 } return Object.prototype.toString .call(value) .slice(8, -1) .toLowerCase(); } // 测试 console.log(getType(null)); // "null" console.log(getType([])); // "array" console.log(getType({})); // "object" console.log(getType(new Date())); // "date"这道题背后的逻辑很清晰：出题人想确认你对JS类型系统的理解不是停留在"背结论"层面，而是真的知道每种判断方式的适用边界。如果你能顺带说一句"Object.prototype.toString之所以可靠，是因为它读取的是对象内部的[[Class]]属性，而普通方法可以被重写或污染"，那这道题基本就是满分级别了。
2.2 作用域与闭包：经典循环输出题的多种解法演进
小米这套题里有一道非常经典的闭包题：给出一段for循环代码，循环体内用setTimeout输出变量i，问最终输出什么，以及如何修改才能输出预期的结果。这道题在2018年属于"烂大街"的考法，但放到今天依然是高频考点，因为它一题能考三个核心概念：作用域、闭包、异步执行机制。
原题大概是这样的：
for (var i = 0; i < 5; i++) { setTimeout(function() { console.log(i); }, 1000); } // 输出结果是什么？答案是连续输出五个5，而不是0、1、2、3、4。原因是var声明的变量没有块级作用域，i是全局变量，等到一秒后定时器回调执行时，for循环早就跑完了，i已经变成5。而闭包捕获的是变量本身，不是变量的值——这是最核心的考点。
要修正这个问题，2018年的标准答案是两种。第一种是用let替换var，因为let具有块级作用域，每次循环都会创建一个新的词法环境，i的值会被冻结在当前迭代；第二种是用立即执行函数（IIFE）传参，把每次的i作为实参传给闭包函数，形成"值传递"的效果。
现在再回头看这道题，其实还有第三种解法，就是setTimeout的第三个参数：
for (var i = 0; i < 5; i++) { setTimeout(function(val) { console.log(val); }, 1000, i); }第三种解法当年能写出来的人很少，它利用的是setTimeout在调用回调函数时会透传额外参数的特性。如果面试时你能从var + IIFE讲到let再讲到setTimeout第三参数，最后再补充一句"其实最根本的解决思路是让每个回调函数捕获独立的变量副本"，面试官对你的评价会明显不一样——因为这说明你不是死记答案，而是真正理解了问题本质。
3. 手写代码题：这里才是真正的拉分项
3.1 数组去重：从"能用"到"优雅"的四个版本
小米这道题要求手写数组去重，看起来简单，但阅卷人其实在看你能写出几个版本、每个版本考虑了哪些边界情况。我当时在考场上写了两个版本就停了，后来复盘才发现，这道题其实是有"层次感"的——它考察的是你对ES6新特性、Set的底层原理、以及对象属性机制的掌握程度。
最基础的是用两层循环去重，时间复杂度O(n²)，能跑通但效率低；好一点的是用indexOf判断是否已存在；再往上是用Set：
const unique = (arr) => [...new Set(arr)];这是最简洁的写法，但在当年的考场上，如果你只写这一行，面试官可能会觉得你只是"知道Set能去重"，未必真正理解它为什么能去重。因为 Set 的去重逻辑是"严格相等"（SameValueZero），所以它无法区分NaN和NaN（实际上Set能去重NaN，因为NaN !== NaN但SameValueZero认为它们相等），也区分不了{}和{}。如果题目要求保留对象类型数组中的第一个相同引用，那Set依然能处理；但如果要求按JSON结构去重，就得自己写递归或者用JSON.stringify做缓存键。
我当时整理过一道扩展题的完整解法，是对任意数组的"深度去重"，可以补充一下：
const deepUnique = (arr) => { const cache = new Map(); const result = []; for (const item of arr) { const key = JSON.stringify(item); if (!cache.has(key)) { cache.set(key, true); result.push(item); } } return result; };当然这种写法也有局限——对象属性顺序不同会导致JSON.stringify结果不同，比如{a: 1, b: 2}和{b: 2, a: 1}会被视为不同。但这个补充思路在考场上说出来，绝对是加分项。
3.2 防抖与节流：手写实现背后的设计思路差异
防抖（debounce）和节流（throttle）是2018年小米笔试的高频手写题，到现在依然是面试标配。原因是它们太常用了——搜索框输入联想、滚动事件监听、resize 窗口变化、按钮点击防重复提交，随便一个真实项目里都能找到应用场景。
防抖的核心思想是"在事件被连续触发时，只有在最后一次触发后等待指定时间，才执行回调"。它的实现原理是：每次触发都清除上一次的定时器，然后重新设置一个新的定时器。这样如果用户一直快速触发，回调就永远不会执行，直到停下来。
function debounce(fn, delay = 300) { let timer = null; return function(...args) { if (timer) clearTimeout(timer); timer = setTimeout(() => { fn.apply(this, args); }, delay); }; }节流的核心理念是"在指定时间间隔内最多执行一次"。它的实现方式有两种：时间戳版和定时器版。时间戳版是记录上次执行时间，当前时间减去上次执行时间如果大于间隔就执行；定时器版是设置一个定时器，在执行完回调之前不再设置新的定时器。很多人在面试时只写了防抖，节流写不出来，或者把两者搞混。我自己的记忆方法是：防抖是"等一等再办"，节流是"办一次歇一歇"。
当时这道题还有一个隐性考察点——this的绑定问题。你在返回的新函数里调用fn.apply(this, args)，这行代码的作用是保证原函数在执行时，this指向和调用返回函数的上下文一致。如果漏掉这行，在Vue组件里用防抖函数时，this就会丢失，导致this.data访问报错。能主动提到这个细节的人，说明是真的写过实际业务的。
3.3 深拷贝：从JSON.parse(JSON.stringify())到递归处理的边界讨论
深拷贝这道题，2018年出现频率极高，小米也不例外。题目通常分两问：第一问，如何实现一个深拷贝；第二问，如果对象里有函数、Symbol、循环引用，怎么处理？
第一问的"标准偷懒答案"是JSON.parse(JSON.stringify(obj))，但面试官显然不会满足于这个。这个方案有几个硬伤：undefined、函数、Symbol 类型的属性会被直接丢弃；Date 会被转成字符串；RegExp 会变成空对象；如果对象存在循环引用，直接报错。
所以要拿高分，得手写递归版本。我当时写的思路是这样的：
function deepClone(target, cache = new WeakMap()) { if (target === null || typeof target !== "object") { return target; } // 处理循环引用 if (cache.has(target)) { return cache.get(target); } const clone = Array.isArray(target) ? [] : {}; cache.set(target, clone); // 处理Symbol属性 const symbols = Object.getOwnPropertySymbols(target); for (const sym of symbols) { clone[sym] = deepClone(target[sym], cache); } for (const key in target) { if (Object.prototype.hasOwnProperty.call(target, key)) { clone[key] = deepClone(target[key], cache); } } return clone; }那段代码里WeakMap的使用是整个实现的关键。如果不是用WeakMap而是用普通对象做缓存，缓存本身不仅可能造成内存泄漏，而且循环引用的判断也就失效了。WeakMap的键是弱引用，当原对象被回收时，缓存项也会被销毁，这是它适合这个场景的原因。考场上能讲清楚这一层，就已经超过绝大多数候选人了。另外，这里的for...in只遍历可枚举属性，所以如果对象属性是用Object.defineProperty定义的enumerable: false，那这个实现就不会拷贝它——这个边界可以在答题时主动提一句，体现你的思考深度。
4. 浏览器与网络题目解析
4.1 从输入URL到页面渲染：这道"大综合题"怎么答才能出彩
小米2018的笔试题里有一道开放性的大题，原题大意是：在浏览器地址栏输入一个网址，按下回车，到页面完整显示，中间发生了什么？这类题目现在已经是前端面试的"必考题"了，但2018年考和现在考，侧重点略有不同。
完整的回答链路大致是：URL解析 → DNS解析 → TCP连接（三次握手）→ 发送HTTP请求 → 服务器处理并返回 → 浏览器接收响应 → 解析HTML构建DOM树 → 解析CSS构建CSSOM树 → DOM树和CSSOM树合成渲染树 → 布局（Layout）→ 绘制（Paint）→ 合成（Composite）。把这条链路完整拎出来，已经能拿到基础分。
但要拿高分，每一环节都要有细节。比如DNS解析环节，要能说出浏览器缓存、系统缓存、路由器缓存、本地DNS服务器、根域名服务器这个逐级查找的完整链路，以及DNS缓存对性能的影响。比如TCP连接环节，要能解释为什么是三次握手而不是两次，"确认双方收发能力都对"这个点是核心。再比如HTTP请求环节，要能区分HTTP/1.0、HTTP/1.1的keep-alive机制和头部字段含义。
最有区分度的是渲染部分。很多候选人只会背"DOM树 + CSSOM树合成渲染树"，但深挖下去有几个关键细节：第一，渲染树只包含可见节点，display: none的节点不会出现在渲染树中，但visibility: hidden的节点会占位；第二，JS的加载和执行会阻塞DOM解析，所以script标签建议放在body底部，或者使用defer、async属性；第三，CSS会阻塞渲染但不会阻塞DOM解析。如果时间允许，你还可以补充说明现代浏览器的渲染流水线中，"布局"（Layout）和"绘制"（Paint）都会分图层，最终由GPU合成，这就是CSS动画为什么用transform比改left更流畅的原因。
4.2 跨域问题：CORS、JSONP、postMessage、代理，一个都不能漏
跨域是2018年笔试的常客，小米这份卷子出了一道"请列举跨域解决方案并说明各自的适用场景"的简答题。这道题看似送分，但真正答得全面的人不多，因为很多人只记得JSONP和CORS，对后面两种方案了解很少。
先梳理一下完整的跨域方案清单：JSONP、CORS、postMessage、window.name、location.hash、document.domain、WebSocket、代理服务器。其中JSONP的核心原理是利用script标签不受同源策略限制的特点，动态创建script标签，通过src发起带回调函数名的GET请求，服务器返回callback({...})形式的JS代码，浏览器执行后调用本地回调函数。它有个明显缺点：只支持GET请求。
CORS（跨域资源共享）是现代开发中最常用的方案，它依赖于服务器在响应头中设置Access-Control-Allow-Origin。这里有个面试官喜欢追问的点：CORS的"简单请求"和"预检请求"（preflight）的区别。当请求方法为GET/POST并且Content-Type为application/x-www-form-urlencoded、multipart/form-data、text/plain时，属于简单请求，浏览器直接发出；如果携带了自定义头或者Content-Type是application/json，浏览器会先发一个OPTIONS预检请求，确认服务器允许后，再发真实请求。能把OPTIONS请求这条路讲清楚，就说明你真的处理过跨域问题。
postMessage适合iframe嵌套场景，比如父页面和子页面通信，window.parent.postMessage(data, targetOrigin)配合window.addEventListener("message", handler)一起用，接收方必须校验event.origin的合法性，这是安全红线。代理服务器方案则是"后端转发"思路，开发环境和生产环境各有实现：开发环境用webpack-dev-server的proxy功能，生产环境用Nginx反向代理把前端请求转发到后端服务，从浏览器视角看，请求是同源的，自然不存在跨域问题。
5. 框架与工程化题目的思考路径
5.1 框架原理题不会直接问你"什么是虚拟DOM"
2018年大厂笔试已经开始出现框架题，小米也不例外。当时Vue和React正处于交替上升期，题目不会直接出"什么是虚拟DOM"这种概念题，而是放在具体的场景里考。比如："为什么在Vue组件的列表中，不建议使用index作为key值？""React中setState是同步还是异步的？"
先说key的问题。key我们平常写的时候基本都会带，但为什么不能用index、真正理解的人不多。这要追溯到虚拟DOM的diff算法。经典diff算法中有个核心假设是"同一层级的节点可以通过唯一key做最小化比对"，当列表顺序发生变化时，如果key是稳定且唯一的标识，旧节点就可以被准确复用、移动而不是重建。如果使用index作为key，当列表头部插入一条数据时，所有后续节点的index都变了，React或Vue会认为这是完全不同的节点，于是全部卸载后重建，不仅性能浪费，而且可能导致组件状态错乱。举个最常见的例子：一个带有输入框的列表，第一行输入了内容，在头部插了一条新数据后，因为index全部变了，输入框的对应关系会错乱，内容看起来"跑"到了别的行。这就是为什么key必须用唯一的id而不是index。
再说setState的同步异步问题。React的setState在合成事件和生命周期钩子里是异步的，在原生事件、setTimeout、setInterval、Promise回调里是同步的。原因是React内部的batchedUpdates机制，它在合成事件处理器中会把多个setState合并成一个更新，避免频繁渲染。这个问题当年能解开的人很少，因为它需要你确实读过React源码，而不是只调过API。被问到这类题目时，我的建议思路是：先给结论，再解释实现机制，最后补充一个实际场景来证明自己真的踩过这个坑。
5.2 模块化与打包：CommonJS、AMD、ES Module 的演进逻辑
2018年笔试里还有一类题是考察模块化规范的，比如问CommonJS和ES Module的区别。这个问题放到现在依然是高频题，但在2018年考它的意义更偏向于"你有没有在工程化项目里解决过模块依赖问题"。
CommonJS是Node.js默认的模块规范，使用require和module.exports。它的加载是同步的，模块在加载时执行并缓存结果。ES Module是ES6引入的标准，使用import和export，它是静态分析、编译时加载的，所有import都会被提升到模块顶部。关键区别在于：CommonJS输出的是值的拷贝，ES Module输出的是值的引用，所以ES Module可以做到"在模块内部修改一个变量，外部读到的是最新值"。
再往深一层，CommonJS是运行时加载，所以它可以在if语句里写require，但ES Module是编译时加载，import语句必须写在顶层，不能放在条件语句里。这也是为什么ES Module能支持"静态分析"的Tree Shaking，只有依赖分析是静态的，打包器才能安全地摇掉未被使用的导出。如果答到这里，你可以顺带提一句"webpack在打包时会把ES Module转换成浏览器可执行的代码，同时保留Tree Shaking能力，而CommonJS因为运行时特性，做Tree Shaking非常困难"，这样就把模块化和打包器串起来了，答题层次会高很多。
5.3 性能优化：一道题看你有没有"大局观"
小米笔试有一道性能优化方向的题，题目大致是"你负责的页面首屏加载太慢，你会从哪些维度去排查和优化"。这道题没有标准答案，考的是候选人的全局意识和工程经验。我当时答题的思路是按"网络层、渲染层、代码层、缓存层"四个维度来组织回答。
网络层：减少HTTP请求数（合并JS/CSS、雪碧图、小图片内联base64）、启用CDN加速静态资源、使用HTTP/2多路复用、按需加载（路由懒加载、组件懒加载）。
渲染层：CSS放头部、JS放底部或添加defer/async、避免CSS表达式、减少重排重绘、合理使用GIF转WebP图片、懒加载页面图片。
代码层：避免内存泄漏（及时移除事件监听器、清理定时器）、使用事件委托减少事件绑定数量、使用Web Worker处理密集型计算、对大列表做虚拟滚动。
缓存层：合理设置Cache-Control和Expires头、使用ETag做缓存校验、CDN缓存策略、Service Worker离线缓存。
这道题的加分项是：你能说出**"优先优化哪一块"**的判断逻辑，而不是把所有方案都罗列一遍。比如你可以说："如果首屏加载时间超过3秒，我会先用Chrome DevTools的Network面板看是什么资源占了大头；如果是图片，考虑压缩和懒加载；如果是JS，考虑拆包按需加载；如果HTML本身太大，考虑服务端渲染或流式渲染。"这种思路展示的是解决问题的能力，而不是背诵能力。
6. 面试官视角的备考建议与避坑指南
6.1 从2018到现在的题型变化：哪些没变，哪些早变了
以2026年的视角复盘2018年的笔试题，一个很明显的感受是：基础题的考察逻辑几乎没变，变的是考察载体。当年的var和let的循环输出题，现在可能变成了"这段TS代码里的类型推断结果是什么"；当年的手写深拷贝，现在可能变成了"实现一个带深浅控制参数的工具函数"。但核心考察点始终是那几个：作用域与闭包、异步与事件循环、原型链与继承、数据结构的灵活运用。
另一个明显变化是：现在的大厂笔试越来越偏重工程化场景，比如给你一段“有问题的webpack配置”，让你找出影响构建速度的原因；或者给你一个“线上白屏”的排查场景，让你按排查顺序写出步骤。这种从"考知识点"向"考排查能力"的转变，意味着准备面试时不能只刷题，而是要真真切切地动手去搭项目、排查问题、看报错。你踩过的每一个坑，可能在笔试时都是加分项。
还有一个趋势是：随着AI编程工具的普及，现在的部分笔试题已经开始允许使用AI辅助，但面试官会追问你"为什么会选择这个实现方案""这个AI生成的代码有什么边界问题"，反而不太考察手写代码的速度了。但这不意味着基础能力不重要——恰恰相反，只有你真正理解底层原理，才能判断AI生成的代码是否合理、哪里需要加缓存、哪里会有内存泄漏风险。
6.2 考场上最容易丢分的五个习惯
第一，只看结果不看过程。手写题阅卷时会看代码结构，就算最终结果不对，如果思路清晰、步骤完整，也能拿到大部分分数。所以遇到不会写的题目，尽量把思考过程写下来，不要留白。
第二，忽略边界条件。手写深拷贝忽略了循环引用，手写防抖忽略了this绑定，手写数组去重忽略了NaN——这些都是考场上最常见的丢分点。宁可多一点代码，也要把边界条件说清楚，这恰恰是程序员思维和"会写代码"之间的区别。
第三，时间分配失衡。整套笔试题的时间是有限的，前面选择题纠结太久，后面手写题就来不及。我自己的经验是：遇到卡壳的题先标记跳过，先把有把握的题写完，再回头啃硬骨头，至少保证"会做的题都拿到分"。
第四，只答不解释。笔试题比面试题更残酷的地方在于，你没法通过讲解来挽救评分。所以答题时尽量写出你的思路注释，比如在关键代码行后加一行// 防抖核心：清除上一次定时器，阅卷人扫一眼就能理解你的思路。
第五，对框架题的态度。很多候选人看到框架题就紧张，觉得自己水平不够。其实大厂的框架题大多是"以框架为背景考JS基础"，把虚拟DOM原理拆到底层，依然是JS对象和树形结构遍历的问题。所以备考时与其背框架源码，不如把基础的数据结构和算法补扎实。
6.3 回到备考本身：一份可持续刷题的路线清单
刷题不是目的，真正提升能力才是。我的个人建议是分三条线并行准备：第一条线是基础知识线，把JS核心机制（作用域、闭包、原型、异步、this绑定）过三遍以上，每过一遍都尝试不看资料手写实现；第二条线是工程线，动手做一个包含打包配置、代码规范、接口请求、错误监控的中型项目，把所有考过的工程化知识点在真实项目里跑一遍；第三条线是算法线，按数组、字符串、链表、二叉树、动态规划的顺序刷题，每天保持1-2道，目标是看到题目能快速判断"这题考什么、用什么思路解"。
笔试只是第一步，它考察的是"你有没有资格进入面试环节"。在笔试中展现出来的不只是"会不会"，还有"是否具有工程师的思维习惯"——比如面对问题时的分解能力、边界意识、表达条理。这套能力练好了，不管是2018年的卷子还是2026年的卷子，都是同一个内核。
最后分享一个我在实际面试候选人时的观察：很多人笔试分数高，但到了面试环节一聊就发现，所有的知识点都是"背"出来的，没有形成自己的理解框架。而少数笔试中等偏上的人，因为能在答案里写出"为什么这么实现，有什么替代方案，有哪些边界情况"，反而成为最终拿下offer的人。所以，刷题的时候多问自己一句"为什么"，比多刷十道题更有价值。这也是我做完小米这套2018年笔试题后最大的收获。
