test-repo/docs/zh-cn/appendix/frontend-evolution.md

前端开发入门：从"贴海报"到"搭乐高" (Interactive Intro)

💡 学习指南：本章节无需编程基础，通过交互式演示带你回顾前端开发的 20 年变迁。我们将从最基础的 HTML 讲起，一直到现代的 Vue/React 组件化开发。

先把几个最常见的新名词说清楚（后面会反复出现）：

• HTML：网页的"骨架"，负责内容和结构（标题、段落、图片、按钮）。
• CSS：网页的"皮肤"，负责样式（颜色、大小、布局、动画）。
• JavaScript：网页的"肌肉"，负责交互与逻辑（点击、输入、请求数据）。
• 框架（Framework）：一套成熟的开发方式和工具，让你更高效地做复杂页面（比如 Vue/React）。

0. 引言：网页为什么越来越难做？

最早的网页，只是电子海报——就像你在街上看到的纸质海报，只能看、不能互动。

现在的网页，是桌面级应用 (如 VS Code, Figma)——可以编辑文档、画图、玩游戏，甚至剪辑视频。

为了支撑这种转变，前端技术经历了一场从 "手工作坊" 到 "工业化生产" 的革命。

一个生活的比喻

想象你要盖房子：

• 2000 年代（静态网页）：就像贴海报。你画好一张图，贴到墙上就完事了，不能改动。
• 2010 年代（jQuery 时代）：就像请工人手动装修。你需要亲自告诉工人："把这块墙涂成蓝色"、"把那扇窗户打开"。工人很多、指令很杂，容易出错。
• 2020 年代（Vue/React 时代）：就像用乐高积木搭房子。你先设计好"房子长什么样"（设计图），然后乐高积木（组件）会自动按设计图组装好，不需要你一块一块手动拼。

核心变化只有一点：页面越来越复杂，我们需要更高效的"组织方式"和"开发方式"。

0.1 前端 vs 大前端（你到底在学什么？）

很多人说"我学前端"，但不同公司口径不一样。

• 前端（Web Frontend）：主要指"在浏览器里跑的那部分"。典型产物是网站和 H5 页面。
• 大前端（Big Frontend）：泛指"所有用户界面相关的开发"。不只 Web，还包括小程序、App、桌面应用等。

这里的几个新词（后面也会用到）：

• 端：平台/运行环境的意思，比如 Web 端、移动端、桌面端。
• H5：手机网页（本质也是 Web），通常用来做活动页/落地页，传播快、迭代快。
• WebView：App 里用来显示网页的"内置浏览器控件"。很多 App 的部分页面其实就是 WebView。
• 跨端：用一套代码同时做多个端（比如同时做 iOS + Android）。
• 原生：直接用平台官方语言/能力开发（iOS 的 Swift、Android 的 Kotlin）。

关键点：大前端不是一个"新岗位名字"，而是一种范围：把体验交付到更多平台。

---

1. 第一阶段：静态网页与切图 (2000s-)

早期网页开发像做报纸：设计师把 UI 设计切成很多小图，前端把这些图片拼成页面。 这就叫切图。

这里的几个新词：

• 静态网页：页面内容基本固定，打开就是一份 HTML 文件（不像现在很多页面是"数据驱动、可交互"的）。
• UI：User Interface，用户界面。也就是你看到的按钮、颜色、布局。

1.1 为什么会慢？

网页上的每一张小图，浏览器都要发一次网络请求。 请求越多，加载越慢。

想象一下你点外卖：

• 如果你一次性下单 10 道菜，餐厅可以一起做完送过来。
• 但如果你分 10 次下单，每次只点 1 道菜，骑手要跑 10 趟！

早期的网页就像"分 10 次下单"，每张图片都要单独"下单"（发请求）。

补充一个常见技巧：雪碧图 (Sprite)。 把很多小图合成一张大图，这样请求数会变少（但制作和维护更麻烦）。

