前阵子有刚转行做前端的同学来问我前端到底要不要刷题不刷题感觉心里没底刷题又不知道从哪里开始网上搜“web前端练习题”出来一堆链接资源质量参差不齐刷了几天反而更焦虑。我太理解这个状态了因为我也经历过那个阶段——一边觉得手写代码的能力很重要一边又不知道什么题值得刷、怎么刷才有效。这篇文章就把我对“web前端练习题”的全部理解整理出来包括前端题的类型版图、一套我自用的刷题闭环、练题过程中最常见的翻车现场以及如何把练习题变成简历和面试里真正拿得出手的东西。适合正在自学前端的初学者、准备找实习的应届生以及想系统巩固基本功的在职前端。不保证看完就能拿 Offer但能帮你把每一道题练出应有的价值。1. 我为什么建议你别把前端练习题和算法题按同一个套路刷很多人一说“刷题”脑袋里自动切换到 LeetCode 那种状态刷数量、拼速度、背套路。这个习惯放到前端练习题上很容易越刷越偏。1.1 前端题的“回答对象”不是判题机是浏览器和用户算法题的答案判定非常明确输入数据、跑完测试用例、比对输出结果。对就是对错就是错。前端练习题则完全不同——它的“回答对象”是浏览器渲染出来的页面是用户实际操作时的体验是代码在真实网络环境、真实设备上的表现。举个例子同样是“实现一个弹窗组件”算法题不会关心这个弹窗在 375px 宽的手机上显示会不会溢出不会关心用户点击遮罩层关闭时会不会误触内部按钮也不会关心动画掉帧的问题。但前端练习题会关心而且往往会围绕这些细节分出不同水平的答案。我见过一个很典型的对比同一道“页面里有一个按钮点击后三秒弹出提示框”的练习题A 同学 10 分钟就写完了用 setTimeout 实现看起来没问题B 同学写了一个组件做了点击防抖、组件卸载时清除定时器、移动端触摸事件兼容。谁的答案更好在“判题机”视角下这俩都是满分但在前端练习题的视角下B 同学才真正理解了“在浏览器里运行”意味着什么。刷前端题的时候脑子里要同时有三个角色你是在写代码的工程师同时也是审查渲染结果的 QA还是那个即将被这个页面卡住或者惊艳到的用户。1.2 新手练“手稳”进阶练“思路”这是两套打法前端练习题确实有一个从易到难的过程但难度的分水岭不在题目数量而在练习目标。基础阶段的目标是“手稳”HTML 结构语义化是否顺手、CSS 布局能不能做到心里有数、常用 JS 数组字符串方法能不能不查文档就写对。这个阶段适合大量刷基础题因为每一道题都是在给手指和大脑建立肌肉记忆。我当时练 CSS 垂直居中把浮动的写法、Flex 的写法、Grid 的写法、绝对定位的写法各练了不下二十遍后来做任何布局都能快速挑出最合适的那一种。进阶阶段的目标是“思路”这时题目数量反而不重要了。一道“实现一个带搜索框的下拉多选组件”能把受控组件、事件冒泡、虚拟列表、防抖、样式隔离这些点全部串起来思考价值远超十道互相独立的小题。这个阶段与其说是刷题不如说是“解题”——你真正面对的是如何把一个笼统的需求拆成明确的技术决策。所以我建议你在刷题之前先想清楚自己处在哪一层不然容易出现“看了很多题、好像都会、一写就废”的尴尬状态。2. 前端练习题的五块版图从像素还原到源码复刻如果你打开任何一份所谓“前端练习题大全”大概率会看到一堆杂乱的题目混在一起。我习惯把前端题分成五类每一类的练法、重点、时间投入都不相同。2.1 结构与视觉还原题练的是“眼睛里有没有尺”这块主要涵盖 HTML 语义化、CSS 布局、盒模型、响应式设计、常见 UI 组件还原。典型题目包括用 Flex 实现经典的圣杯布局、用 Grid 做一张照片墙、把一个设计稿精确还原到像素级。这类题的核心能力是“视觉敏感度”和“布局确定性”。很多人写出来的页面“差不多”但仔细一看文字和间距差了 2px、不同断面上按钮位置飘了、明明可以用 Grid 两行搞定却写了一百多行 hack。练习这类题时我建议你开浏览器开发者工具去量每一个间距、圆角、字号然后问自己我能不能不看代码就知道这个元素在这个位置为什么这么宽一个高效练习方式是把某知名网站首页截图下来用纯 HTMLCSS 还原它的布局骨架不需要还原图片和文案只还原结构和间距。这个做法对训练布局直觉非常有效。遇到问题就去看它的源码再回头改自己的代码对比差异。2.2 JavaScript 手写题练的是“语法背后的运行机制”这是面试中最常被问到的一类因为手写题能快速看出你对语言机制的理解。高频题目有手写防抖节流、手写深拷贝、手写 instanceof 和 new、手写 call/apply/bind、实现一个简易 Promise、实现数组的 map/filter/reduce。这类题别看表面是“背代码”实际考察点是你知不知道函数执行上下文发生了什么、原型链怎么走、异步队列怎么排队。拿手写 bind 举例它考的不只是“返回一个新函数”还要求你理解 this 指向、参数拼接、以及 new 调用时 bind 绑定的 this 要被忽略。当年我第一次写的时候漏掉了 new 的情况后来花了一个晚上专门搞懂 new 和 bind 的关系才算是真的把这道题吃透。我给自己定的标准是能不看参考答案写出来并且能说出每一行代码存在的理由才算通过。下面是一个防抖手写的例子代码很短但值得反复体会计时器清除的时机function debounce(fn, delay 300) { let timer null; return function (...args) { if (timer) clearTimeout(timer); timer setTimeout(() { fn.apply(this, args); }, delay); }; }如果你能顺手说清楚“为什么要用 apply 绑定 this”“箭头函数和普通函数在这里的区别”这道题才算真正属于你了。2.3 框架与状态管理题练的是“抽象思维和组件边界”现在的前端面试和工作中React、Vue 这类框架逃不掉。框架类练习题常见的有实现一个受控 input 组件、设计一个通用 Table 组件、实现组件间通信兄弟组件、跨层级、写一个简单的全局状态管理器。这类题最值得练的不是 API 调用而是“组件边界怎么划”。同一个功能有人把所有状态都放一个组件里最后改一个字段要传三层 props有人拆成容器组件展示组件数据流清晰得多。做题时我建议你刻意练习一个习惯写组件之前先把 props 和 state 列出来再想清楚哪些状态该由父组件管理、哪些该内部管理、哪些需要提升。我曾经做过一个模拟项目要求用组件化的方式写一个标签输入框功能包括输入后回车生成标签、支持删除、支持键盘导航。一开始我所有状态都堆在一个组件里代码越写越乱。后来我拆成 Input 子组件、TagList 子组件和父级容器三层的职责才彻底清楚了。这个拆解过程本身就是这类练习题的价值。2.4 工程化与性能优化题练的是“全局视野”前面三类题大多聚焦在代码本身工程化题则关注代码之外的基础设施Webpack 或 Vite 的配置优化、代码分割、Tree Shaking、Gzip 压缩、懒加载、图片优化、首屏加载时间分析。这类题很少让你从零写一个打包器更多的是给你一个场景让你分析性能瓶颈并给出优化方案。比如一个首屏加载 3 秒的长页面可能的原因有哪些这时候你要能说出资源体积过大、请求过多、渲染阻塞、图片未压缩等方向并能给出对应的检查工具和优化手段。练习这类题我比较推荐的方式是自己做一个玩具项目故意把体积写大——引入一个巨大的组件库、不开启代码分割、图片也不压缩然后用开发者工具的 Performance 面板和打包分析插件看问题在哪再逐个优化。如果你能记录下优化前后的数据变化这个练习就算做到了满分。2.5 场景设计与综合应用题练的是“把需求翻译成技术方案”最后一类是综合性最强的一般会给你一个完整需求比如“实现一个带搜索、筛选、排序的用户列表页”“做一个支持无限滚动的图片瀑布流”“实现一个购物车结算模块”。它考的不只是某一个知识点而是组件怎么拆、数据怎么管、交互怎么做、边界情况怎么处理、性能怎么保证。这类题最接近真实工作场景也最能暴露你的工程素养。拿到题不要急着写先在注释里或者草稿纸上列出涉及哪些状态、哪些组件、哪些交互事件、哪些边界条件。把这一步做好后面写代码会顺手很多。我常拿“图片懒加载”做综合练手对象因为它几乎是前端各类知识的交汇点需要监听滚动事件会涉及防抖节流、需要处理图片加载失败的回退、需要兼容不同浏览器的 API、还要合理运用 data 属性和自定义指令或高阶组件。一道题练下来等于同时复习了五六个知识点。3. 一套自用的前端刷题闭环预判、拆解、复写、复盘刷题最怕“题做了人没变”。我形成了一套固定的做题流程每一道值得练的题都走四步效率比随便刷高很多。3.1 预判先回答三连问再动手拿到一道题先不写代码先问自己三个问题这道题在考什么能力它用到了哪些知识点它在真实项目里对应什么场景比如“实现一个 Promise.all”考点是 Promise 异步机制和数组遍历场景是批量请求的并发控制。想清楚这三点你才知道自己该从哪个方向去思考而不是直接开始硬写。这个预判步骤还有个额外好处能帮你筛选题目。如果一道题你连它考什么能力都说不清那它大概率是一道拼凑出来的废题不值得在上面花时间。前端练习题资源确实很多但质量参差不齐预判就是你的第一道过滤器。3.2 拆解把一道大题切成一系列小任务碰到复杂题目我会把它拆成“最小可跑通版本”和“逐步增强版本”。拿“实现一个拖拽排序列表”来说拆解后大概是先让列表能渲染出来再给每个列表项加拖拽事件拖动时通过数据变换更新顺序最后加上动画和边界判断。每一步都可以单独验证即使最后没做完你也至少完成了一个能运行的部分。拆解还有一个作用避免被“这道题好难”吓退。很多人看到综合题直接放弃其实把它拆成三五个小步骤之后难度就降到了可以动手写代码的程度。先去写最核心的那一步写到一半思路自然会延伸出来。3.3 复写关上参考答案从头写一遍看答案写代码是最容易产生“我会了”错觉的环节。我给自己定的规矩是看了答案之后必须关上答案从头自己写一遍而且是在一个新的文件里不是把答案改几个变量名就当作自己会了。复写过程中卡住的地方才是你真正需要学的地方。比如你复写一个深拷贝函数写到最后发现没有处理循环引用那你就在这个点上去查资料、看文章、找解决方案。这个“卡住—查询—解决”的循环才是刷题提升的关键。如果复写一遍就能顺利写出来说明这道题你已经内化了可以直接进入下一道。3.4 复盘记录“我和参考答案的分歧点”做完题之后我会打开一个专门的练习日志记录几个问题我写的方案和参考答案的最大差异是什么这个差异是因为我没想到还是因为思路不同如果重新做一次我会在哪里改进举个例子有一道题是实现数组扁平化。参考答案里用了递归我最初用循环写出来了。复盘时我记录的差异点就是递归版本处理深层嵌套时代码更简洁但存在栈溢出的风险循环栈的版本稍微长一点但更稳定。这个记录在面试时可以直接作为“有深入思考”的论据来讲比单纯背答案好得多。复盘还有一个衍生用法每隔一两周翻出之前的题目不看笔记再看不看代码重新写一遍。如果还能写出来恭喜你这道题已经刻在脑子里了如果写不出来说明之前的“会了”是假象需要回头重新练习。4. 前端刷题路上的典型翻车现场与应对策略刷题这件事方向错了比不刷更可怕。我自己踩过坑也见过很多人踩同样的坑下面这几个翻车现场最有代表性。4.1 跟着答案抄了一遍就觉得自己会了这是最常见的幻觉。很多人刷题的时候对照着答案写一遍还运行通过于是觉得这道题掌握了。真到面试或者实际写代码的时候完全想不起来。对策就是我前面说的复写关上答案重新写。另一个办法是给这道题换一个壳——比如刚练完防抖就自己设计一个“搜索框输入停顿 500ms 自动请求”的场景重新实现一遍。改变外在场景能检验你是不是真的理解了机制而不是只会抄那一份代码。4.2 只刷手写题到了项目里还是不会用前端练习题库里手写题是最容易让人沉迷的因为每做完一道都有“我今天解决了三个问题”的成就感。但真实项目里没有任何一道题叫“请手写一个 debounce”只有在输入框快速输入的时候你才想起该用防抖。这个问题我的解决方法是每刷十道手写题就强迫自己做一个综合练习把其中至少两道融入一个有完整页面的小项目。刷手写题积累零件做项目练习把这些零件组装起来两组交替进行效果会好很多。4.3 只练热门大厂面试题忽视基础题经常有人拿某公司面试题到处问其实那些题往往高度依赖特定业务场景不具备普遍性。而真正容易被面试官问住的反而是那些看起来很简单的基础题比如“说说盒模型”“块级元素和内联元素的区别”“事件委托的原理”。这些题看着简单但想讲清楚、讲全面是需要花功夫的。我在练习日志里专门列了一个“基础题清单”每两周过一遍每个知识点都用一两句话把本质说清楚。答不上来的标记出来重新看资料。基础题就像是房子的地基漂亮的手写代码像装修地基不牢的装修再好看也撑不住。4.4 过度追求源码复刻把阅读源码变成背诵源码有一类高难度练习题是“读源码、复刻源码”比如实现一个简化版的 Vue 响应式系统、实现一个 React Fiber 的调度模型。这类题对进阶很有价值但也容易走向极端为了在面试时讲源码把代码逐行背下来结果只记住了调用栈没理解设计动机。我的判断标准是如果你能在不参考源码的情况下用你自己的话讲清楚“为什么要这么设计”那才算读懂了。比如读响应式系统源码你能明白“为什么 Vue 3 要用 Proxy 替代 Object.defineProperty”能说出二者在拦截能力上的差异这比背下一整段源码更有价值。复刻源码是手段理解设计思想才是目的。5. 从练习题到项目如何把刷过的题变成简历上敢写的东西刷题刷到最后总要把成果沉淀下来。只在一个个练习文件里躺着的代码价值很有限把它们变成完整、可展示的项目才真正算是对练习成果进行了变现。5.1 把多个练习串成一个综合 Demo前端练习题过于分散每一道都像一颗珠子你要做的是一根线把它们串起来。我做过一个模拟项目名字叫“跨端表单增强组件库”听起来复杂其实核心就是把几道经典练习题组合在一起防抖搜索框、虚拟滚动列表、自定义多选下拉、表单校验、可拖拽排序。每一道题单独看都是常见的练习题组合在一起就是一个能跑的、有完整交互的小型组件库。组合的过程会逼着你处理练习题里没有的细节组件之间怎么通信、公共样式怎么抽离、数据格式怎么统一。这些综合问题里的“意外”恰恰是刷单题永远练不到的部分。5.2 给练习题套上工程化外壳我会把练习代码放到一个规范化的工程目录里带上完善的 README、类型定义、单元测试、构建脚本并且精心写一份文档说明设计思路。这个过程回顾了第 2.4 节提到的工程化能力模块划分、依赖管理、脚本配置、性能优化。你在 README 里可以大方地写“这个组件使用了防抖和虚拟列表技术”面试官看到的不只是一道练习题而是一个具备工程素养的作品。这套做法尤其适合简历项目经验还不够丰富的同学拿完整、干净、有文档的作品去弥补项目经历的空白。5.3 面试里怎么讲练习题才不会像背题很多人面试讲项目时习惯用“我们用了什么技术栈——实现了什么功能——遇到了什么问题”这个顺序。讲到练习题项目时更容易变成背题的复盘把代码从头背到尾。我建议换一种讲法从需求出发讲你怎么拆解、怎么对比方案、为什么选择了现在的方案。比如你做的是表单增强组件库可以这样讲业务里面需要支持大规模数据下的选择器直接渲染一万个选项会让页面卡顿所以我用到了虚拟滚动只用渲染可视区内的内容输入搜索时需要频繁请求数据所以用防抖控制请求频率。这样讲一道平平无奇的练习题就变成了一个完整的工程决策故事。面试官关心的从来不是那道题的答案而是你做答案时的思考过程。另外一个很实用的技巧是挑出练习题里你觉得最有分享价值的两个“坑”来讲。比如我在实现虚拟滚动时发现滚动容器和列表项的高度计算容易产生偏移后来通过固定行高加缓冲区的方案解决。这类具体的踩坑经验比“我熟练掌握了 XXX”有说服力得多。说实话前端练习题的资源从来不缺缺的是认真对待每一道题的态度和一套适合自己的练习方法。我自己从盲目刷题到现在每道题都走一遍“预判、拆解、复写、复盘”的流程用同样的时间换来的成长明显不一样。如果你也正在刷题的路上希望这篇文章能帮你少走一些弯路。最后再分享一个小习惯每练完一道觉得不错的题把它记录到你的练习库一个月后回头看看你会发现自己已经比想象中强了。