feat(appendix): 重构工程实践章节，添加交互式演示组件

## 新增组件 (14个)
- CodeSmellDemo.vue: 代码异味识别演示
- DecisionMatrixDemo.vue: 决策矩阵工具
- DesignPatternCatalogDemo.vue: 设计模式目录
- DocStructureDemo.vue: 文档结构示例
- LicenseComparisonDemo.vue: 开源许可证对比
- OpenSourceWorkflowDemo.vue: 开源协作流程
- PatternPlaygroundDemo.vue: 设计模式演练场
- RefactoringDemo.vue: 重构实战演示
- SecurityChecklistDemo.vue: 安全检查清单
- TDDCycleDemo.vue: TDD 循环演示
- TechRadarDemo.vue: 技术雷达图
- TechWritingPracticeDemo.vue: 技术写作实践
- TestPyramidDemo.vue: 测试金字塔
- WebSecurityDemo.vue: Web 安全演示

## 文档更新 (7篇)
- code-quality-refactoring.md: 代码质量与重构
- design-patterns.md: 设计模式
- open-source-collaboration.md: 开源协作
- security-thinking.md: 安全思维
- technical-writing.md: 技术写作
- technology-selection.md: 技术选型
- testing-strategies.md: 测试策略

## 其他变更
- 将 browser-as-os.md 内容合并到 computer-networks.md
- 更新 .gitignore 和 theme/index.js

docs/zh-cn/appendix/1-computer-fundamentals/computer-networks.md

@@ -1,224 +1,544 @@
-# 计算机网络：从输入网址到返回结果的过程
+# 浏览器是一个操作系统
 
-::: tip 🎯 核心问题
-**当你舒服地靠在沙发上，在手机浏览器里输入 `www.google.com` 并按下回车，为什么几百毫秒后，搜索结果就能准确无误地出现在你的屏幕上？**
+::: tip 前言
+你每天都在用浏览器——看视频、刷新闻、在线办公。但你有没有想过：**当你在地址栏输入一个网址并按下回车，背后发生了什么？**
 
-在上一章中，我们知道了数据是如何被编码成 0 和 1 并通过海底光缆传输的。但这还不够。互联网上的服务器浩如烟海，你的手机是怎么在茫茫机海中精准找到 Google 的服务器，商量好暗号，并成功把页面要回来的呢？
+这篇文章会用**"网购"**的生活化比喻，配合**真实的技术过程**，带你一步步理解浏览器如何将一行网址变成丰富多彩的页面。
 
-这个看似无比简单的"敲回车"动作，背后其实隐藏着一个精密到令人震撼的跨国"快递接力系统"。本章，我们不讲枯燥的八股文概念，而是顺着**"填写购物单 -> 查地址簿 -> 打电话确认 -> 寄包裹 -> 自己拆解组装"**这条主线，带你零基础看清网络世界的全貌。
+读完这篇，你就能：
+- 理解从输入网址到显示页面的完整流程
+- 掌握 URL、DNS、TCP、HTTP 等核心概念
+- 了解浏览器如何渲染页面
+- 知道静态网站和动态网站的区别
+
+**无需编程基础**，只需要你平时网购的经验即可。
+:::
+
+**这篇文章会带你学什么？**
+
+| 章节 | 内容 | 核心概念 |
+|-----|------|---------|
+| **第 1 章** | URL 解析 | 网址的结构和作用 |
+| **第 2 章** | DNS 查询 | 域名如何转换成 IP 地址 |
+| **第 3 章** | TCP 握手 | 如何建立可靠的连接 |
+| **第 4 章** | HTTP 通信 | 浏览器和服务器如何对话 |
+| **第 5 章** | 浏览器渲染 | 代码如何变成画面 |
+| **第 6 章** | 静态 vs 动态 | 网页内容的生成方式 |
+
+---
+
+## 0. 引言：当你按下回车键的那一刻
+
+::: tip 🤔 核心问题
+**当你在浏览器输入网址并按下回车，后台发生了什么？** 为什么有的网页打开很快，有的很慢？为什么有时候会出现"找不到服务器"的错误？
+:::
+
+### 生活比喻：一次网购之旅
+
+想象你正在进行一次**网购**。整个过程可以分为 5 个步骤：
+
+<div style="display: flex; gap: 20px; margin: 20px 0;">
+<div style="flex: 1; padding: 16px; background: var(--vp-c-bg-alt); border-radius: 12px;">
+
+**🛒 第 1 步：填写订单**
+选好商品，确认收货地址
+
+</div>
+<div style="flex: 1; padding: 16px; background: var(--vp-c-bg-alt); border-radius: 12px;">
+
+**🗺️ 第 2 步：查找仓库**
+系统找到具体的发货仓库
+
+</div>
+<div style="flex: 1; padding: 16px; background: var(--vp-c-bg-alt); border-radius: 12px;">
+
+**📞 第 3 步：建立通道**
+确认仓库营业且能发货
+
+</div>
+</div>
+
+<div style="display: flex; gap: 20px; margin: 20px 0;">
+<div style="flex: 1; padding: 16px; background: var(--vp-c-bg-alt); border-radius: 12px;">
+
+**🚚 第 4 步：仓库发货**
+快递员把包裹送上门
+
+</div>
+<div style="flex: 1; padding: 16px; background: var(--vp-c-bg-alt); border-radius: 12px;">
+
+**🎁 第 5 步：拆箱体验**
+打开包裹，看到心仪的商品
+
+</div>
+</div>
+
+**访问网页的过程和网购惊人地相似！**
+
+当你在浏览器输入 `google.com` 并按下回车，你就是那个"买家"，浏览器通过一系列操作，最终把远方服务器上的"商品"（网页内容）送到你的屏幕上。
+
+<UrlToBrowserQuickStart />
+
+::: info 💡 核心启示
+理解浏览器工作原理的关键是：**把复杂的技术过程映射到熟悉的生活场景**。网购的 5 个步骤完美对应了浏览器访问网页的 5 个技术阶段。
 :::
 
 ---
 