关键点：早期网页慢，常见原因之一是"请求太多"。（图片、脚本、样式都会产生请求）

---

2. 第二阶段：移动端普及与响应式布局 (2010s)

手机和平板开始流行以后，网页必须适配不同屏幕。 这就需要响应式布局：同一套 HTML/CSS，自动根据屏幕宽度变换布局。

这里用到了媒体查询 (Media Query)： 它是 CSS 里的"条件判断"，比如"如果屏幕小于 640px，就用 1 列布局"。

想象一下你在不同房间看同一张照片：

• 在大客厅（电脑屏幕），照片可以摆大一些，旁边还能放其他装饰品。
• 在小卧室（手机屏幕），照片需要缩小，其他装饰品要收起来，否则会挤不下。

响应式布局就是"智能相框"，它会自动根据房间大小调整展示方式。

关键点：响应式让网页"会变形"，不再只适配电脑。

---

3. 第三阶段：从"手动搬砖"到"数据驱动" (jQuery -> Vue/React)

网页开始像 App 一样复杂之后，最麻烦的事变成了：同一份数据变化，要改很多地方。

举个最常见的例子：购物车数量从 1 变成 2。

• 右上角小红点要变
• 购物车页面的数量要变
• 结算按钮的价格要变

下面这个可视化演示，专门用来解释：什么是 jQuery（以及它为什么会累）。

想象一下你在餐厅当服务员：

• jQuery 时代：客人点了一份牛排，你要亲自跑厨房告诉厨师、跑吧台拿饮料、跑收银台记账。客人加菜，你又要重新跑一遍。你成了"跑腿王"，累得半死。
• Vue/React 时代：你只需在单子上写好"客人要什么"（数据），厨房、吧台、收银台会自动看单子做事。客人加菜，你只需改单子，其他地方自动更新。你成了"指挥家"，轻松优雅。

3.1 jQuery 的思路：我来"亲手改页面"

在 jQuery 时代（2005+），你通常会写很多"命令"去改页面： "找到某个元素，把文字改掉；找到某个按钮，把它禁用……"

它的问题不是"写不出来"，而是：只要漏改一个地方，页面就会出现前后不一致的 bug。 页面越大，这种 bug 越多。

就像你手动修一栋大楼：

• 你要记住"每个房间的长什么样"。
• 你要亲自"一间一间地修"。
• 如果你忘了修某间房，或者修错了，整栋楼就不一致了。

这里用到的新词（先解释清楚）：

• jQuery：早期非常流行的 JavaScript 工具库，特点是"很方便地找元素、改元素"。
• DOM：浏览器里保存页面结构的一棵"树"（按钮、文字、图片都在这棵树上）。
• ID：HTML 元素的唯一名字（类似"身份证号"），方便你定位某一个元素。
• div：HTML 里最常用的"盒子"标签，用来做布局和容器。

3.2 Vue/React 的思路：我只改"数据"，页面自己变

后来大家意识到：与其到处改页面，不如只维护一份状态 (State)。 状态变了，页面自动刷新到正确的样子。

这就是"数据驱动 UI"的核心：

• State（状态）：页面的"数据"，比如购物车数量、登录状态、输入框内容。
• 数据驱动：你只改 State，不直接改 DOM；框架负责把界面同步到正确状态。
• Vue/React：现代前端框架，主要解决"状态变化 -> 界面自动更新"。

想象一下你在玩"模拟城市"游戏：

• 你不需要"手动画每一栋房子"（手动改 DOM）。
• 你只需要调整"城市数据"（比如人口、资金、政策），游戏画面自动更新。

这就是数据驱动的魅力：你只关心"数据长什么样"，不关心"页面怎么画"。

3.3 什么是"命令式"和"声明式"？

这就好比你要画一幅画：

• 命令式：你告诉画家"拿起笔，蘸红颜料，在坐标(10,10)画一个圈"。
• 声明式：你直接给画家一张照片，"给我画成这样"。

想象一下你点披萨：

