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

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

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

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

🚀前端开发演进时间线从"贴海报"到"搭乐高"的 20 年变迁

🖼️

2000s静态网页时代

网页像海报，只能看不能动

📱

2010s 初响应式布局时代

一套代码适配手机和电脑

🔧

2010s 中jQuery 时代

简化 DOM 操作，但还是手动搬砖

⚛️

2010s 末现代框架时代

数据驱动，组件化开发

🏭

2020s工程化时代

自动化、规范化、规模化

👆点击任意时代，查看详细信息

🎯

核心思想： 前端技术的演进，本质是为了解决两个问题： 提升开发效率（从手动到自动化）和 支撑更复杂的应用（从简单页面到桌面级应用）。

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）。

运行环境

浏览器 (Chrome/Safari/Edge)

主要技术

HTML + CSS + JavaScript / Vue / React

发布方式

部署到服务器/静态托管，用户刷新即可更新

哪些能力是“共通的”？

HTTP/网络性能优化工程化与构建组件化状态管理调试与排错用户体验

大前端的核心不是“会更多框架”，而是：用同一套工程能力，把体验交付到不同平台。

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

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

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

这里的几个新词：

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

1.1 为什么会慢？

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

想象一下你点外卖：

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

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

📦🚚🏠

小明搬家记

小明要搬 6 箱书到新房子。有两种搬家方式：
A 方案：一箱一箱搬（切图模式） vs B 方案：一次性打包运走（雪碧图模式）
看看哪种更省时间？

🛵

A 方案：一箱一趟

小面包车，一次拉一箱

需要 6 趟运输

🚚

B 方案：打包一车拉

大卡车，6箱一次运走

只需 1 趟运输

🏠

旧家

剩余箱子: 6

🏡

新家

已送达: 0/6

运输趟数

0 趟

总耗时

0.0 秒

效率评分

一般

💡 核心原理

切图模式（分开请求）：就像一箱一箱搬，每次只拉一件货。浏览器要发起 6 次 HTTP 请求，每次都要建立连接、传输数据，效率低、耗时长。

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

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

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

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

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

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

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

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

👗✨🚪

小美的魔法衣柜

小美有一件神奇的魔法衣柜！不管你把它放在大房间还是小房间，
里面的衣服都会自动叠好、排好，完美适应空间大小！

🚪 拖动把手，把衣柜放进不同房间：小房间（手机）

🏠小大🏰

当前衣柜宽度：375px | 可以放下 1 件衣服

🚪小美的魔法衣柜🪄

🪝

👗

连衣裙

叠好了!

🪝

👔

衬衫

叠好了!

🪝

👖

牛仔裤

叠好了!

🪝

🧥

大衣

叠好了!

🪝

👘

和服

叠好了!

🪝

🥻

纱丽

叠好了!

🔮 魔法原理揭秘

📱

小房间（手机）

衣柜只有 320px 宽，衣服会自动叠起来，1列排开

➡️

📲

中房间（平板）

衣柜有 768px 宽，衣服舒展开，2列排开

➡️

💻

大房间（电脑）

衣柜有 1200px 宽，衣服完全展开，3列排开

💻 魔法咒语（CSS代码）CSS

/* 默认：小房间，衣服叠成1列 */
.closet {
  display: grid;
  gap: 10px;
  grid-template-columns: 1fr;  /* 1列 */
}

/* 中房间：衣服排成2列 */
@media (min-width: 640px) {
  .closet {
    grid-template-columns: repeat(2, 1fr);  /* 2列 */
  }
}

/* 大房间：衣服排成3列 */
@media (min-width: 1024px) {
  .closet {
    grid-template-columns: repeat(3, 1fr);  /* 3列 */
  }
}

🎯

关键 takeaway： 响应式布局就像小美的魔法衣柜，同一套衣服（内容），会根据房间大小（屏幕宽度）自动调整排列方式！这就是 CSS 媒体查询（Media Query）的魔法！

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

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

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

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

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

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

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

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

👨‍🍳📒🤖

老张的餐厅账本

老张开了家餐厅，每天要点菜、做菜、算账。有两种记账方式：
传统方式：老张手工记（jQuery 模式） vs 智能方式：请个管家（Vue/React 模式）
看看哪种更轻松？

👨‍🍳老张手工记账

翻开账本，找到对应菜品

手动计算价格，写到本子上

再算一遍总数，防止算错

把完成的菜标记一下

📒今日账本手工计算中...

宫保鸡丁¥38

○

鱼香肉丝¥32

○

麻婆豆腐¥18

○

糖醋排骨¥48

○

菜品数量：0/4 份

今日营收：¥0

💡 两种方式对比

工作方式

手动改每一处

改数据，界面自动变

容易出错

容易漏改某处

自动同步，不易错

适合场景

简单页面

复杂交互应用

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 / Imperative

"Tell me HOW"

Progress:

Normal

Vue / Declarative

"Tell me WHAT"

Progress:

Normal

关键点：从 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 文件里写模板/逻辑/样式）。

Vue

count: 1

典型写法（示意）

<template>
  <button @click="count++">+1</button>
  <div>count: {{ count }}</div>
</template>

<script setup>
import { ref } from 'vue'
const count = ref(1)
</script>

React

count: 1

典型写法（示意）

function App() {
  const [count, setCount] = useState(1)
  return (
    <>
      <button onClick={() => setCount(count + 1)}>+1</button>
      <div>count: {count}</div>
    </>
  )
}