-## 第一步：填写购物单 (URL 解析)
+## 1. 第一步：填写"订单" —— URL 解析
 
-**目标**：把人类能看懂的网址，翻译成浏览器能理解的结构化信息。
+::: tip 🤔 核心问题
+**为什么网址要写成这样？** `https://www.example.com:8080/path/page.html?id=123#section` — 这串字符到底有什么含义？
+:::
 
-当你在地址栏中输入 `https://www.google.com/search` 时，浏览器第一步必须先把你输入的这段"人类文字"，仔细拆解成它能看懂的标准化字段。
+### 生活比喻：填写购物单
 
-这就像是你准备去商店买东西，首先要在**购物单**上写清楚：用什么交通工具去、去哪家店、拿什么货。
+假设你只在订单上写"买鞋子"，仓库肯定不知道发哪双。你需要写清楚：
+
+- **店铺类型**（官方旗舰店/普通店）
+- **店铺名称**（Nike 官方店）
+- **商品位置**（男鞋区/跑鞋系列）
+- **具体型号**（Air Max 90）
+- **备注信息**（我要红色的）
+
+### 真实过程：浏览器解析 URL
+
+**URL（Uniform Resource Locator，统一资源定位符）**就是浏览器世界的"商品定位码"。当你在地址栏输入 `https://www.example.com:8080/path/page.html?id=123#section`，浏览器会立即拆解它：
+
+| URL 部分                   | 示例值               | 网购类比                                           | 技术作用                                                                 |
+| -------------------------- | -------------------- | -------------------------------------------------- | ------------------------------------------------------------------------ |
+| **协议** `https://`        | 安全超文本传输协议   | **物流方式**：保密配送（HTTPS）vs 普通配送（HTTP） | 决定使用什么规则通信。`http` 是普通传输，`https` 是加密传输              |
+| **域名** `www.example.com` | 服务器的人类可读名字 | **店铺名称**：京东超市                             | 告诉浏览器要找哪台服务器。域名是为了让人记住，最终要转换成 IP 地址       |
+| **端口** `:8080`           | 服务器的具体"门牌号" | **柜台编号**：3号柜台（默认不写）                  | 服务器上可能有多个服务，端口指定访问哪一个。HTTP 默认 80，HTTPS 默认 443 |
+| **路径** `/path/page.html` | 服务器上的文件位置   | **货架位置**：日用品区/第三排                      | 指定服务器上的具体资源位置                                               |
+| **查询参数** `?id=123`     | 附加信息             | **订单备注**：红色、XL码                           | 传递给服务器的额外数据，如搜索关键词、页码等                             |
+| **锚点** `#section`        | 页面内的位置         | **说明书页码**：翻到第5页                          | 页面加载后自动滚动到指定位置，不发送给服务器                             |
 
 <UrlParserDemo />
 
-**💡 核心原理解析：URL是怎么分工的？**
-
-- **交通方式（Protocol/协议）**：比如开头写的 `https://`。这代表你要求坐安全级别最高的"运钞车"（加密通信）去。如果是老式的 `http://`，就相当于坐敞篷车，你一路上买什么都会被别人看光。
-- **店铺名（Host/主机名）**：比如 `www.google.com`。这就是你要去哪家店（也就是服务器的域名）。
-- **具体货架（Path/路径）**：比如后面的 `/search`。这代表进了店门之后，你要去哪个房间拿具体的哪份文件。
-
-**这一步完成了什么？** 浏览器现在知道了：我要用 HTTPS 协议，去 `www.google.com` 这个域名对应的服务器，获取 `/search` 路径下的内容。
-
-**但问题来了**：浏览器知道了域名，但网络世界只认数字 IP 地址。就像你知道"王府井大饭店"，但司机需要 GPS 坐标。下一步，我们需要把域名转换成 IP 地址。
+::: info 💡 关键理解
+URL 的存在是为了让**人类**能记住和输入。计算机最终需要的是 **IP 地址**（就像快递员最终需要的是具体的仓库地址，而不是"Nike 官方店"这个名字）。
+:::
 
 ---
 
-## 第二步：查地址簿 (DNS 解析)
+## 2. 第二步：查"地址簿" —— DNS 查询
 
-**上一步完成了**：浏览器拆解了 URL，知道了目标域名是 `www.google.com`。
+::: tip 🤔 核心问题
+**为什么浏览器能找到网站？** 你输入的是人类可读的域名（如 `baidu.com`），但计算机真正需要的是数字地址（IP）。这中间发生了什么？
+:::
 
-**这一步要实现**：把域名转换成 IP 地址，让浏览器知道服务器的精确位置。
+### 生活比喻：查仓库地址
 