• 命令式：你亲自和面、撒料、烤披萨、切披萨。你要记住每一步，很累。
• 声明式：你只需说"我要一个芝士披萨"，披萨店自动做好。你只需"声明"你要什么，不关心"怎么做"。

3.4 交互演示：两种写法的区别

下方的演示展示了两种思维的巨大差异。

• 左边 (jQuery)：你需要手动关注每一步 DOM 操作。忘了更新 DOM？界面就不对了。
• 右边 (Vue)：你只管修改数据 count，界面自动变。

关键点：从 jQuery 到 Vue/React，变化的核心不是"语法"，而是思维方式：从"我去改页面"变成"我只改数据"。

3.5 Vue 和 React 怎么选？先把差异理解清楚

很多初学者会纠结："我到底学 Vue 还是 React？" 先别急着站队。你先把它们的"共同点"和"差异点"理解清楚，就不会被带节奏了。

共同点（它们都在解决同一件事）：

• 都是为了解决：页面复杂时，如何可靠地管理状态、更新界面
• 都强调：组件化（把页面拆成积木）

差异点（你会在写代码时真实感受到）：

• 写 UI 的方式：Vue 常用 Template；React 常用 JSX
• 状态变化时怎么更新：Vue 更偏"依赖追踪"；React 更偏"重新渲染组件函数"

这里的几个新词（像课件一样解释清楚）：

• Template：Vue 常见写法，用类似 HTML 的语法来写界面。
• JSX：React 常见写法，用"像写 JS 一样"的方式写界面结构。
• Hook：React 的一套函数式能力（比如 useState），用来保存状态、处理副作用。
• SFC：Single File Component，Vue 常见的单文件组件（一个 .vue 文件里写模板/逻辑/样式）。

关键点：别死记名词。你只要记住一句话：它们都能做同样的产品，只是"写法和心智模型"不一样。

---

4. 第四阶段：组件化（像搭积木一样写页面）

解决了"怎么更新页面"的问题，接下来是"怎么组织代码"。 以前一个页面可能是一个超大的 HTML 文件，改一个按钮可能牵连全局。

4.1 "积木"是什么？

现代前端把页面拆成了组件。 一个按钮、一个导航栏、一个商品卡片，都是独立的积木。

想象一下你在搭乐高：

• 你不需要"从头开始雕刻每一块积木"（从头写 HTML/CSS）。
• 你只需要"按说明书把积木拼在一起"（把组件组合起来）。
• 每个积木都是独立的，你可以在不同的套装里重复使用。

4.2 为什么组件能复用？

定义好一个"商品卡片"组件后，你可以由它生成 100 个实例。每个实例都有自己独立的状态（比如点赞状态），互不干扰。

想象一下你有一个"万能开关"组件：

• 你可以把这个开关放在客厅、卧室、厨房。
• 每个开关都是独立的：你按客厅的开关，不会影响到卧室的灯。
• 但它们都是同一个组件，你只需要设计一次"开关长什么样"，就可以到处使用。

新名词解释：

• 组件 (Component)：页面里的"积木块"，可以单独复用。
• 封装：组件内部的状态不影响别人。
• 复用：同一个组件可以用很多次。

关键点：组件化让页面像搭积木一样搭出来。

---

5. 第五阶段：页面切换体验（MPA vs SPA）

用户不再想要"每点一次就刷新整页"的体验。 于是出现了单页应用 (SPA)：整个网站只加载一次，之后只是切换内容。

与之对应的是多页应用 (MPA)：每点一次都会重新加载整个页面。

这里的一个新词：路由 (Routing)。 简单理解：就是"从 A 页面切到 B 页面"的规则和过程。

再补两个新词（非常重要）：

• 前端路由：页面切换主要由浏览器里的 JavaScript 控制（常见于 SPA）。
• 后端路由：页面切换主要由服务器决定"返回哪个页面"（常见于 MPA）。

想象一下你在看一本书：

