docs: update Chinese documentation and add Vue components

- Update AI capability dictionary by removing redundant mention of Baidu's model
- Add new Vue components for context engineering visualization (IntroProblemReasonSolution, MemoryPalaceDemo, MemoryPalaceActionDemo, KVCacheDemo, LostInMiddleDemo)
- Register new components in theme index.js
- Enhance audio introduction with new interactive demos (AudioQuickStartDemo, MelSpectrogramDemo, TTSPipelineDemo, VoiceCloningDemo, ASRvsTTSDemo, AudioTokenizationDemo, EmotionControlDemo)
- Improve existing context engineering demos with Chinese localization and better tokenization
- Fix Japanese documentation layout by properly closing NavGrid components

docs/zh-cn/appendix/url-to-browser.md

@@ -1,142 +1,358 @@
-# 从 URL 输入到浏览器显示 (From URL to Browser)
+# 从 URL 到网页显示：一次网络"快递"之旅
 
-> 💡 **学习指南**：本章节通过交互式演示，带你深入了解浏览器如何将一行网址变成丰富多彩的页面。我们将从输入 URL 开始，一步步拆解背后的网络请求、连接建立和页面渲染过程。
+<script setup>
+import UrlToBrowserQuickStart from '../../.vitepress/theme/components/appendix/url-to-browser/UrlToBrowserQuickStart.vue'
+import UrlParserDemo from '../../.vitepress/theme/components/appendix/url-to-browser/UrlParserDemo.vue'
+import DnsLookupDemo from '../../.vitepress/theme/components/appendix/url-to-browser/DnsLookupDemo.vue'
+import TcpHandshakeDemo from '../../.vitepress/theme/components/appendix/url-to-browser/TcpHandshakeDemo.vue'
+import HttpExchangeDemo from '../../.vitepress/theme/components/appendix/url-to-browser/HttpExchangeDemo.vue'
+import BrowserRenderingDemo from '../../.vitepress/theme/components/appendix/url-to-browser/BrowserRenderingDemo.vue'
+</script>
 
-## 0. 全景图：一次神奇的旅行
-
-当你在浏览器地址栏输入一个网址并按下回车，短短几秒钟内，背后发生了一系列复杂而精妙的过程。这就像是一次跨越万水千山的旅行。
-
-它的核心任务只有一个：**将你想要的资源（网页）准确无误地从世界的另一端搬运到你的屏幕上**。
-
-我们可以把这个过程分为五个关键阶段，点击下方的步骤来预览整个流程：
-
-<UrlToBrowserDemo />
+> **学习指南**：本章节无需编程基础。我们将用**"寄快递"**的生活化比喻，配合**真实的技术过程**，带你一步步理解浏览器如何将一行网址变成丰富多彩的页面。
 
 ---
 
-## 1. 第一步：寻址 (URL Parsing)
+## 0. 引言：当你按下回车键的那一刻
 
-### 1.1 计算机的"导航地址"
+想象你要给远方的朋友寄一份礼物。你需要：
+1. **填写快递单**（写明地址、收件人）
+2. **快递公司查地址**（把"XX市XX区"转换成具体的门牌号）
+3. **打电话确认**（确保对方在家能收件）
+4. **快递员送达**（把包裹交给对方）
+5. **朋友拆开包裹**（看到礼物）
 
-计算机需要一个精确的地址格式才能找到资源。这就是 **URL (统一资源定位符)** 的作用。它不仅告诉浏览器**去哪里**（域名），还告诉它**怎么去**（协议），以及**找什么**（路径）。
+**访问网页的过程和寄快递惊人地相似！**
 