-**目的**：网络世界的底层路由器（负责指路的交警）根本不懂英文，它们**只认数字**，也就是所谓的 **IP 地址（如 142.250.80.46）**。
+你下单写的是"Nike 官方店"，但物流系统不知道仓库在哪。它需要查地址簿：
+
+1. 先查**常用地址**（最近买过这家吗）→ 浏览器缓存
+2. 没有的话问**小区快递点**（他们知道大区域的分配）→ 本地 DNS 服务器
+3. 问**总部调度中心**（知道.com类店铺归谁管）→ 根域名服务器
+4. 问**品牌管理处**（最终找到 Nike 店铺的真实发货仓库）→ 权威域名服务器
+
+### 真实过程：DNS 分层查询
+
+**DNS（Domain Name System，域名系统）**是互联网的"分布式地址簿查询系统"。由于全球有数十亿个域名，采用分层架构来分散查询压力：
+
+```
+你（浏览器）
+    ↓ 问：google.com 的 IP 是多少？
+本地 DNS 服务器（你的网络运营商，如电信/联通）
+    ↓ 问：.com 归谁管？
+根域名服务器（全球13组根服务器，管理所有顶级域）
+    ↓ 告诉：去问 .com 的管理者
+顶级域服务器（Verisign 管理 .com）
+    ↓ 告诉：去问 google.com 的管理者
+权威域名服务器（Google 自己的 DNS 服务器）
+    ↓ 告诉：google.com 的 IP 是 142.250.80.46
+返回 IP 地址给浏览器
+```
+
+**查询类型说明：**
+
+- **递归查询（Recursive Query）**：浏览器只发一次请求，本地 DNS 负责层层查询后返回结果
+- **迭代查询（Iterative Query）**：每一层只告诉下一层去哪查，浏览器需要多次查询
+- **缓存机制**：查询结果会被缓存，下次直接返回，大大加速访问
 
 <DnsLookupDemo />
 
-**💡 核心原理解析：找"114查号台"**
+::: info 💡 为什么需要这么多层？
+想象一下如果全世界只有一个地址簿，几十亿人同时查，早就崩溃了。分层设计让每个层级只管理自己的"辖区"，既高效又可靠。
 
-既然必须用 IP 地址，浏览器就会走一个叫做 **DNS (Domain Name System)** 的打听流程：
-
-1. **翻自己的备忘录（本地缓存）**：浏览器会先翻翻自己的浏览历史，看看前几天是不是刚去过这家店，记没记过它的数字地址。如果记了，直接用。
-2. **打电话给查号台（递归查询）**：如果实在没见过，它就会向互联网的"总查号台"（通常由你的宽带运营商提供，比如联通、电信的 DNS 服务器）发请求："你好，请帮我查一下，google.com 对应的数字坐标是几？"
-3. **拿到坐标**：查号台通过逐级查询，最终把一个准确的 IP 地址（如 `142.250.80.46`）发回给你的手机。
-
-**这一步完成了什么？** 浏览器现在拿到了 Google 服务器的精确 IP 地址 `142.250.80.46`。
-
-**但问题来了**：有了 IP 地址就能直接发请求了吗？万一服务器宕机了呢？万一网线断了呢？如果直接发请求，对方没收到，就成了鸡同鸭讲。下一步，我们需要先确认双方能正常通信。
+这就是互联网设计的核心思想：**分布式系统**。
+:::
 
 ---
 
-## 第三步：打电话确认 (TCP 三次握手)
+## 3. 第三步：打电话确认 —— TCP 三次握手
 
-**上一步完成了**：浏览器通过 DNS 查询，拿到了服务器的 IP 地址 `142.250.80.46`。
+::: tip 🤔 核心问题
+**为什么需要"三次握手"？** 找到服务器地址后，为什么不能直接发送数据？为什么要先进行三次通信？
+:::
 
-**这一步要实现**：建立一条可靠的通信通道，确保双方都能收发数据。
+### 生活比喻：建立物流通道
 
-**目的**：在正式传输数据之前，必须先确认"对方在线"且"双方收发通道都正常"。这就像打电话前要先确认"喂，能听到吗？"
+假设物流车直接开到仓库，结果：
+
+- 仓库关门了 → 白跑一趟
+- 仓库爆仓不接单 → 无法发货
+- 找不到卸货口 → 无法对接
+
+**所以在真正发货之前，必须先建立可靠的运输通道**。
+
+### 真实过程：TCP 三次握手
+
+**TCP（Transmission Control Protocol，传输控制协议）**是确保数据可靠传输的规则。在传输商品（数据）前，必须通过"三次握手"建立连接：
+
+```
+客户端（你的电脑）              服务器（商家仓库）
+   |                                |
+   |--- SYN=1 --------------------->|  第1次：你好，我在家，准备收货！(SYN)
+   |                                |
+   |<-- SYN=1, ACK=1 ---------------|  第2次：收到！我也准备好发货了，你在家吗？(SYN-ACK)
+   |                                |
+   |--- ACK=1 --------------------->|  第3次：在的！请发货吧。(ACK)
+   |                                |
+   ===== 通道建立，开始发货 =====
+```
+
+**为什么是三次，不是两次？**
+
+- **第一次（SYN）**：客户端证明自己能发送
+- **第二次（SYN-ACK）**：服务器证明自己能接收和发送
+- **第三次（ACK）**：客户端证明自己能接收
+
+三次握手确保：**双方都能发、双方都能收** —— 四个条件都满足，才能可靠传输。
+
+**TCP 还负责：**
+
+- **数据分包**：大数据拆成小数据包传输
+- **顺序重组**：确保数据包按正确顺序组装
+- **错误重传**：丢包后自动重新发送
+- **流量控制**：根据网络状况调整发送速度
 
 <TcpHandshakeDemo />
 