• MPA（多页应用）：就像翻书。每翻一页，你都要把旧书合上、去书架上拿一本新书。慢，而且你之前在书上做的笔记（比如折页）都会消失。
• SPA（单页应用）：就像在同一页纸上换内容。你只需要擦掉旧内容、写上新内容，纸还是那张纸。快，而且你做的笔记一直都在。

5.1 MPA 是什么？（多页应用）

MPA 的直觉很像"翻书"：

• 点"商品页" -> 浏览器向服务器要一个新的页面（新的 HTML）
• 旧页面被替换掉 -> 原来的输入、滚动位置、临时数据往往会消失

想象一下你在逛商场：

• 每进一家店（点一个链接），你都要走出商场、重新排队进门（整页刷新）。
• 你在上一家店试过的衣服（输入的内容）、拿过的购物车，全部清空。

优点（为什么很多网站仍在用）：

• 结构简单：服务器负责"出页面"，浏览器负责"展示"
• SEO 友好：搜索引擎更容易直接看到页面内容
• 首屏容易快：因为服务器直接给了 HTML

缺点：

• 体验偏"跳"：整页刷新会白一下、加载一下
• 复杂交互会变难：页面之间共享状态不方便

5.2 SPA 是什么？（单页应用）

SPA 更像"同一本书里换章节"：

• 第一次打开：加载一个"外壳页面"（HTML + CSS + JS）
• 之后切换页面：通常只换内容区域，整页不刷新

想象一下你在用手机的 App：

• 打开微信（第一次加载），之后你刷朋友圈、看聊天、进公众号，页面不会重新加载，只是内容在切换。
• 你输入了一半的消息、看到的滚动位置，切换后再回来还在。

优点：

• 体验丝滑：页面切换快
• 状态好管理：同一个页面里，数据更容易共享（登录态、购物车等）

缺点（也要知道）：

• 首次加载可能更慢：需要先下载一堆 JS
• SEO 要额外处理：通常需要 SSR/SSG 方案配合（后面第 7 阶段会讲）

5.3 交互演示：状态会不会丢？

下面这个小实验更直观：输入一段文字，然后切换页面再回来，看看有没有被清空。

想象一下你正在填写一张申请表：

• MPA（翻书模式）：你填到一半，去另一页查资料，回来发现表格被清空了，要重新填。
• SPA（同一页模式）：你填到一半，去另一页查资料，回来发现表格还在，继续填就行。

关键点：从"整页刷新"到"局部更新"，带来的不仅是速度，更是"状态能不能保留"的体验差异。

---

6. 第六阶段：工程化（从"手工作坊"到"现代化工厂"）

前端项目越来越大，不能再靠手动引入脚本文件。 于是有了打包工具（Webpack/Vite）：把多个文件和依赖打成一个或多个"优化后的包"。

想象一下你在整理行李：

• 以前（手动引入）：你要出门，把衣服、裤子、袜子一件一件拿在手里，容易丢、容易乱。
• 现在（工程化打包）：你把所有东西打包进一个行李箱，拉着就走，整齐又方便。

依赖就是你用到的第三方库，比如图表库、编辑器。

想象一下你在做饭：

• 你要做蛋糕，需要面粉、鸡蛋、糖（依赖）。
• 你不需要自己种小麦、养鸡（自己写所有代码），而是去超市买现成的（使用第三方库）。
• 工程化就是"超市购物清单"，帮你自动把所有需要的食材买齐、分类放好。

这里的几个新词：

• 工程化：用工具和规范把项目"像工程一样"管理（目录结构、构建、发布、代码规范等）。
• Bundle（包）：打包后的产物文件。
• Tree Shaking：把"没用到的代码"从包里摇掉，体积更小。

关键点：工程化让多人协作的大项目变得可控。

---

7. 第七阶段：渲染方式（CSR / SSR / SSG）

为了更快的首屏、更好的搜索排名，渲染方式也在进化。

想象一下你在餐厅吃饭，有三种服务模式：

