我在带第一个前端实习生的前端教学时候，发现他卡在了一个极简单的前端教学问题上：

他写了一个按钮，点了没反应。前端教学控制台报错，前端教学他看了一眼，前端教学然后挠头——那行错误他看不懂。前端教学不是前端教学不认识英文，是前端教学不知道那串字符跟他写的代码有什么关系。他盯着屏幕上那个红色报错看了五分钟，前端教学最后问我：“老师，前端教学这个报错是前端教学不是浏览器的问题？”

不是。那是前端教学他代码里一个变量名拼错了。

前端教学的前端教学第一课，不是前端教学教语法，也不是前端教学教框架。是教人学会看错误。你得先让他明白，浏览器是个诚实的工具——它不会骗你，你写错了什么，它就告诉你什么。只是它的表达方式比较机械，比较啰嗦。你得教他拆解那堆英文，把“undefined is not a function”翻译成人话：“你调用了一个不存在的方法，多半是拼错了，或者这个变量根本不是你想的那个东西。”

这个能力比背一百个API都管用。因为前端这行，百分之八十的时间都在跟错误打交道。剩下的百分之二十，在写新的错误。

第二课，我会让他删掉一个元素，再手动加回来。就这么简单一个操作。但我不让他用DevTools的“编辑HTML”功能，而是让他写代码去操作DOM。他一开始觉得这有什么难的，不就是document.getElementById然后removeChild吗？

结果他写了半天，发现删掉之后加不回来了。因为他把那个节点引用弄丢了——removeChild之后，那个变量还在，但节点已经从文档里脱离了。他得先保存引用，再操作，才能加回来。这个细节，比任何理论都更能让他理解“DOM是活的，变量是死的”这个道理。

等他会处理基本的增删改查了，我才开始讲样式。但我不让他写CSS文件，我让他用JavaScript直接改style属性。他问我为什么，我说你先感受一下，用代码控制视觉是什么感觉。他改了一个div的背景色，又改了字体大小，然后他说：“原来CSS这么暴力啊，直接改属性就行。”

对，前端就是这么暴力。没有那么多玄学，就是你告诉浏览器：这个元素，长什么样，出现在哪，点击之后干嘛。它全听你的。但前提是你得说得清楚。

说到说清楚，第三课最难。我让他去给别人讲他写的代码。不是讲“我做了什么”，而是讲“我为什么这么做”。他憋了半天，说：“因为这样写比较方便。”

我说方便在哪？他说不用写那么多重复代码。我说你把这个“方便”具体化——是维护成本低？还是执行效率高？还是可读性好？他想了想，说其实都不是，他就是习惯了这么写。我说那你回去把代码改成另一种写法，然后对比一下，你就能说出为什么了。

他改完之后，发现原来的写法确实更好——不是因为习惯，是因为那个写法把状态的变更集中在一个地方，不容易出bug。他终于能说清楚了。

这时候我才开始教他框架——React也好，Vue也好，其实都是工具。工具是拿来用的，不是拿来背的。你要是连原生DOM操作都搞不明白，用框架就是空中楼阁。框架帮你优化了很多东西，但你要是不知道它在优化什么，出了问题你连排查的方向都没有。

我带他最后一个项目，是一个简单的待办事项列表。他写完，自己测了测，说感觉还行。我不说话，让他把浏览器窗口拉窄，再拉宽。他拉了一下，发现布局乱了。我说这就是下一个要学的——响应式。他叹口气，说前端怎么这么多事。

我说不是前端事多，是你终于开始看到真实世界的复杂性了。你写的代码，不只是给你自己看的，是给无数种屏幕、无数种操作习惯、无数种网络环境看的。你得学会跟这些不确定性共存。

他后来转正了，写代码还是会有报错，但他不再挠头了。他会自己读错误信息，自己查文档，自己调试。偶尔还来问我问题，但问的都是“你觉得这个交互逻辑合不合理”这种问题了。

这才是前端教学的目的——不是教人写代码，是教人解决问题。代码只是工具，你手里的工具会过时，但你解决问题的能力不会。浏览器会更新，框架会迭代，但那种“看到错误，拆解错误，解决错误”的循环，永远是这个行业的底层逻辑。

你学得会这个，前端就学得会。学不会这个，背再多API也是白搭。