-**💡 核心原理解析：为什么非得是"三"次？**
-
-不要被专业名词吓到，它完全可以在现实生活中还原。想象一下你给朋友打电话：
+> **HTTPS 的额外步骤**：如果是 HTTPS（安全的网站），在 TCP 握手后还会进行 **TLS 握手**（1-RTT 或 2-RTT），双方交换加密密钥，确保之后的对话内容只有双方能看懂，就像用暗语通话。
 
 ---
 
-### 第一次握手：SYN（同步请求）
+## 4. 第四步："买家"和"商家"的对话 —— HTTP 请求与响应
 
-**浏览器发送 SYN 包**
+::: tip 🤔 核心问题
+**浏览器和服务器在说什么？** 建立连接后，浏览器如何"告诉"服务器它想要什么？服务器又如何"回应"？
+:::
 
-就像你拨通朋友电话后说的第一句话："喂，你好，能听到我说话吗？"
+### 生活比喻：仓库发货
 
-- **SYN** 是 **Synchronize**（同步）的缩写
-- 浏览器生成一个随机数字（比如 `Seq = 100`），告诉服务器："我要开始建立连接了，我的初始序号是 100"
-- 这个序号用来标记后续发送的数据顺序，防止乱序
+物流车到达仓库："这是订单（HTTP请求），**我要取回商品（网页 HTML 源代码）！**"
+仓库管理员核对："订单有效，这是你要的包裹（**HTML 文件**），请拿好。"
 
-**这一步确认了什么？** 服务器收到了浏览器的消息 → 浏览器的**发送通道**正常。
+### 真实过程：HTTP 协议通信
 
----
+**HTTP（HyperText Transfer Protocol，超文本传输协议）**是浏览器和服务器之间的"对话规则"。通道建立后，浏览器发送**取货请求**，**核心目标是拿回网页的源代码（HTML 文件）**：
 
-### 第二次握手：SYN-ACK（同步+确认）
+**HTTP 请求示例：**
 
-**服务器回复 SYN-ACK 包**
+```http
+GET /index.html HTTP/1.1          ← 请求方法 + 路径 + 协议版本
+Host: www.example.com             ← 目标主机（支持虚拟主机，一台服务器可托管多个网站）
+User-Agent: Chrome/120.0          ← 客户端标识（服务器可据此返回适配内容）
+Accept: text/html,application/xhtml+xml  ← 可接受的响应格式
+Accept-Language: zh-CN,zh;q=0.9   ← 偏好的语言
+Accept-Encoding: gzip, deflate    ← 支持的压缩格式
+Connection: keep-alive            ← 保持连接（复用 TCP 连接）
+Cookie: session_id=abc123         ← 身份凭证
+```
 
-就像朋友回答："喂喂，我能听到你！你也能听到我吗？"
+::: tip 💡 开发者顿悟：这不就是 API 吗？
+**一模一样！**
+你平时写的 API 调用（`fetch` / `axios`）和浏览器访问网页，在 **HTTP 层面完全是同一个东西**。
 
-- **SYN-ACK** = **Synchronize + Acknowledge**（同步+确认）
-- 服务器做两件事：
-  1. **ACK**：确认收到浏览器的消息（`Ack = 101`，表示"我期待收到你序号为 101 的下一个包"）
-  2. **SYN**：服务器也生成自己的随机序号（比如 `Seq = 200`），告诉浏览器："我的初始序号是 200"
+它们都是发送一个请求，服务器返回一段文本数据。
 
-**这一步确认了什么？** 浏览器收到了服务器的回复 → 服务器的**发送通道**正常，浏览器的**接收通道**正常。
+- 如果服务器给的是 **HTML**，浏览器就把它**画出来**（变成网页）。
+- 如果服务器给的是 **JSON**，你的代码就把它**存起来**（用于逻辑处理）。
 
----
+**根本就没有"两种"请求，只有同一种 HTTP 请求，只是返回的数据格式（Content-Type）不同而已。**
+这也是为什么理解了 HTTP，你就理解了 90% 的后端 API 原理。
 
-### 第三次握手：ACK（确认）
+如果你想深入学习 API 开发，请参考 [API 章节](./api-intro.md)。
+:::
 
-**浏览器回复 ACK 包**
+**常见 HTTP 方法：**
 
-就像你回答："能听到！那我们开始聊正事吧！"
+- `GET`：获取资源（安全、幂等，可被缓存）
+- `POST`：提交数据（创建资源，如注册、登录）
+- `PUT`：更新资源（完整替换）
+- `PATCH`：部分更新资源
+- `DELETE`：删除资源
+- `HEAD`：获取响应头（不返回主体，用于检查资源是否存在）
 
-- **ACK** 是 **Acknowledge**（确认）的缩写
-- 浏览器回复：`Ack = 201`，表示"我期待收到你序号为 201 的下一个包"
+**服务器返回 HTTP 响应：**
 