点击 “+1” 时发生了什么？

1你写 UI 的方式：Vue 常用 Template；React 常用 JSX

2点击按钮触发事件处理函数

3count 更新后，界面显示跟着变

说明：这是为了建立心智模型的简化示意，真实框架内部更复杂。

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

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

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

4.1 "积木"是什么？

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

想象一下你在搭乐高：

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

4.2 为什么组件能复用？

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

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

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

Component Library

App Workspace

Click buttons above to add components.
Notice how each one works independently!

新名词解释：

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

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

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

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

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

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

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

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

想象一下你在看一本书：

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

📖📄✨

小明看书记

小明喜欢看书。有两种看书方式：
MPA 方式：像翻书，每翻一页都要换一本书 SPA 方式：像换纸，在同一本书里换内容

📚

MPA 多页应用

像翻书：每次都换一本

每点一次链接，浏览器向服务器要新页面

📄

SPA 单页应用

像换纸：同一本书换内容

只加载一次，后续只切换内容

当前模式：SPA 单页应用

📚

书架（服务器）

🏠

🛍️

🛒

👤

无需传输

📖

阅读区（浏览器）

🏠

首页

欢迎来到首页！这是网站的入口。

✏️ 状态保留测试：

⚡内容已经下载好了，切换不需要再拿（前端路由）

📊 MPA vs SPA 对比

比喻

翻书：每翻一页换一本书

换纸：同一本书里换内容

页面切换

每次都重新加载整个页面

只加载一次，后续只切换内容

速度体验

每次都有"白屏-加载"的过程

页面切换流畅，无白屏

状态保留

切换页面后，输入的内容会丢失

切换页面后，输入的内容还在

搜索引擎

容易被搜索到（SEO 友好）

需要额外处理才能被搜索到

首屏加载

服务器直接给 HTML，首屏快

需要先下载 JS，首屏可能慢

适合场景

博客、新闻、企业官网

淘宝、网易云音乐、后台系统

🎯

核心差异：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（同一页模式）：你填到一半，去另一页查资料，回来发现表格还在，继续填就行。

当前页面：首页

备注（模拟表单输入）：

提示：切到别的页面再回来，看看这段文字还在不在。

购物车数量（模拟状态）： 1

你现在看到的现象

MPA：切换页面时像刷新，输入和状态经常会丢

背后的原因（一句话）

因为浏览器加载了“新的页面”，旧页面的内存状态会被清掉

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

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

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

想象一下你在整理行李：

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

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

想象一下你在做饭：

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

图表库 (+180 KB) 富文本编辑器 (+220 KB) 国际化 (+60 KB) 埋点分析 (+80 KB)

开启 Tree Shaking (移除未使用代码)

Bundle Size

295 KB

Build Time

3 s

这里的几个新词：

工程化：用工具和规范把项目"像工程一样"管理（目录结构、构建、发布、代码规范等）。
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，页面变得"可以点、可以用"的时间。

🍽️👨‍🍳⚡

小美的餐厅

小美开了家餐厅，有三种上菜方式：
CSR（客户端渲染）：给你半成品食材包，你自己做
SSR（服务端渲染）：厨房做好菜端给你
SSG（静态生成）：提前做好所有菜放保温柜

🧑‍🦰

用户（浏览器）

🍲 提前做好的菜

保温中，直接吃

直接取

👨‍🍳

服务器（保温柜）

🗄️

保温柜

所有菜都提前做好了

首屏速度

最快

交互体验

较流畅

SEO 友好度

好

📊 三种渲染方式详细对比

比喻

给半成品食材包，自己做

厨房做好菜端给你

提前做好放保温柜

首屏速度

慢（要等 JS）

快（直接给 HTML）

最快（直接给 HTML）

交互体验

流畅（已在浏览器）

较流畅（交互仍需 JS）

SEO 友好度

差（搜不到内容）

好（完整 HTML）

服务器压力

小（只传 JS）

大（每次都渲染）

最小（预渲染好）

适合场景

后台系统、工具应用

新闻网站、电商首页

博客、文档站

代表框架

React SPA、Vue SPA

Next.js SSR、Nuxt SSR

Next.js SSG、Nuxt SSG

🎯

如何选择？
CSR：适合需要复杂交互、不关心 SEO 的应用（如后台管理系统）
SSR：适合需要首屏快、SEO 好的动态内容网站（如新闻、电商）
SSG：适合内容固定的静态网站（如博客、文档站）
现代方案：混合渲染，首页用 SSG/SSR，后续页面用 CSR，兼顾速度和体验。

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

8. 小结与学习建议

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

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

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

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

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

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

先把 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	可交互时间，页面变为完全可交互状态所需的时间。

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

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

一个生活的比喻 ​

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

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

1.1 为什么会慢？ ​

小明搬家记

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

小美的魔法衣柜

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

老张的餐厅账本

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

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

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

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

"Tell me HOW"

"Tell me WHAT"

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

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

4.1 "积木"是什么？ ​

4.2 为什么组件能复用？ ​

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

小明看书记

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

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

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

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

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

小美的餐厅

8. 小结与学习建议 ​

9. 名词速查表 (Glossary) ​

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

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

一个生活的比喻

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

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

1.1 为什么会慢？

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

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

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

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

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

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

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

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

4.1 "积木"是什么？

4.2 为什么组件能复用？

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

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

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

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

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

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

8. 小结与学习建议

9. 名词速查表 (Glossary)