Files
test-repo/docs/zh-cn/appendix/frontend-evolution.md
T
sanbuphy e8bba6f7c0 feat(docs): add performance overview demo component and update content structure
- Create PerformanceOverviewDemo.vue with interactive performance dimension visualization
- Update config.mjs to support new component registration
- Add new frontend evolution components to theme/index.js
- Consolidate stage-0 intro pages into index.md across all locales
- Enhance LLM intro documentation with tokenization details
2026-02-05 01:33:28 +08:00

425 lines
23 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 前端开发入门:从"贴海报"到"搭乐高" (Interactive Intro)
> 💡 **学习指南**:本章节无需编程基础,通过交互式演示带你回顾前端开发的 20 年变迁。我们将从最基础的 HTML 讲起,一直到现代的 Vue/React 组件化开发。
先把几个最常见的新名词说清楚(后面会反复出现):
- **HTML**:网页的"骨架",负责内容和结构(标题、段落、图片、按钮)。
- **CSS**:网页的"皮肤",负责样式(颜色、大小、布局、动画)。
- **JavaScript**:网页的"肌肉",负责交互与逻辑(点击、输入、请求数据)。
- **框架(Framework)**:一套成熟的开发方式和工具,让你更高效地做复杂页面(比如 Vue/React)。
<FrontendEvolutionDemo />
## 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)。
<BigFrontendScopeDemo />
**关键点**:大前端不是一个"新岗位名字",而是一种范围:把体验交付到更多平台。
---
## 1. 第一阶段:静态网页与切图 (2000s-)
早期网页开发像做报纸:设计师把 UI 设计切成很多小图,前端把这些图片拼成页面。
这就叫**切图**。
这里的几个新词:
- **静态网页**:页面内容基本固定,打开就是一份 HTML 文件(不像现在很多页面是"数据驱动、可交互"的)。
- **UI**User Interface,用户界面。也就是你看到的按钮、颜色、布局。
### 1.1 为什么会慢?
网页上的每一张小图,浏览器都要发一次**网络请求**。
请求越多,加载越慢。
想象一下你点外卖:
- 如果你一次性下单 10 道菜,餐厅可以一起做完送过来。
- 但如果你分 10 次下单,每次只点 1 道菜,骑手要跑 10 趟!
早期的网页就像"分 10 次下单",每张图片都要单独"下单"(发请求)。
<EvolutionSliceRequestDemo />
补充一个常见技巧:**雪碧图 (Sprite)**。
把很多小图合成一张大图,这样请求数会变少(但制作和维护更麻烦)。
**关键点**:早期网页慢,常见原因之一是"请求太多"。(图片、脚本、样式都会产生请求)
---
## 2. 第二阶段:移动端普及与响应式布局 (2010s)
手机和平板开始流行以后,网页必须适配不同屏幕。
这就需要**响应式布局**:同一套 HTML/CSS,自动根据屏幕宽度变换布局。
这里用到了**媒体查询 (Media Query)**
它是 CSS 里的"条件判断",比如"如果屏幕小于 640px,就用 1 列布局"。
想象一下你在不同房间看同一张照片:
- 在**大客厅**(电脑屏幕),照片可以摆大一些,旁边还能放其他装饰品。
- 在**小卧室**(手机屏幕),照片需要缩小,其他装饰品要收起来,否则会挤不下。
**响应式布局**就是"智能相框",它会自动根据房间大小调整展示方式。
<EvolutionResponsiveGridDemo />
**关键点**:响应式让网页"会变形",不再只适配电脑。
---
## 3. 第三阶段:从"手动搬砖"到"数据驱动" (jQuery -> Vue/React)
网页开始像 App 一样复杂之后,最麻烦的事变成了:**同一份数据变化,要改很多地方**。
举个最常见的例子:购物车数量从 1 变成 2。
- 右上角小红点要变
- 购物车页面的数量要变
- 结算按钮的价格要变
下面这个可视化演示,专门用来解释:**什么是 jQuery(以及它为什么会累)**。
想象一下你在餐厅当服务员:
- **jQuery 时代**:客人点了一份牛排,你要亲自跑厨房告诉厨师、跑吧台拿饮料、跑收银台记账。客人加菜,你又要重新跑一遍。**你成了"跑腿王",累得半死**。
- **Vue/React 时代**:你只需在单子上写好"客人要什么"(数据),厨房、吧台、收银台会自动看单子做事。客人加菜,你只需改单子,其他地方**自动更新**。**你成了"指挥家",轻松优雅**。
<EvolutionJQueryVsStateDemo />
### 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`,界面自动变。
<ImperativeVsDeclarativeDemo />
**关键点**:从 jQuery 到 Vue/React,变化的核心不是"语法",而是**思维方式**:从"我去改页面"变成"我只改数据"。
### 3.5 Vue 和 React 怎么选?先把差异理解清楚
很多初学者会纠结:"我到底学 Vue 还是 React"
先别急着站队。你先把它们的"共同点"和"差异点"理解清楚,就不会被带节奏了。
**共同点(它们都在解决同一件事)**
- 都是为了解决:页面复杂时,如何可靠地管理状态、更新界面
- 都强调:组件化(把页面拆成积木)
**差异点(你会在写代码时真实感受到)**
- **写 UI 的方式**Vue 常用 TemplateReact 常用 JSX
- **状态变化时怎么更新**:Vue 更偏"依赖追踪"React 更偏"重新渲染组件函数"
这里的几个新词(像课件一样解释清楚):
- **Template**Vue 常见写法,用类似 HTML 的语法来写界面。
- **JSX**React 常见写法,用"像写 JS 一样"的方式写界面结构。
- **Hook**React 的一套函数式能力(比如 `useState`),用来保存状态、处理副作用。
- **SFC**Single File ComponentVue 常见的单文件组件(一个 `.vue` 文件里写模板/逻辑/样式)。
<VueReactComparisonDemo />
**关键点**:别死记名词。你只要记住一句话:它们都能做同样的产品,只是"写法和心智模型"不一样。
---
## 4. 第四阶段:组件化(像搭积木一样写页面)
解决了"怎么更新页面"的问题,接下来是"怎么组织代码"。
以前一个页面可能是一个超大的 HTML 文件,改一个按钮可能牵连全局。
### 4.1 "积木"是什么?
现代前端把页面拆成了**组件**。
一个按钮、一个导航栏、一个商品卡片,都是独立的积木。
想象一下你在搭乐高:
- 你不需要"从头开始雕刻每一块积木"(从头写 HTML/CSS)。
- 你只需要"按说明书把积木拼在一起"(把组件组合起来)。
- 每个积木都是**独立的**,你可以在不同的套装里**重复使用**。
### 4.2 为什么组件能复用?
定义好一个"商品卡片"组件后,你可以由它生成 100 个实例。每个实例都有自己独立的状态(比如点赞状态),互不干扰。
想象一下你有一个"万能开关"组件:
- 你可以把这个开关放在客厅、卧室、厨房。
- 每个开关都是**独立的**:你按客厅的开关,不会影响到卧室的灯。
- 但它们都是**同一个组件**,你只需要设计一次"开关长什么样",就可以到处使用。
<ComponentReusabilityDemo />
**新名词解释**
- **组件 (Component)**:页面里的"积木块",可以单独复用。
- **封装**:组件内部的状态不影响别人。
- **复用**:同一个组件可以用很多次。
**关键点**:组件化让页面像搭积木一样搭出来。
---
## 5. 第五阶段:页面切换体验(MPA vs SPA)
用户不再想要"每点一次就刷新整页"的体验。
于是出现了**单页应用 (SPA)**:整个网站只加载一次,之后只是切换内容。
与之对应的是**多页应用 (MPA)**:每点一次都会重新加载整个页面。
这里的一个新词:**路由 (Routing)**。
简单理解:就是"从 A 页面切到 B 页面"的规则和过程。
再补两个新词(非常重要):
- **前端路由**:页面切换主要由浏览器里的 JavaScript 控制(常见于 SPA)。
- **后端路由**:页面切换主要由服务器决定"返回哪个页面"(常见于 MPA)。
想象一下你在看一本书:
- **MPA(多页应用)**:就像**翻书**。每翻一页,你都要把旧书合上、去书架上拿一本新书。慢,而且你之前在书上做的笔记(比如折页)都会消失。
- **SPA(单页应用)**:就像**在同一页纸上换内容**。你只需要擦掉旧内容、写上新内容,**纸还是那张纸**。快,而且你做的笔记一直都在。
<RoutingModeDemo />
### 5.1 MPA 是什么?(多页应用)
MPA 的直觉很像"翻书"
- 点"商品页" -> 浏览器向服务器要一个新的页面(新的 HTML)
- 旧页面被替换掉 -> 原来的输入、滚动位置、临时数据往往会消失
想象一下你在逛商场:
- 每进一家店(点一个链接),你都要**走出商场、重新排队进门**(整页刷新)。
- 你在上一家店试过的衣服(输入的内容)、拿过的购物车,**全部清空**。
**优点(为什么很多网站仍在用)**
- 结构简单:服务器负责"出页面",浏览器负责"展示"
- SEO 友好:搜索引擎更容易直接看到页面内容
- 首屏容易快:因为服务器直接给了 HTML
**缺点**
- 体验偏"跳":整页刷新会白一下、加载一下
- 复杂交互会变难:页面之间共享状态不方便
### 5.2 SPA 是什么?(单页应用)
SPA 更像"同一本书里换章节":
- 第一次打开:加载一个"外壳页面"HTML + CSS + JS
- 之后切换页面:通常只换内容区域,整页不刷新
想象一下你在用手机的 App
- 打开微信(第一次加载),之后你刷朋友圈、看聊天、进公众号,**页面不会重新加载**,只是内容在切换。
- 你输入了一半的消息、看到的滚动位置,**切换后再回来还在**。
**优点**
- 体验丝滑:页面切换快
- 状态好管理:同一个页面里,数据更容易共享(登录态、购物车等)
**缺点(也要知道)**
- 首次加载可能更慢:需要先下载一堆 JS
- SEO 要额外处理:通常需要 SSR/SSG 方案配合(后面第 7 阶段会讲)
### 5.3 交互演示:状态会不会丢?
下面这个小实验更直观:输入一段文字,然后切换页面再回来,看看有没有被清空。
想象一下你正在填写一张申请表:
- **MPA(翻书模式)**:你填到一半,去另一页查资料,回来发现**表格被清空了**,要重新填。
- **SPA(同一页模式)**:你填到一半,去另一页查资料,回来发现**表格还在**,继续填就行。
<SpaStatePreservationDemo />
**关键点**:从"整页刷新"到"局部更新",带来的不仅是速度,更是"状态能不能保留"的体验差异。
---
## 6. 第六阶段:工程化(从"手工作坊"到"现代化工厂"
前端项目越来越大,不能再靠手动引入脚本文件。
于是有了**打包工具**(Webpack/Vite):把多个文件和依赖打成一个或多个"优化后的包"。
想象一下你在整理行李:
- **以前(手动引入)**:你要出门,把衣服、裤子、袜子一件一件拿在手里,容易丢、容易乱。
- **现在(工程化打包)**:你把所有东西**打包进一个行李箱**,拉着就走,整齐又方便。
**依赖**就是你用到的第三方库,比如图表库、编辑器。
想象一下你在做饭:
- 你要做蛋糕,需要面粉、鸡蛋、糖(**依赖**)。
- 你不需要自己种小麦、养鸡(**自己写所有代码**),而是去超市买现成的(**使用第三方库**)。
- **工程化**就是"超市购物清单",帮你自动把所有需要的食材买齐、分类放好。
<BundlerSizeDemo />
这里的几个新词:
- **工程化**:用工具和规范把项目"像工程一样"管理(目录结构、构建、发布、代码规范等)。
- **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,页面变得"可以点、可以用"的时间。
<RenderingStrategyDemo />
**关键点**:不同渲染策略适配不同业务场景。
---
## 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 | 可交互时间,页面变为完全可交互状态所需的时间。 |