-**这一步确认了什么？** 服务器收到了浏览器的确认 → 服务器的**接收通道**也正常。
+```http
+HTTP/1.1 200 OK                   ← 协议版本 + 状态码 + 状态描述
+Date: Mon, 23 May 2025 12:00:00 GMT  ← 服务器时间
+Content-Type: text/html; charset=UTF-8  ← 内容类型和编码
+Content-Length: 1234              ← 内容长度（字节）
+Cache-Control: max-age=3600       ← 缓存策略
+Set-Cookie: user_id=xyz789        ← 设置 Cookie
 
----
+```
+
 **HTTP 状态码分类：**
-### 为什么必须是三次？两次行不行？
+
 | 状态码      | 类别       | 含义             | 生活类比                         |
-**假设只有两次握手：**
-
-1. 浏览器："喂，能听到吗？"
-2. 服务器："能听到！"
-
-这时候服务器以为连接建立了，开始发送数据。但如果服务器的回复在半路丢了，浏览器根本没收到，浏览器就不会认为连接建立成功，也不会处理服务器发来的数据。
-
-**结果**：服务器单方面认为连接已建立，疯狂发数据，但浏览器全当垃圾丢弃。服务器资源被白白浪费。
-
-**三次握手的精妙之处**：
-
-第三次握手的 ACK 包，**证明了浏览器确实收到了服务器的回复**。只有浏览器收到了，才会回复 ACK；服务器收到了这个 ACK，才能**100%确定**双方通道都是通的。
-
-这就像打电话时的完整确认：
-- 你："喂，能听到吗？"（SYN）
-- 朋友："能听到，你呢？"（SYN-ACK）
-- 你："我也能听到！"（ACK）
-
-**这一步完成了什么？** 浏览器和服务器都确认了：**我能发给你，我能收到你的，你也能发给我，你也能收到我的**。一条可靠的 TCP 通道正式建立！
-
-**现在可以开始了吗？** 通道已建立，下一步就是正式发送请求，获取网页内容。
-
----
-
-## 第四步：寄包裹 (HTTP 请求与响应)
-
-**上一步完成了**：通过 TCP 三次握手，建立了可靠的通信通道。
-
-**这一步要实现**：正式发送请求，获取网页内容。
-
-**目的**：浏览器向服务器"下单"，服务器返回"货物"（网页内容）。
+| ----------- | ---------- | ---------------- | -------------------------------- |
+| **200**     | 成功       | 请求成功处理     | "订单确认，马上发货"             |
+| **301/302** | 重定向     | 资源已移动       | "本店搬家了，请去新店下单"       |
+| **304**     | 未修改     | 缓存仍有效       | "你上次买的还能用，不用重新发货" |
+| **400**     | 客户端错误 | 请求格式错误     | "订单填写模糊，看不懂"           |
+| **401**     | 未授权     | 需要身份验证     | "请先出示会员卡"                 |
+| **403**     | 禁止访问   | 权限不足         | "非内部人员禁止入内"             |
+| **404**     | 未找到     | 资源不存在       | "仓库里没这款商品"               |
+| **500**     | 服务器错误 | 服务器内部错误   | "仓库起火了，暂时发不了货"       |
+| **502**     | 网关错误   | 上游服务器无响应 | "总仓没货了，分仓也调不到"       |
+| **503**     | 服务不可用 | 服务器过载或维护 | "爆单了，暂停接单"               |
+
 <HttpExchangeDemo />
 
 ---
-**💡 核心原理解析：HTTP 请求与响应的小纸条**
-
-浏览器会把你刚才写好的购物单，按照一种极为规范的格式打包（这叫 **HTTP 请求头**），正式塞进刚才建立好的 TCP 通道里，发给服务器。
-
-- **买方发纸条（HTTP Request）**：
-  浏览器发出的包裹里，写着大写的请求指令。如果是看网页就是 `GET`，如果是提交账号密码登录就是 `POST`。不仅如此，这张纸条里还附带了一些重要情报："嗨，我是用 Mac 电脑的 Chrome 浏览器访问的哦，另外我只能听懂中文，请把给我的货也转换成中文。"（这些补充说明就被叫做 **请求 Headers**）。
-
-- **卖方发纸条（HTTP Response）**：
-  位于千里之外的服务器收到这包东西后，看了一眼："哦，他要 `GET` 这个页面啊"。于是服务器飞速在自己的硬盘里找到相应的 HTML 网页代码打包好，在包裹最外面贴上一个标签：`200 OK`（意思是交易非常成功，你要的货全齐了），然后借由同一个通道，原路寄回给你的电脑。
-
-> **小科普**：如果是找不到你要找得页面，服务器就会贴个 `404 Not Found` 的悲伤标签给你退回来。如果是服务器自己代码写错了挂掉了，就会贴个 `500 Server Error` 的崩溃标签。
-
-**这一步完成了什么？** 浏览器收到了服务器返回的 HTML、CSS、JavaScript 代码（也就是网页的"原材料"）。
-
-**但问题来了**：这些代码只是文本，还不是你能看到的网页画面。下一步，浏览器需要把这些代码"翻译"成屏幕上的像素。
-
 
 ## 5. 第五步：拆开"包裹" —— 浏览器渲染
-## 第五步：拆解组装 (浏览器渲染)
+
 ::: tip 🤔 核心问题
-**上一步完成了**：通过 HTTP 请求，浏览器获取了网页的源代码（HTML、CSS、JavaScript）。
+**代码怎么变成画面？** 服务器发来的是枯燥的 HTML/CSS/JavaScript 代码，浏览器如何把它们变成丰富多彩的网页？
+:::
+
 ### 生活比喻：拆箱与组装