• CSR（客户端渲染）：服务员给你一个半成品食材包（JS 文件），你自己在桌上做饭。等菜时间长（要下载 JS），但做完后你可以随时"热更新"（交互流畅）。

• SSR（服务端渲染）：服务员在厨房做好菜（服务器渲染 HTML），直接端给你。上菜快（首屏快），但你想加辣（交互），还得等厨师（服务器响应）。

• SSG（静态生成）：餐厅提前把所有菜做好，放在保温柜里。你来点餐，立刻就能吃（最快）。但菜单是固定的（静态内容），不能临时加菜。

• 首屏：用户打开网站时，最先看到的那一屏内容。

• SEO：Search Engine Optimization，搜索引擎优化。让页面更容易被搜索到。

• TTFB：Time To First Byte，浏览器收到"第一口数据"的时间（越小越快）。

• TTI：Time To Interactive，页面变得"可以点、可以用"的时间。

关键点：不同渲染策略适配不同业务场景。

---

8. 小结与学习建议

前端技术的进化，本质上是在解决两个问题：

1. 效率：从 手动操作 DOM -> 数据驱动 (MVVM)。
2. 规模：从 巨型面条代码 -> 组件化 + 工程化。

MVVM 是什么？ 简单理解：Model（数据）变了，View（界面）自动变。

现在你可以把前端理解成三件事：

1. 写页面：HTML + CSS（结构与样式）
2. 让页面动起来：JavaScript（交互与状态）
3. 把复杂项目做好：组件化 + 工程化（协作与质量）

如果你刚开始学，建议按这个顺序：

• 先把 HTML/CSS 写熟（布局、响应式）
• 再学 JavaScript 的基础（变量、函数、事件）
• 最后上手一个框架（Vue/React），理解"状态驱动 UI"

---

9. 名词速查表 (Glossary)

名词	全称	解释
HTML	HyperText Markup Language	超文本标记语言。网页的骨架，定义内容和结构。
CSS	Cascading Style Sheets	层叠样式表。网页的皮肤，定义颜色、布局、动画。
JS	JavaScript	网页的肌肉，负责交互和逻辑。
DOM	Document Object Model	文档对象模型。浏览器内部表示页面结构的树形对象。
jQuery	-	早期流行的 JS 库，简化了 DOM 操作。
Vue/React	-	现代前端框架，采用数据驱动和组件化开发。
State	-	状态。组件或应用的数据，状态变化驱动 UI 更新。
组件	Component	可复用的 UI 单元，如按钮、卡片、导航栏。
MPA	Multi-Page Application	多页应用。每次跳转都重新加载整个页面。
SPA	Single-Page Application	单页应用。只加载一次，后续切换不刷新页面。
路由	Routing	管理页面之间切换的规则和过程。
CSR	Client-Side Rendering	客户端渲染。浏览器下载 JS 后执行生成页面。
SSR	Server-Side Rendering	服务端渲染。服务器生成 HTML 后发给浏览器。
SSG	Static Site Generation	静态站点生成。构建时预渲染页面为静态 HTML。
Bundle	-	包。打包工具将多个文件合并后的产物。
Tree Shaking	-	摇树优化。自动移除未使用的代码，减小包体积。
H5	HTML5	通常指手机网页或基于 HTML5 的移动页面。
WebView	-	内嵌网页视图。App 中用于显示网页内容的组件。
跨端	Cross-Platform	一套代码运行在多个平台（iOS、Android、Web 等）。
原生	Native	使用平台官方语言和 API 开发的应用。
MVVM	Model-View-ViewModel	一种架构模式，实现数据（Model）和视图（View）的自动同步。
SEO	Search Engine Optimization	搜索引擎优化，提高网页在搜索结果中的排名。
TTFB	Time To First Byte	首字节时间，从请求到收到第一个字节数据的耗时。
TTI	Time To Interactive	可交互时间，页面变为完全可交互状态所需的时间。