-试着在下方的模拟地址栏中输入不同的 URL，看看它是如何被拆解的：
+当你在浏览器输入 `google.com` 并按下回车，浏览器就是那个"快递员"，它要完成一次从"你的电脑"到"远方服务器"再到"屏幕显示"的完整旅程。
+
+<UrlToBrowserQuickStart />
+
+---
+
+## 1. 第一步：填写"快递单" —— URL 解析
+
+### 生活比喻：填写快递单
+
+假设你只在快递单上写"寄给张三"，快递员肯定找不到人。你需要写清楚：
+- **用什么快递**（顺丰/中通）
+- **哪个城市**（北京市）
+- **具体地址**（朝阳区XX街道XX号）
+- **哪栋楼哪间房**（3号楼201）
+- **备注信息**（放快递柜/打电话）
+
+### 真实过程：浏览器解析 URL
+
+**URL（Uniform Resource Locator，统一资源定位符）**就是浏览器世界的"快递单格式"。当你在地址栏输入 `https://www.example.com:8080/path/page.html?id=123#section`，浏览器会立即拆解它：
+
+| URL 部分 | 示例值 | 快递单类比 | 技术作用 |
+|----------|--------|-----------|----------|
+| **协议** `https://` | 安全超文本传输协议 | **快递公司**：顺丰（安全）vs 中通（普通） | 决定使用什么规则通信。`http` 是普通传输，`https` 是加密传输 |
+| **域名** `www.example.com` | 服务器的人类可读名字 | **收件人姓名**：张三 | 告诉浏览器要找哪台服务器。域名是为了让人记住，最终要转换成 IP 地址 |
+| **端口** `:8080` | 服务器的具体"门牌号" | **详细门牌号**：3号楼201（默认不写） | 服务器上可能有多个服务，端口指定访问哪一个。HTTP 默认 80，HTTPS 默认 443 |
+| **路径** `/path/page.html` | 服务器上的文件位置 | **房间里的抽屉**：衣柜第二层 | 指定服务器上的具体资源位置 |
+| **查询参数** `?id=123` | 附加信息 | **备注**：请轻拿轻放 | 传递给服务器的额外数据，如搜索关键词、页码等 |
+| **锚点** `#section` | 页面内的位置 | **书里的页码**：翻到第5页 | 页面加载后自动滚动到指定位置，不发送给服务器 |
 
 <UrlParserDemo />
 
-**关键部分解析**：
-
-- **Protocol (协议)**：通常是 `https` (安全) 或 `http`。就像告诉司机是"坐飞机"还是"坐火车"。
-- **Host (域名)**：`www.example.com`。目的地的名字，方便人类记忆。
-- **Port (端口)**：服务器的"门牌号"。Web 服务默认是 80 (HTTP) 或 443 (HTTPS)，通常省略不写。
-- **Path (路径)**：`/path/to/page`。资源在服务器文件系统中的具体位置。
-- **Query (参数)**：`?q=vue`。给服务器的附加指令，就像点餐时的备注"不要香菜"。
+> **关键理解**：URL 的存在是为了让**人类**能记住和输入。计算机最终需要的是 **IP 地址**（就像快递员最终需要的是门牌号，而不是"张三的家"）。
 
 ---
 
-## 2. 第二步：定位 (DNS Lookup)
+## 2. 第二步：查"地址簿" —— DNS 查询
 
-### 2.1 互联网的"电话簿"
+### 生活比喻：查地址簿
 
-虽然我们记住了 `google.com` 这样的域名，但计算机之间通信真正识别的是 **IP 地址**（如 `142.250.185.238`）。
+你告诉快递员"送到张三那里"，但快递员怎么知道张三住哪？他需要查地址簿：
+1. 先翻**通讯录**（最近联系过的人）→ 浏览器缓存
+2. 没有的话问**社区服务中心**（他们知道各个小区归谁管）→ 本地 DNS 服务器
+3. 社区问**总管理处**（他们知道XX街道归哪个片区管）→ 根域名服务器
+4. 片区查**住户登记**（最终找到张三的门牌号）→ 权威域名服务器
 
-**DNS (Domain Name System)** 就是互联网的"电话簿"或"导航系统"。当你输入域名时，浏览器需要先通过 DNS 找到它对应的 IP 地址。
+### 真实过程：DNS 分层查询
 