-**这一步要实现**：把代码转换成屏幕上可见的网页画面。
+
 你终于收到了快递包裹（HTTP 响应），但打开一看，里面不是现成的家具，而是一堆**零件**（HTML）和一本**组装说明书**（CSS）。作为"买家"（浏览器），你需要亲自动手组装：
-**目的**：将文本代码"翻译"成像素，让用户看到最终的网页。
+
+1.  **拆开包装**：取出所有零件，核对清单（解析 HTML → DOM 树）。
+2.  **阅读说明**：看懂说明书，知道哪个零件该装哪、什么颜色（解析 CSS → CSSOM 树）。
+3.  **分类整理**：挑出需要组装的零件，扔掉包装泡沫（`display: none`），准备组装（构建渲染树）。
+4.  **测量位置**：用尺子量好房间尺寸，决定每个家具具体摆在哪（布局/回流）。
+5.  **上色装饰**：给家具刷漆、贴贴纸（绘制）。
+6.  **最终展示**：打扫干净，开灯展示（合成）。
+
+### 真实过程：浏览器渲染引擎
+
+浏览器收到的是 **HTML/CSS/JavaScript 代码**（枯燥的文本），但它要变成**像素画面**（精美的网页）。这个过程叫做**渲染（Rendering）**，由浏览器的**渲染引擎**（如 Chrome 的 Blink、Safari 的 WebKit）执行。
+
+#### 步骤1：解析 HTML → 构建 DOM 树 (零件清单)
+
+浏览器读取 HTML 字节流，将其解析为**DOM（Document Object Model，文档对象模型）树**。这就像把一堆散乱的零件整理成一个有层级关系的清单：
+
+```html
+<!-- 原始 HTML -->
+<div class="header">标题</div>
+<div class="content">内容</div>
+```
+
+```text
+DOM 树结构：
+Document
+ └─ html
+     └─ body
+         ├─ div.header ("标题")
+         └─ div.content ("内容")
+```
+
+#### 步骤2：解析 CSS → 构建 CSSOM 树 (说明书)
+
+浏览器解析所有的 CSS（内联、外部文件），构建**CSSOM（CSS Object Model）树**。这就像理解说明书上的样式规则：
+
+```css
+.header {
+  color: blue;
+  font-size: 24px;
+} /* 标题要是蓝色的 */
+.content {
+  display: none;
+} /* 内容暂时隐藏 */
+```
+
+#### 步骤3：合并 → 渲染树 (准备组装)
+
+DOM 树 + CSSOM 树 = **渲染树 (Render Tree)**。
+关键点：**只有"可见"的元素才会在渲染树中**。
+
+- `.header`：在渲染树中（可见）。
+- `.content`：**不在**渲染树中（因为 `display: none`，就像被扔掉的包装纸，不需要组装）。
+
+#### 步骤4：布局 (Layout / Reflow) —— 测量尺寸
+
+浏览器计算渲染树中每个节点在屏幕上的**精确坐标和大小**。
+
+- "这个标题框宽 100px，高 50px，放在屏幕左上角 (0,0) 位置。"
+- 这个过程叫**重排 (Reflow)**。如果窗口大小变了（比如手机横屏），所有元素的位置都要重新计算，非常消耗性能。
+
+#### 步骤5：绘制 (Paint) —— 上色
+
+知道位置后，浏览器开始填充像素：画背景色、文字颜色、边框、阴影等。
+
+#### 步骤6：合成 (Composite) —— 最终展示
+
+现代浏览器会将页面分成多个**图层 (Layers)** 分别绘制（比如 3D 变换、滚动条独立图层），最后由 GPU 将它们像 Photoshop 图层一样叠加在一起，呈现在屏幕上。
+
 <BrowserRenderingDemo />
 
 ::: info 💡 你知道吗？
-**💡 核心原理解析：毫秒级的画家**
-
-此时你电脑收到的，仅仅是一大串干瘪枯燥的文本代码（HTML 骨架、CSS 色彩图纸、JS 交互动效代码）。这就像你网购了一箱子乐高，它给你的只有几千个塑料零件和一本极度复杂的说明书。
-
-浏览器的组装过程堪比惊心动魄的全自动工厂流水线：
-
-1. **搭骨架 (DOM 解析)**：工人先把 HTML 文件通读一遍，理清楚网页的结构。比如"这里要有一个标题框，那里要有三个图片框"。这个骨架叫做 DOM 树。
-2. **上颜色 (CSS 解析)**：紧接着看 CSS 文件，"哦，老王说标题框必须是红色的，图片框必须有圆角。"
-3. **几何计算排版 (Layout)**：结合骨架和颜色后，开始拿尺子计算。因为每个人的屏幕大小不一样，同样是三个图片框，在手机上只能竖着放，在电脑上可以横着放。必须计算出每一个像素块极其精确的摆放坐标。
-4. **上色绘制 (Paint)**：最后拿起了画笔，按照前面算出来的精确设计图，把真真切切的颜色和像素渲染到了你的显示器上！
-
-**这一步完成了什么？** 浏览器把代码转换成了屏幕上的像素，用户终于看到了完整的网页！
+**布局和绘制**是浏览器最忙碌的时候。网页里的元素越多、结构越复杂，浏览器就需要花更多时间来计算位置和上色。这就是为什么有的复杂网页打开会卡顿的原因。
+:::
+
 ---
 
 ## 5.5 网页是怎么"生成"的？静态网站 vs 动态网站
