说实话把“Web前端学习感悟”这个系列写到第二篇并不是因为我第一篇写完之后特别有底气。第一篇里的我刚刚把 HTML、CSS 过了一遍能用 flex 排版会用 media query 做响应式就觉得自己已经摸到了前端的门槛。真正让我改变想法的是后来接到的一堆“看起来不难、做起来全是坑”的小需求页面上的弹窗要能拖拽、表单要实时校验、列表要按条件过滤、数据要分页加载……每一样单拿出来都不算复杂可一旦组合在一起我那套“写一段代码、刷一下页面、再看效果”的老办法就完全失灵了。这篇《Web前端学习感悟二》我想认真聊聊从“会做页面”到“能想清楚再做”的这段过渡期。文章里没有特别高深的内容更多是实实在在的学习复盘哪些概念我当时没读懂、后来是怎么补上的哪些坏习惯让我反复返工哪些方法让我终于开始看得懂别人的代码、自己的代码也慢慢变得可维护。如果你正处于“能照葫芦画瓢写页面但一涉及 JavaScript 状态、组件划分、调试性能就心虚”的阶段这篇应该能给你一些可以直接拿走的参照。1. 从“会做页面”到“能想清楚再做”1.1 第一阶段复盘我以为自己会了先说一段让我印象特别深的经历。某项目里要做一个带搜索、筛选、分页的列表页按我第一期的水平第一反应是先把页面结构写好把 CSS 调漂亮然后到交互部分直接在事件里写一堆 DOM 操作比如 getElementById 拿节点、改 innerHTML、循环拼字符串。听上去很顺但真正跑起来到处都是问题数据一变列表没有刷新翻了一页之后搜索条件丢了筛选和分页各自维护一套逻辑到后来根本想不起哪个状态由谁在管。我回头想这个问题发现自己犯的最大的错是“眼睛盯着页面没盯着数据”。做静态页面的时候内容是写死的怎么改都不容易出大问题可一旦页面开始动态变化核心就不再是“画布上有几个元素”而是“这些元素根据什么状态、什么数据、在什么时机发生变化”。我没有先把数据关系想清楚就直接开始拼 DOM这就像盖房子不看图纸先搬砖垒墙垒到一半发现承重墙的位置不对。所以第一期到第二期之间我做的第一件事不是学更多新框架而是把之前写过的所有动态页面翻出来重新审视每个交互背后对应的数据是什么这些数据从哪里来、到哪里去页面上一共有几份“会变的状态”事后回看这一步比多会一个 API 重要得多。这里要多说一句前端学习里最迷惑人的就是“写出来了”和“写对了”之间的距离。很多 bug 不是语法错误而是逻辑设计时埋下的雷。如果你刚开始做动态页面我特别建议多问自己上面三个问题不要一拿到需求就急着切页面。1.2 真正的转折点从改代码到看代码我后来的一个转折点是开始认真读别人的代码。以前遇到问题我的常规操作是网上搜一段代码复制下来改改能跑就算成功。结果就是同一个问题换个场景又不会了因为那段代码我根本没看懂。真正打破这个循环的是一次排查事件失效的经历。页面里有一层遮罩点击遮罩要关闭弹窗但无论我怎么绑事件点击都没反应。后来发现遮罩被一个内层元素冒泡上来的点击事件拦截了而那个事件处理器里执行了 stopPropagation()。当时我对“事件冒泡”“事件捕获”这些概念只有模糊印象看了别人的解决方案才明白一个点击事件的完整路径是从顶部节点往下捕获到目标元素再冒泡回顶部。任何一层只要阻止了传播外层监听器就永远等不到自己那一枪。从那以后我开始养成了一个习惯遇到问题先打开浏览器开发者工具里的 Sources 面板给关键代码打断点一步步看执行顺序和参数变化而不是着急改代码。断点调试的最大好处是强迫你承认代码运行的顺序和你脑补的顺序不一样。这种偏差恰恰是大多数“玄学 bug”的来源。1.3 一套我自己总结的“动手前清单”在反复踩坑之后我给自己定了一套动工前的检查清单不一定适合所有人但对我这种记性不好、又爱直接上手的人特别有效这个页面或组件有哪些随时间变化的数据这些数据的初始值是什么什么时候会被更新有哪些用户操作会触发这些更新触发入口在哪个组件里数据更新之后哪些视图会受影响影响的边界在哪这张清单看起来很基础可它解决了我最痛的问题写代码时“害怕改这里坏了那里”。如果我能清楚地知道一个状态只在某个组件内部起作用那改起来就很有底气反过来如果说不清某个变量的影响范围它迟早会给自己“惊喜”。这套方式还有一个附加收益它让我在沟通需求时能提出更具体的问题。比如“这个列表是只在筛选后显示还是一直显示”这种问题看似零碎却能省掉后面大量返工的时间。2. JavaScript 基本功值得再砸三个月2.1 闭包、作用域这些概念到底卡在哪我一直觉得前端第二阶段学习里最磨人的不是框架 API而是 JavaScript 语言本身的一批基础概念。闭包就是其中之一。当时看到各种博客把它讲得神乎其神说什么“函数内部的函数”“变量被记住了”我听完还是云里雾里。直到我遇到一个真实的 bug一个循环里给一组按钮绑定点击事件渲染之后点哪个按钮打印出来的都是最后一组数据。这就是经典的“循环里用 var 声明变量”的问题代码如下for (var i 0; i 3; i) { setTimeout(function () { console.log(i); // 输出 3 3 3而不是 0 1 2 }, 0); }第一次看到输出是三个 3 的时候我整个人是懵的。后来才慢慢理解var 声明的变量是函数作用域整个循环只存在同一个 i等定时器回调真正执行时循环早就跑完了i 已经变成了 3。而用 let 声明时每次循环都会创建一次块级作用域每个回调记住的是自己那一轮的 i。这个例子也让我重新理解了闭包回调函数引用了外层的变量导致外层变量被“留着”不被回收这就是闭包。它不是什么高深魔法而是一个很自然的机制。理解它之后很多代码行为都能解释通了——比如为什么组件里定义的定时器要在组件销毁时清掉为什么一不小心某些变量就变成了“全局污染”。2.2 异步不是“背代码”是“排时间表”我以前背过 Promise、async/await 的语法但真正用起来还是经常出乱子接口请求的顺序不对、数据的展示时机不对、loading 状态一闪而过或者永远不消失。后来我才意识到问题出在我根本没理解“事件循环”这个底层调度机制。用现实生活打比方页面里的任务可以分为几类同步任务就是“当前窗口正在处理的操作”必须立即做完微任务是在同步任务结束后、“回到窗口重新取号”之前插进来的小任务宏任务则是排在“取号队列”里的下一批任务。一个最简单的例子console.log(1); Promise.resolve().then(() console.log(2)); setTimeout(() console.log(3), 0); // 输出顺序1 - 2 - 3刚开始我以为这段代码会按 1、3、2 的顺序输出结果被现实纠正了微任务永远会比下一个宏任务更早执行。别小看这个顺序它直接影响你在真实项目里写“先请求接口再根据结果操作 DOM”的代码。async/await 只是语法糖底层的调度逻辑没变。现在我写异步代码时会强制自己先把“哪个操作等待哪个结果”想清楚再动手。比如一个页面要并行拉两个接口就考虑两路请求同时发起一个操作依赖另一个操作的结果就串行等待。想清楚了再写回调嵌套会少一大半出错的概率也明显下降。2.3 数据结构与算法在前端里的真实出场率再说一个很多新手会纠结的问题前端到底要不要学算法我的答案是常见的数据结构和思想必须会但不必一上来刷几百道题。真实场景里数组去重、对象转 Map、深拷贝、树形菜单展开、长列表渲染……这些每天都在用。举一个我印象很深的例子后端返回了一个菜单树前端要按 id 快速找到某个节点原来我是用数组一个个找数据量小没事菜单一多就开始慢。换成先把数组转成 Map再用 key 直接定位速度立刻就不一样了。这就是数据结构的价值不是考试题是能实打实省时间的工具。前端框架里也有算法的影子比如渲染列表时为什么要给每一项一个稳定的 key。框架对比新旧列表时如果没有 key只能按顺序一个个比对一旦你删掉中间一项后面的项全部要重新渲染有了稳定的 key框架才能知道“这一项还是原来那一项”。这个细节不深但理解了它能帮你避开很多性能问题。3. 组件化与状态管理的数次踩坑3.1 组件拆分的边界怎么定进入组件化阶段之后我一度掉进另一个极端什么都想拆成小组件。结果组件数量爆炸父子组件之间 props 传得又长又乱改一个样式要顺着五层组件往上找。后来我才慢慢找到一点感觉组件拆分的边界应该跟着“变化”走。一起变化的 UI 和逻辑放一起单独变化、独立复用的部分抽出来。举个例子一个表单页面里输入框的校验逻辑、错误提示、样式都在一个小范围内变化那这部分适合抽成独立的输入组件而整张表单提交后的成功提示跟页面跳转逻辑关系紧密硬拆出去反而要传一堆回调得不偿失。我给自己定了一条很朴素的规则至少有两个地方用到或者一个组件内部的复杂度已经高到自己都看不下去了才考虑拆。为了“看起来规范”而拆组件只会徒增沟通成本。3.2 状态管理不是越重越好第二个让我反复纠结的是状态管理。看了一些项目之后我一度觉得“状态不用全局管理库好像就不专业”于是不管组件树多浅都往全局状态里塞。结果呢把本该局部的状态放到了全局代码里到处都是“设置状态”“读取状态”的调用别人接手根本看不出来一个变量到底是哪块业务在用。其实可以先用一个简单的分级方法判断状态应该放在哪一层状态类型典型例子建议存放位置组件私有的临时状态输入框内容、下拉菜单展开组件内部需要传递给子组件列表数据、选中项提升到共同父组件跨多个不相关组件共享用户登录信息、主题配置全局状态或上下文这个表格看着简单却帮我把“什么时候才需要引入重型状态管理”这个问题想明白了只有当一堆互不相干的组件需要读同一份数据或者数据更新时机很复杂时才值得把状态放到全局。一般的页面靠组件内部状态加父组件传值就够用了。3.3 数据流的单向性与调试革命我学习组件化过程中受益最大的一件事就是理解了“单向数据流”数据从父组件传到子组件子组件不直接改父组件的数据而是通过事件把“想改数据”的请求告诉父组件由父组件统一更新。听起来绕但它解决了一个大难题出 bug 时你能顺着一条清晰的方向追踪而不是在组件树里到处找是谁改了数据。举个很简单的例子父组件有一份用户列表子组件渲染列表项并提供一个删除按钮。我早期的写法是子组件直接操作那份列表数组结果一个页面上多个入口都能改数据改来改去状态就乱了。改成单向数据流之后子组件只负责把“用户点了删除、删的是哪一行”这个意图抛给父组件父组件统一更新列表。代码看起来多了一行事件派发但调试时你能明确知道数据只在父组件里变排查范围一下子缩小了很多。这个习惯不依赖任何特定框架只要是组件化的设计这套思路都适用属于非常值得花时间养成的思维。4. 调试与性能前端进阶的试金石4.1 开发者工具不只会看控制台以前我打开浏览器开发者工具只会两件事在控制台里看报错在元素面板里改样式。后来才发现我错过了很多重要的面板。先说网络面板。页面里某个接口请求失败了第一反应不该是反复刷新猜原因而是打开网络面板看请求状态码、耗时、请求参数、响应内容。有一次我排查一个“列表偶尔为空”的问题点开接口响应一看某个字段在数据量大的时候会变成空值而后端接口文档里没写这个边界。如果没有网络面板这个 bug 我可能排查一整天。再说源代码面板。打断点并不是资深工程师才会的事。在可疑代码行上点一下刷新页面代码执行到这一行会停下来你可以看到所有变量的当前值、调用栈里的每一层。我第一次用的时候就被震撼到了原来代码真的可以“放慢速度”来看。很多“明明逻辑没问题却不对”的问题靠打断点一步步走几遍往往就能发现是某个变量的值和你设想的不一样。4.2 把“感觉卡”变成数字性能优化如果没有数据支撑就很容易变成“我感觉快了”“我感觉还慢”。我学习到这个阶段时最怕的就是改来改去没有对照标准。后来我养成了一个习惯用浏览器自带的性能检测工具定期跑一遍页面重点看几个核心指标指标含义我的参考目标首次内容绘制页面第一个文本或图片出现的时间2.5 秒以内最大内容绘制页面主要内容渲染完成的时间2.5 秒以内累积布局偏移页面加载过程中元素跳动的程度0.1 以下这几个指标里累积布局偏移是我以前最容易忽略的。有一次页面图片加载出来后下面的内容被挤着跳了一下用户反馈“页面在抖”。我用性能工具一测布局偏移评分很高。原因就是图片没有预留宽高图片加载前后占位大小不一样。后来我给图片显式设置了宽高布局偏移立刻就降下来了。很多性能问题不看数字是发现不了的。4.3 常见问题速查我踩过的“玄学”坑分享几个我实际踩过的性能坑每一个最后都找到了可以解释的原因现象根因处理方式页面循环时卡顿循环里反复读写布局属性先读后写批量改样式点击一次触发多次回调动态元素重复绑定事件事件委托到容器层动画卡顿掉帧每一帧触发重新布局优先用 transform 和透明度图片加载后页面跳动图片没有预留尺寸显式指定宽高或比例占位第一个坑最典型。在循环里反复用 offsetWidth 这类属性会强制浏览器重新计算布局一两次没什么循环几百次就卡。正确的做法是先把尺寸读出来存到变量再统一改样式把布局计算的次数攒到一次完成。第二个坑是事件监听器“越绑越多”。动态创建的元素每次都绑定事件又不清理用户操作多了以后一次点击触发的回调数量会非常吓人。解决办法是把事件委托到容器上事件只绑一次所有子元素点击都走同一个入口。第三个坑是“改样式却不考虑性能”。以前我为了做一个动画在每一帧里同时改宽度和定位属性结果浏览器每一帧都要重新计算布局。后来知道动画尽量用 transform 和透明度这两类属性可以被硬件加速不会每次都触发整个页面的重新布局。这些知识都不算高深但每一个都是我之前真实卡过的地方。5. 工程化与学习路径的再认识5.1 构建工具帮你做了什么学习到后面我不可避免地碰到了“工程化”这三个字。第一次看到一堆配置文件时我心里是抗拒的我一个写页面的为什么要理解打包、构建、依赖这些后来我明白了如今的前端开发早就不是“写一个 HTML 文件双击打开看效果”那么简单。组件化、模块化带来的好处是代码可以拆成很多个文件方便维护和复用但浏览器没法直接运行那种“在一个文件里引用另一个文件”的写法或者某些新语法浏览器还不支持。构建工具做的事情简单说就是把开发时利于人阅读和组织的代码转换成浏览器能高效运行的代码顺便做压缩、合并、加缓存标记。打个比方开发时你的代码是“一堆零件加说明书”构建工具负责把它们组装成一台“可以直接交给客户使用的机器”同时还把包装做得更小、更快。理解了这一点我就不再害怕那些配置项了因为每一步改配置都对应着一个实际的诉求比如“这个库太大了我想拆开来分别加载”。实际项目中我们通常会在命令行里执行两类命令一类是开发时用的启动本地服务、实时预览另一类是发布前用的产出经过压缩和优化的正式版本。刚接触工程化时不用急着记住所有配置项的写法先理解“开发环境”和“生产环境”的区别就已经能跨过最大的理解门槛。5.2 源码阅读的正确姿势很多同学一听“读源码”就头疼觉得那是大牛才能干的事。我的体会是读源码的关键不是从第一行读到最后一行而是带着问题“点状切入”。我自己的方法是这样先在项目里找一个自己用过的 API顺着调用栈点进内部实现只看跟当前调用相关的部分。看不懂的变量先跳过把主干逻辑理出来再回去补细节。这样读起来源码不是一个几千行的方块而是一条可以顺着走的路线图。这个方法还改变了我对“看文档”的态度。以前我看到某些 API 的说明写得含糊就会烦躁这到底什么意思后来发现很多情况下直接看源码里这个 API 的几行实现就能看懂它做了什么比猜文档的潜台词快得多。对新手来说读的第一份源码不一定要选那种动辄上万行的项目找一个你天天在用的中等规模工具库看它一个方法是怎么写的就足够开始了。5.3 我一直在用的学习节奏最后说一下我自己验证过比较有效的学习节奏不一定适合所有人但很适合那种“看着好像学了很多、一动手就慌”的状态。我基本是按“学一点 - 立刻做一个小实验 - 写几句复盘”的循环走。小实验不用大比如今天学了并发请求就写一个几行的小页面模拟两个接口同时请求明天学了事件委托就改造一个昨天刚写的列表。每次只专注一个点做完在笔记里用一句话写下“这个东西在什么场景能用、有什么坑”过一段时间回头看会比反复看视频有效得多。还有一个小习惯是定期从自己项目里找“可优化的旧代码”。我每隔一两周会把之前写的某个功能重构一遍能不能少几次重复代码组件边界有没有需要调整的数据流清不清楚这种“回头看”的过程既是复习也是把新学的知识真正内化到已有项目里的好办法。我的很多进步其实不是在学新东西的时候发生的而是在改旧代码的时候发生的。