-点击下方的 **"Go"** 按钮，观察 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 />
 
-**查询流程解析**：
-
-1.  **浏览器缓存/Hosts**：先看看自己是否最近去过（缓存），或者本地小本本上有没有记（Hosts 文件）。
-2.  **递归解析器 (Recursive Resolver)**：通常由你的 ISP (运营商) 提供。它像个尽职的跑腿员，负责帮你跑完剩下的路。
-3.  **根域名服务器 (Root Server)**：它是 DNS 层级的顶端（`.`）。它不知道具体地址，但知道谁管 `.com`。
-4.  **顶级域名服务器 (TLD Server)**：管理 `.com`、`.org` 等后缀的服务器。它会告诉你 `google.com` 归谁管。
-5.  **权威域名服务器 (Authoritative Server)**：最终的管理者，它知道 `www.google.com` 的确切 IP 地址。
+> **为什么需要这么多层？** 想象一下如果全世界只有一个地址簿，几十亿人同时查，早就崩溃了。分层设计让每个层级只管理自己的"辖区"，既高效又可靠。
 
 ---
 
-## 3. 第三步：连接 (TCP Handshake)
+## 3. 第三步：打电话确认 —— TCP 三次握手
 
-### 3.1 建立可靠的通路
+### 生活比喻：打电话确认
 
-拿到 IP 地址后，浏览器找到了服务器。但在传输数据之前，它们必须建立一条可靠的连接，确保双方都能"听得到"且"说得出"。
+假设快递员直接冲到张三家门口，结果：
+- 张三不在家 → 白跑一趟
+- 电话打不通 → 不知道送哪
+- 地址错了 → 送错地方
 
-这就是著名的 **TCP 三次握手 (Three-Way Handshake)**。
+**所以在真正送包裹之前，必须先确认"对方能收到"**。
 
-点击 **"Connect"** 亲自完成这次握手：
+### 真实过程：TCP 三次握手
+
+**TCP（Transmission Control Protocol，传输控制协议）**是确保数据可靠传输的规则。在发送任何数据前，客户端和服务器必须通过"三次握手"建立可靠连接：
+
+```
+客户端（你的浏览器）              服务器（网站）
+   |                                |
+   |--- SYN=1, seq=x ------------->|  第1次：我想连接你，我的初始序号是 x
+   |                                |
+   |<-- SYN=1, ACK=1, seq=y, ack=x+1 |  第2次：我也想连接你，我的初始序号是 y，期待收到 x+1
+   |                                |
+   |--- ACK=1, ack=y+1 ----------->|  第3次：确认，期待收到 y+1
+   |                                |
+   ===== 连接建立，开始传输数据 =====
+```
+
+**为什么是三次，不是两次？**
+
+- **第一次（SYN）**：客户端证明自己能发送
+- **第二次（SYN-ACK）**：服务器证明自己能接收和发送
+- **第三次（ACK）**：客户端证明自己能接收
+
+三次握手确保：**双方都能发、双方都能收** —— 四个条件都满足，才能可靠传输。
+
+**TCP 还负责：**
+- **数据分包**：大数据拆成小数据包传输
+- **顺序重组**：确保数据包按正确顺序组装
+- **错误重传**：丢包后自动重新发送
+- **流量控制**：根据网络状况调整发送速度
 
 <TcpHandshakeDemo />
 