-## 完整流程回顾
+
 ::: tip 🤔 核心问题
-让我们把整个过程串起来：
+**网页内容从哪里来？** 前面我们讲了浏览器如何渲染页面，但服务器上的 HTML 文件是怎么来的？是提前做好还是现做？
+:::
+
 前面我们讲的都是浏览器如何"拆开包裹"——把服务器发来的 HTML/CSS/JS 渲染成页面。但你有没有想过一个问题：**服务器上那个 HTML 文件是怎么来的？**
-| 步骤 | 完成了什么 | 下一步需要什么 |
-|------|-----------|---------------|
-| **1. URL 解析** | 拆解网址，知道要去哪 | 需要把域名转成 IP |
-| **2. DNS 解析** | 拿到服务器 IP 地址 | 需要确认服务器在线 |
-| **3. TCP 握手** | 建立可靠通信通道 | 需要发送正式请求 |
-| **4. HTTP 交换** | 获取网页源代码 | 需要把代码转成画面 |
-| **5. 浏览器渲染** | 把代码渲染成像素 | ✅ 用户看到网页！ |
+
+答案是：**有两种方式**，这就是静态网站和动态网站的区别。
+
+### 静态网站：提前做好、直接给你
+
+想象你去超市买饼干。货架上的饼干都是工厂已经生产好的，你直接拿走就行，不需要等。
+
+**静态网站**就是这样的"成品"——网页在服务器上已经准备好了，你访问时服务器直接把现成的 HTML 文件发给你，不做任何额外处理。
+
+**特点：**
+- ✅ 访问速度快（服务器直接发文件，不用计算）
+- ✅ 制作简单（写好 HTML 就能用）
+- ✅ 承载力强（可以用 CDN 分发，多少人访问都不怕）
+- ❌ 内容难更新（想改内容就要重新生成文件）
+
+**常见例子：** 公司介绍页、产品文档、帮助中心、个人博客
+
+### 动态网站：现点现做、每次不同
+
+这次想象你去餐厅点餐。厨师根据你的订单现做，你点宫保鸡丁不会给你上糖醋里脊。
+
+**动态网站**就是你访问时才"现场制作"的页面——服务器收到你的请求后，去数据库查资料、计算数据，然后生成一个全新的 HTML 发给你。
+
+**特点：**
+- ✅ 内容实时（购物车显示最新库存、新闻随时更新）
+- ✅ 因人而异（登录后看到你的个人信息）
+- ✅ 功能强大（搜索、评论、推荐、支付都能实现）
+- ❌ 访问速度慢（服务器需要时间计算）
+- ❌ 服务器压力大（同时很多人访问要排队）
+
+**常见例子：** 淘宝、微博、在线银行、在线文档
+
+**需要服务器吗？** 动态网站确实需要某种"后端"来生成内容，但形式多样：
+- **传统服务器**：自己买/租服务器（阿里云 ECS、AWS EC2）
+- **Serverless**：不用管服务器，云厂商帮你运行代码（AWS Lambda、阿里云函数计算、Cloudflare Workers）
+- **调用第三方 API**：支付用 Stripe、天气用气象局 API，自己不写后端代码
+
+::: tip 💡 静动态结合
+现在很多网站是"混合"的：网页主体是静态的，但某些部分（比如评论区、搜索框）是动态加载的。JavaScript 可以在页面加载后调用 API 获取数据，实现"静态页面 + 动态功能"。
+:::
+
+### 📊 静态 vs 动态，一对比就清楚
+
+| | 静态网站 | 动态网站 |
+|---|---------|---------|
+| **怎么来的** | 提前做好，存服务器上 | 访问时现做 |
+| **像什么** | 超市货架上的商品 | 餐厅现点的菜 |
+| **速度** | 快 | 慢（需要计算） |
+| **能改内容吗** | 难（要重新生成） | 容易（后台直接改） |
+| **适合做什么** | 展示型内容（介绍页、文档） | 交互型应用（购物、社交） |
+| **典型例子** | 公司官网、帮助文档 | 淘宝、微信、在线银行 |
+
+### 🤔 常见疑问
+
+**Q: 静态网站是不是不能用 JavaScript？**
+
+当然不是！轮播图、折叠菜单、表单验证这些交互功能，静态网站都能用 JavaScript 实现。我们说的"静态""动态"，是指**页面内容是不是提前准备好的**，跟有没有交互功能是两回事。
+
+**Q: 动态网站一定要自己买服务器吗？**
+
+不一定。除了传统服务器，你还可以用 Serverless（云函数）、或者直接调用第三方 API。现在的趋势是"能不动服务器就不动"——用静态网站 + JavaScript 调用 API 的方式，既快又省成本。
+
+::: tip 💡 重要提示
+无论静态网站还是动态网站，**浏览器渲染的原理都是一样的**！服务器发来的是什么，浏览器就渲染什么。区别只在于：
+- 静态网站：服务器发来的是"成品"
+- 动态网站：服务器发来的是"现做的"
+
+作为前端开发者，你主要关注的是浏览器如何处理收到的内容，而不是服务器怎么生成的。
+:::
+
 ---
 
 ## 6. 总结：一次完整的"网购"之旅
-## 结语：0.5 秒里发生了什么
+
 ::: tip 🎉 学完本章，你应该能