-**握手三部曲**：
-
-1.  **SYN** (Synchronize)：客户端发送一个包，说"你好，我想和你建立连接，我的序列号是 X"。
-2.  **SYN-ACK** (Synchronize-Acknowledge)：服务器收到后回复，"好的，收到了 X。我也想和你建立连接，我的序列号是 Y"。
-3.  **ACK** (Acknowledge)：客户端最后回复，"好的，收到了 Y。那我们开始传输数据吧"。
-
-> 🔒 **关于 HTTPS (TLS)**：
-> 如果使用 HTTPS，在 TCP 握手之后，还会进行 **TLS 握手**。双方会协商加密算法并交换证书，确保后续传输的数据像装在保险箱里一样安全。
+> **HTTPS 的额外步骤**：如果是 HTTPS（安全的网站），在 TCP 握手后还会进行 **TLS 握手**（1-RTT 或 2-RTT），双方交换加密密钥，确保之后的对话内容只有双方能看懂，就像用暗语通话。
 
 ---
 
-## 4. 第四步：交流 (HTTP Exchange)
+## 4. 第四步："快递员"和"收件人"的对话 —— HTTP 请求与响应
 
-### 4.1 索取与交付
+### 生活比喻：快递员送达
 
-连接建立好了，浏览器终于可以发出它的请求了："请给我首页的 HTML 代码"。这就像在餐厅点餐。
+快递员敲门："张三在吗？您的快递！"
+张三开门："好的，给我吧。" 或者 "我没买东西啊，退回去吧。"
 
-**HTTP (HyperText Transfer Protocol)** 定义了这种对话的格式。
+### 真实过程：HTTP 协议通信
 
-在下方的模拟器中尝试发送不同的请求（GET/POST），观察网络日志：
+**HTTP（HyperText Transfer Protocol，超文本传输协议）**是浏览器和服务器之间的"对话规则"。TCP 连接建立后，浏览器发送 HTTP 请求：
+
+**HTTP 请求示例：**
+```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         ← 身份凭证
+```
+
+**常见 HTTP 方法：**
+- `GET`：获取资源（安全、幂等，可被缓存）
+- `POST`：提交数据（创建资源，如注册、登录）
+- `PUT`：更新资源（完整替换）
+- `PATCH`：部分更新资源
+- `DELETE`：删除资源
+- `HEAD`：获取响应头（不返回主体，用于检查资源是否存在）
+
+**服务器返回 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 状态码分类：**
+
+| 状态码 | 类别 | 含义 | 生活类比 |
+|--------|------|------|----------|
+| **200** | 成功 | 请求成功处理 | "给，这是你要的" |
+| **301/302** | 重定向 | 资源已移动 | "搬家了，去新地址取" |
+| **304** | 未修改 | 缓存仍有效 | "和上次一样，不用重新拿" |
+| **400** | 客户端错误 | 请求格式错误 | "你说的话我听不懂" |
+| **401** | 未授权 | 需要身份验证 | "请出示证件" |
+| **403** | 禁止访问 | 权限不足 | "你不准进" |
+| **404** | 未找到 | 资源不存在 | "没这个人/没这个东西" |
+| **500** | 服务器错误 | 服务器内部错误 | "我们这系统出故障了" |
+| **502** | 网关错误 | 上游服务器无响应 | "我们上级部门没回应" |
+| **503** | 服务不可用 | 服务器过载或维护 | "今天休息，不营业" |
+
 <HttpExchangeDemo />
 
 ---
-**对话过程**：
-
-1.  **请求 (Request)**：
-    - **Method**：`GET`（获取）、`POST`（提交数据）等。
-    - **Path**：我要什么资源。
-    - **Headers**：我是谁（User-Agent）、我想要什么格式（Accept）等元数据。
-
-2.  **响应 (Response)**：
-    - **Status Code**：`200 OK`（成功）、`404 Not Found`（没找到）、`500 Error`（服务器出错了）。
-    - **Headers**：内容类型（Content-Type）、服务器信息等。
-    - **Body**：具体的 HTML 代码、JSON 数据或图片二进制流。
-
 
 ## 5. 第五步：拆开"包裹" —— 浏览器渲染
-## 5. 第五步：展示 (Browser Rendering)
+
 ### 生活比喻：拆开包裹看到礼物
-### 5.1 代码如何变成画面？
+
 快递员把包裹交给张三，张三看到的是**包装盒**。他需要：
-浏览器收到的是一堆枯燥的 HTML 代码，它是如何变成我们在屏幕上看到的精美网页的呢？这个过程叫做**渲染 (Rendering)**。
+1. **拆开包装**（去掉快递袋）→ 解析 HTML
+2. **查看说明书**（了解怎么用）→ 解析 CSS
+3. **组装零件**（按说明书拼装）→ 构建渲染树
+4. **摆放位置**（确定放哪里）→ 布局计算
+5. **最终呈现**（展示成品）→ 绘制到屏幕
+
 ### 真实过程：浏览器渲染引擎
-浏览器就像一个精密的工厂，将原材料（HTML/CSS）加工成最终产品（屏幕上的像素）。
+
 浏览器收到的是 **HTML/CSS/JavaScript 代码**（枯燥的文本），但它要变成**像素画面**（精美的网页）。这个过程叫做**渲染（Rendering）**，由浏览器的**渲染引擎**（如 Chrome 的 Blink、Safari 的 WebKit）执行。
-点击下方的步骤，查看渲染流水线的每个阶段：
+
+#### 步骤1：解析 HTML → 构建 DOM 树
+
+浏览器读取 HTML 字节流，按编码（通常是 UTF-8）转换成字符，通过词法分析生成 Token，再解析成 DOM 节点，最终构建成**DOM（Document Object Model，文档对象模型）树**：
+
+```html
+<!-- 原始 HTML -->
+<html>
+  <body>
+    <div class="header">标题</div>
+    <div class="content">内容</div>
+  </body>
+</html>
+```
+
+```
+变成树形结构：
+        Document
+           │
+        html
+           │
+        body
+       /      \
+    div        div
+  .header    .content
+    │           │
+  "标题"      "内容"
+```
+
+**关键特性：**
+- **流式解析**：浏览器边下载边解析，不需要等整个 HTML 下载完
+- **遇到 script 标签**：会暂停解析，先下载并执行 JavaScript（除非加 `async` 或 `defer`）
+- **遇到 css 链接**：不会阻塞解析，但会阻塞渲染（需要等 CSS 下载完）
+
+#### 步骤2：解析 CSS → 构建 CSSOM 树
+
+浏览器同时解析 CSS（内联样式、`<style>` 标签、外部 `.css` 文件），构建**CSSOM（CSS Object Model，CSS 对象模型）树**：
+
+```css
+.header { color: blue; font-size: 24px; }
+.content { margin: 20px; background: #f0f0f0; }
+```
+
+CSSOM 树与 DOM 树结构类似，但存储的是样式规则。
+
+**CSS 解析特点：**
+- **阻塞渲染**：CSS 会阻塞渲染，因为浏览器不知道元素长什么样就无法绘制
+- **层叠和继承**：CSS 的"C"就是 Cascading（层叠），遵循特定的优先级规则
+
+#### 步骤3：合并 → 渲染树（Render Tree）
+
+DOM 树 + CSSOM 树 = **渲染树**。渲染树只包含可见元素（`display: none` 的元素不会进入渲染树）。
+
+```
+渲染树节点示例：
+- 节点类型：div
+- 样式：color: blue, font-size: 24px
+- 内容："标题"
+```
+
+#### 步骤4：布局（Layout / Reflow）
+
+浏览器计算渲染树中每个节点的**精确位置和大小**：
+- 视口（viewport）多大？
+- 每个元素占多少空间？
+- 元素之间如何排列？
+
+这个过程也叫**重排（Reflow）**，是性能开销较大的操作。
+
+**影响布局的因素：**
+- 视口大小变化（窗口缩放）
+- 元素尺寸变化（内容增减）
+- 字体大小变化
+- CSS 布局属性变化（`width`、`height`、`margin` 等）
+
+#### 步骤5：绘制（Paint）→ 合成（Composite）
+
+**绘制阶段**：把渲染树的每个节点绘制成像素，填充到**图层（Layer）**中。
+
+**合成阶段**：如果页面有多个图层（如 `position: fixed`、CSS 动画、3D 变换等），浏览器会把这些图层按正确顺序叠加，最终显示到屏幕上。
+
+**GPU 加速**：现代浏览器会把某些图层交给 GPU 处理，实现流畅的动画效果。
+
 <BrowserRenderingDemo />
 
 > **关键洞察**：渲染是"渐进式"的。浏览器不需要等所有内容都下载完才开始显示，而是收到一部分就渲染一部分。这就是为什么大网页会"慢慢加载出来"。