-敲下回车，等上半秒，页面就跳出来了——我们早就习惯了这个速度，甚至觉得慢。
+- 解释从输入网址到显示页面的完整流程
+- 理解 URL、DNS、TCP、HTTP 的作用和关系
+- 知道浏览器如何渲染页面
+- 区分静态网站和动态网站
+- 用生活化比喻向他人解释浏览器工作原理
+:::
+
 让我们回顾整个旅程：
-但仔细想想，就在这眨眼的功夫里：
+
 | 阶段        | 技术术语   | 网购类比 | 核心任务           | 关键技术                       |
-- **第一步**：浏览器把你输入的网址拆开看懂
-- **第二步**：跑去问了好多台服务器才要到 IP 地址
-- **第三步**：跟大洋彼岸的服务器来回确认了三次"能听见吗"
-- **第四步**：把请求打包发过去，再等着收回来
-- **第五步**：最后还要把成千上万行代码瞬间组装成你能看到的画面
+| ----------- | ---------- | -------- | ------------------ | ------------------------------ |
+| **1. 解析** | URL 解析   | 填写订单 | 理解买家想买什么   | 协议、域名、端口、路径、参数   |
+| **2. 查询** | DNS 查询   | 查仓库址 | 找到店铺的发货仓库 | 递归/迭代查询、缓存机制        |
+| **3. 连接** | TCP 握手   | 建立通道 | 确保物流通畅       | 三次握手、序列号、流量控制     |
+| **4. 对话** | HTTP 交换  | 仓库发货 | 提交订单并收货     | 请求方法、状态码、头部字段     |
+| **5. 展示** | 浏览器渲染 | 拆箱组装 | 把商品展示出来     | DOM、CSSOM、渲染树、布局、绘制 |
+
 **整个过程通常在几百毫秒内完成** —— 想想这有多么不可思议！
-这些步骤一环扣一环，**前一步的输出是后一步的输入**，中间哪个环节出问题，页面就打不开。而那些路由器、服务器、光缆，就默默在后台 24 小时运转，保证你每次滑动手机时，内容都能准时出现。
+
 你的浏览器在不到1秒的时间里：
-下次等网页加载的时候，或许可以想想：这 0.5 秒，其实挺忙的。
+
+- 解析了一个复杂的地址
+- 查询了分布在全球的 DNS 服务器
+- 和千里之外的服务器建立了可靠连接
+- 进行了一次完整的 HTTP 对话
+- 把枯燥的代码变成了精美的画面
+
+这就是互联网的魅力：**复杂的技术，简单的体验**。
+
+::: info 💡 进阶学习
+如果你想深入了解某个环节，可以参考：
+- **API 开发**：[API 简介](./api-intro.md) - 学习如何设计和使用 API
+- **前端性能**：[前端性能优化](./frontend-performance.md) - 学习如何优化网页加载速度
+- **浏览器渲染**：[浏览器渲染管道](./browser-rendering-pipeline.md) - 深入了解渲染细节
+:::
+
+---
+
+## 7. 名词速查表 (Glossary)
+
+| 名词        | 全称                          | 简单解释                                                                   |
+| ----------- | ----------------------------- | -------------------------------------------------------------------------- |
+| **URL**     | Uniform Resource Locator      | **统一资源定位符**。网页的"地址"，告诉浏览器去哪里找资源。                 |
+| **DNS**     | Domain Name System            | **域名系统**。互联网的"电话簿"，把人类可读的域名转换成机器可读的 IP 地址。 |
+| **IP 地址** | Internet Protocol Address     | **互联网协议地址**。每台联网设备的唯一"门牌号"，如 `192.168.1.1`。         |
+| **TCP**     | Transmission Control Protocol | **传输控制协议**。确保数据可靠传输的"规则"，通过三次握手建立连接。         |
+| **HTTP**    | HyperText Transfer Protocol   | **超文本传输协议**。浏览器和服务器"对话"的规则。                           |
+| **HTTPS**   | HTTP Secure                   | **安全的 HTTP**。在 HTTP 基础上加了加密（TLS/SSL），保护数据安全。         |
+| **HTML**    | HyperText Markup Language     | **超文本标记语言**。网页的"骨架"，定义内容的结构。                         |
+| **CSS**     | Cascading Style Sheets        | **层叠样式表**。网页的"皮肤"，定义内容的外观。                             |
+| **DOM**     | Document Object Model         | **文档对象模型**。浏览器把 HTML 转换成的树形结构，方便操作。               |
+| **CSSOM**   | CSS Object Model              | **CSS 对象模型**。浏览器把 CSS 转换成的树形结构。                          |
+| **渲染**    | Rendering                     | 浏览器把代码转换成屏幕像素的过程。                                         |
+| **RTT**     | Round Trip Time               | **往返时间**。数据包从发送到接收确认的时间，影响网页加载速度。             |
+
+---
+
+::: tip 🎓 恭喜
+现在当你再次在地址栏输入网址并按下回车时，你已经能看到屏幕背后的那个忙碌而精彩的数字世界了。
+
+你理解了：
+- 为什么有时候网页打不开（DNS 解析失败、服务器宕机）
+- 为什么有的网页快、有的慢（网络延迟、服务器性能、页面复杂度）
+- 浏览器是如何把代码变成画面的（渲染管道）
+
+**这就是理解技术原理的价值** — 遇到问题时，你能知道从哪里找原因，而不是束手无策。
+:::
+:::