-**关键渲染路径 (Critical Rendering Path)**：
-
-1.  **构建 DOM 树**：解析 HTML，建立文档结构树（就像房屋的框架）。
-2.  **构建渲染树 (Render Tree)**：结合 CSS 样式，计算出所有**可见**元素的样式规则。
-3.  **布局 (Layout/Reflow)**：计算每个元素在屏幕上的确切坐标和大小（就像丈量尺寸）。
-4.  **绘制 (Paint)**：填充像素，包括颜色、图片、边框等。
-5.  **合成 (Composite)**：将不同的图层（Layer）在 GPU 中合成，最终显示在屏幕上。
+
 ---
 
 ## 6. 总结：一次完整的"网络快递"之旅
-## 6. 总结
+
 让我们回顾整个旅程：
-从 URL 输入到页面显示，这短短的几秒钟内，凝聚了计算机网络几十年的智慧结晶。
+
 | 阶段 | 技术术语 | 快递类比 | 核心任务 | 关键技术 |
-| 阶段        | 核心任务 | 关键技术  | 类比           |
-| :---------- | :------- | :-------- | :------------- |
-| **1. 寻址** | 解析目标 | URL       | 确定目的地地址 |
-| **2. 定位** | 查找 IP  | DNS       | 查电话簿       |
-| **3. 连接** | 建立通路 | TCP/TLS   | 打电话确认通畅 |
-| **4. 交流** | 交换数据 | HTTP      | 点餐对话       |
-| **5. 展示** | 绘制页面 | Rendering | 装修房子       |
+|------|----------|----------|----------|----------|
+| **1. 解析** | URL 解析 | 填写快递单 | 理解用户想访问哪里 | 协议、域名、端口、路径、参数 |
+| **2. 查询** | DNS 查询 | 查地址簿 | 把域名转换成 IP 地址 | 递归/迭代查询、缓存机制 |
+| **3. 连接** | TCP 握手 | 打电话确认 | 确保双方能可靠通信 | 三次握手、序列号、流量控制 |
+| **4. 对话** | HTTP 交换 | 快递员送达 | 请求和传输数据 | 请求方法、状态码、头部字段 |
+| **5. 展示** | 浏览器渲染 | 拆开包裹 | 把代码变成画面 | DOM、CSSOM、渲染树、布局、绘制 |
+
 **整个过程通常在几百毫秒内完成** —— 想想这有多么不可思议！
-现在，当你再次按下回车键时，你已经看到了屏幕背后的那个忙碌而精彩的数字世界。
+
+你的浏览器在不到1秒的时间里：
+- 解析了一个复杂的地址
+- 查询了分布在全球的 DNS 服务器
+- 和千里之外的服务器建立了可靠连接
+- 进行了一次完整的 HTTP 对话
+- 把枯燥的代码变成了精美的画面
+
+这就是互联网的魅力：**复杂的技术，简单的体验**。
+
+---
+
+## 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 | **往返时间**。数据包从发送到接收确认的时间，影响网页加载速度。 |
+
+---
+
+> **恭喜！** 现在当你再次在地址栏输入网址时，你已经能看到屏幕背后的那个忙碌而精彩的数字世界了。
+> **恭喜！** 现在当你再次在地址栏输入网址时，你已经能看到屏幕背后的那个忙碌而精彩的数字世界了。