-
-
-
- 1. 输入指令 (Input)
+ 1. 选择输入 (Select Input)
-
{{ selectedTask.icon }}
- ⬇️
-
-
-
-
- 2. 模型处理 (Processing)
- 计算中...
-
-
-
-
-
-
-
+大部分时候，你只需要掌握四种操作，江湖人称 **CRUD**：
+
+| 操作 | 英文 | SQL 关键字 | 类比 Excel |
+|------|------|------------|------------|
+| **C**reate | 创建/插入 | `INSERT` | 在末尾新增一行 |
+| **R**ead | 读取/查询 | `SELECT` | 筛选、查找 |
+| **U**pdate | 更新/修改 | `UPDATE` | 修改单元格内容 |
+| **D**elete | 删除 | `DELETE` | 删除一行 |
+
+### 3.2 实战示例：书店管理系统
+
+假设我们有以下两张表：
+
+**用户表 (users)**：
+
+| user_id | name | age | city |
+|---------|------|-----|------|
+| 1 | 张三 | 25 | 北京 |
+| 2 | 李四 | 30 | 上海 |
+| 3 | 王五 | 28 | 北京 |
+
+**图书表 (books)**：
+
+| book_id | title | price | stock |
+|---------|-------|-------|-------|
+| 101 | 百年孤独 | 59 | 100 |
+| 102 | 活着 | 39 | 50 |
+| 103 | 三体 | 99 | 200 |
+
+#### 查询数据 (Read)
+
+**示例 1**：查找所有年龄大于 25 岁的用户
+
+```sql
+SELECT name, age FROM users WHERE age > 25;
+```
+
+**逐词翻译**：
+- `SELECT name, age`：选择 name 和 age 这两列
+- `FROM users`：从 users 这张表
+- `WHERE age > 25`：在 age 大于 25 的条件下
+
+**返回结果**：
+
+| name | age |
+|------|-----|
+| 李四 | 30 |
+| 王五 | 28 |
+
+**示例 2**：查找价格在 40 到 100 之间的图书
+
+```sql
+SELECT title, price FROM books WHERE price BETWEEN 40 AND 100;
+```
+
+#### 插入数据 (Create)
+
+**示例**：新增一个用户
+
+```sql
+INSERT INTO users (user_id, name, age, city)
+VALUES (4, '赵六', 35, '广州');
+```
+
+**逐词翻译**：
+- `INSERT INTO users`：插入到 users 表
+- `(user_id, name, age, city)`：这几列
+- `VALUES (4, '赵六', 35, '广州')`：值分别是...
+
+#### 更新数据 (Update)
+
+**示例**：给所有北京的用户年龄加 1 岁
+
+```sql
+UPDATE users
+SET age = age + 1
+WHERE city = '北京';
+```
+
+**⚠️ 重要警告**：如果你忘记写 `WHERE city = '北京'`，这条命令会把**所有用户**的年龄都加 1！在生产环境中，这是一个极其危险的错误。
+
+#### 删除数据 (Delete)
+
+**示例**：删除用户 ID 为 4 的用户
+
+```sql
+DELETE FROM users WHERE user_id = 4;
+```
+
+**⚠️ 重要警告**：和 UPDATE 一样，如果忘记写 `WHERE`，你会删除整张表的所有数据！这在生产环境中是灾难性的。
+
+### 3.3 多表查询：JOIN 的力量
+
+还记得我们讲过的"关系"吗？SQL 最强大的地方在于可以一次性查询多张关联的表。
+
+**示例场景**：查询"张三购买过的所有图书"
+
+假设我们还有一张订单表 (orders)：
+
+| order_id | user_id | book_id | quantity |
+|----------|---------|---------|----------|
+| 1001 | 1 | 101 | 1 |
+| 1002 | 1 | 102 | 2 |
+| 1003 | 2 | 101 | 1 |
+
+**SQL 查询**：
+
+```sql
+SELECT u.name, b.title, o.quantity
+FROM orders o
+JOIN users u ON o.user_id = u.user_id
+JOIN books b ON o.book_id = b.book_id
+WHERE u.name = '张三';
+```
+
+**返回结果**：
+
+| name | title | quantity |
+|------|-------|----------|
+| 张三 | 百年孤独 | 1 |
+| 张三 | 活着 | 2 |
+
+通过 `JOIN`，我们把三张表的数据关联在了一起，得到了完整的答案。
+
+
-
+但现在，你手里有一本**字典**。字典有一个按字母排序的**索引**。
-::: tip 试一试
-在上面的演示中，点击 **“索引查找”**。你会发现查找次数极少。这就是为什么数据库能瞬间响应你的请求。
-:::
+你要找"数据库"这个词：
+1. 翻到"数"字开头的区域（快速定位）。
+2. 在"数"字区域内，按第二个字"据"的顺序找。
+3. 很快，你就定位到了"数据库"这个词所在的页码。
-### 4.2 底层数据结构：B+ 树
+这就是**索引查找**——不需要翻完整本书，只需要查索引，直接跳转到目标位置。
-真实数据库使用的索引结构叫 **B+ 树**。
-它像一棵倒过来的树，非常“矮胖”。
+### 4.2 全表扫描 vs 索引查找
-- **根节点**指引大方向。
-- **中间节点**指引小范围。
-- **叶子节点**存储真正的数据。
+让我们通过一个具体的例子来感受两者的差异。
-通常，一棵存储了 1 亿条数据的 B+ 树，高度只有 3 到 4 层。这意味着，数据库只需要读取 3 到 4 次磁盘，就能找到这 1 亿条数据中的任意一条！
+假设我们有一张用户表，里面有 1000 万条用户记录。
+
+**场景：查找 ID = 5,555,555 的用户**
+
+| 方式 | 过程 | 需要检查的行数 | 耗时（估算） |
+|------|------|----------------|--------------|
+| **全表扫描** | 从第 1 行开始，一行一行看，直到找到 ID = 5,555,555 | 平均 500 万行 | 数秒 ~ 数十秒 |
+| **索引查找** | 查索引树，直接跳到目标位置 | 约 3-4 次比较 | 数毫秒 |
+
+**速度差距**：数千倍甚至数万倍！
+
+
前馈神经网络 (FFN)
-
-
-
-
- 🔥 激活率: 100% (全员过载)
-
+
+
+
+
diff --git a/docs/.vitepress/theme/index.js b/docs/.vitepress/theme/index.js
index 6a48e2e..3a997b7 100644
--- a/docs/.vitepress/theme/index.js
+++ b/docs/.vitepress/theme/index.js
@@ -144,6 +144,11 @@ import GPTEvolutionDemo from './components/appendix/ai-history/GPTEvolutionDemo.
import ImperativeVsDeclarativeDemo from './components/appendix/web-basics/ImperativeVsDeclarativeDemo.vue'
import ComponentReusabilityDemo from './components/appendix/web-basics/ComponentReusabilityDemo.vue'
+// Frontend Evolution Components
+import EvolutionSliceRequestDemo from './components/appendix/frontend-evolution/SliceRequestDemo.vue'
+import EvolutionResponsiveGridDemo from './components/appendix/frontend-evolution/ResponsiveGridDemo.vue'
+import EvolutionJQueryVsStateDemo from './components/appendix/frontend-evolution/JQueryVsStateDemo.vue'
+
import BackendEvolutionDemo from './components/appendix/backend-evolution/BackendEvolutionDemo.vue'
import MonolithVsMicroserviceDemo from './components/appendix/backend-evolution/MonolithVsMicroserviceDemo.vue'
import CgiQueueDemo from './components/appendix/backend-evolution/CgiQueueDemo.vue'
@@ -154,6 +159,7 @@ import ServerlessCostAutoScaleDemo from './components/appendix/backend-evolution
// Frontend Performance Components
import PerformanceMetricsDemo from './components/appendix/frontend-performance/PerformanceMetricsDemo.vue'
+import PerformanceOverviewDemo from './components/appendix/frontend-performance/PerformanceOverviewDemo.vue'
import ReflowRepaintDemo from './components/appendix/frontend-performance/ReflowRepaintDemo.vue'
import ImageOptimizationDemo from './components/appendix/frontend-performance/ImageOptimizationDemo.vue'
import LazyLoadingDemo from './components/appendix/frontend-performance/LazyLoadingDemo.vue'
@@ -433,6 +439,11 @@ export default {
app.component('ImperativeVsDeclarativeDemo', ImperativeVsDeclarativeDemo)
app.component('ComponentReusabilityDemo', ComponentReusabilityDemo)
+ // Frontend Evolution Components Registration
+ app.component('EvolutionSliceRequestDemo', EvolutionSliceRequestDemo)
+ app.component('EvolutionResponsiveGridDemo', EvolutionResponsiveGridDemo)
+ app.component('EvolutionJQueryVsStateDemo', EvolutionJQueryVsStateDemo)
+
app.component('BackendEvolutionDemo', BackendEvolutionDemo)
app.component('MonolithVsMicroserviceDemo', MonolithVsMicroserviceDemo)
app.component('CgiQueueDemo', CgiQueueDemo)
@@ -441,8 +452,9 @@ export default {
app.component('CacheHitRatioDemo', CacheHitRatioDemo)
app.component('ServerlessCostAutoScaleDemo', ServerlessCostAutoScaleDemo)
- // Frontend Performance Components Registration
+ // Frontend Performance Components
app.component('PerformanceMetricsDemo', PerformanceMetricsDemo)
+ app.component('PerformanceOverviewDemo', PerformanceOverviewDemo)
app.component('ReflowRepaintDemo', ReflowRepaintDemo)
app.component('ImageOptimizationDemo', ImageOptimizationDemo)
app.component('LazyLoadingDemo', LazyLoadingDemo)
diff --git a/docs/ar-sa/stage-0/intro.md b/docs/ar-sa/stage-0/index.md
similarity index 100%
rename from docs/ar-sa/stage-0/intro.md
rename to docs/ar-sa/stage-0/index.md
diff --git a/docs/de-de/stage-0/intro.md b/docs/de-de/stage-0/index.md
similarity index 100%
rename from docs/de-de/stage-0/intro.md
rename to docs/de-de/stage-0/index.md
diff --git a/docs/en-us/stage-0/intro.md b/docs/en-us/stage-0/index.md
similarity index 100%
rename from docs/en-us/stage-0/intro.md
rename to docs/en-us/stage-0/index.md
diff --git a/docs/es-es/stage-0/intro.md b/docs/es-es/stage-0/index.md
similarity index 100%
rename from docs/es-es/stage-0/intro.md
rename to docs/es-es/stage-0/index.md
diff --git a/docs/fr-fr/stage-0/intro.md b/docs/fr-fr/stage-0/index.md
similarity index 100%
rename from docs/fr-fr/stage-0/intro.md
rename to docs/fr-fr/stage-0/index.md
diff --git a/docs/ja-jp/stage-0/intro.md b/docs/ja-jp/stage-0/index.md
similarity index 100%
rename from docs/ja-jp/stage-0/intro.md
rename to docs/ja-jp/stage-0/index.md
diff --git a/docs/ko-kr/stage-0/intro.md b/docs/ko-kr/stage-0/index.md
similarity index 100%
rename from docs/ko-kr/stage-0/intro.md
rename to docs/ko-kr/stage-0/index.md
diff --git a/docs/public/favicon.ico b/docs/public/favicon.ico
new file mode 100644
index 0000000..31f9efc
Binary files /dev/null and b/docs/public/favicon.ico differ
diff --git a/docs/vi-vn/stage-0/intro.md b/docs/vi-vn/stage-0/index.md
similarity index 100%
rename from docs/vi-vn/stage-0/intro.md
rename to docs/vi-vn/stage-0/index.md
diff --git a/docs/zh-cn/appendix/ai-evolution.md b/docs/zh-cn/appendix/ai-evolution.md
index f8cd6eb..49b9d41 100644
--- a/docs/zh-cn/appendix/ai-evolution.md
+++ b/docs/zh-cn/appendix/ai-evolution.md
@@ -49,6 +49,8 @@ function decideTrafficLight(color) {
return 'caution'
} else if (color === 'green') {
return 'go'
+ } else {
+ return 'unknown'
}
}
```
@@ -60,10 +62,10 @@ function decideTrafficLight(color) {
它的工作原理是：
```lisp
-;; MYCIN 系统的规则示例 (伪代码)
+// MYCIN 系统的规则示例 (伪代码)
(IF
- (organism IS gram-positive)
- (morphology IS coccus)
+ (organism IS gram-positive) AND
+ (morphology IS coccus) AND
(growth-chains IS chains)
THEN
(identity IS 0.7 streptococcus))
@@ -242,7 +244,7 @@ _数据示例 (训练数据格式)_：
- **黑盒问题**：虽然能识别猫，但我们说不清"它是怎么识别的"
- **数据饥渴**：需要海量标注数据，获取成本高
-- **缺乏常识**：能认猫，但不知道"猫会怕狗"
+- **缺乏常识**：能识别出这是“猫”，但理解不了“猫喜欢抓老鼠”或“猫通常怕狗”这种常识关系（因为它只是在做像素级的统计匹配，而非真正的概念理解）
---
diff --git a/docs/zh-cn/appendix/database-intro.md b/docs/zh-cn/appendix/database-intro.md
index bb56702..a76f91a 100644
--- a/docs/zh-cn/appendix/database-intro.md
+++ b/docs/zh-cn/appendix/database-intro.md
@@ -1,125 +1,430 @@
# 数据库原理入门：从 Excel 到 SQL
-> 💡 **学习指南**：本章节无需计算机专业背景。我们将从你熟悉的 Excel 表格开始，一步步带你理解数据库（Database）的核心原理，并揭示它为什么能从数十亿条数据中瞬间找到你想要的那一条。
+> 💡 **学习指南**：本章节无需编程基础，我们将从你熟悉的 Excel 表格出发，一步步深入数据库的底层原理。你会明白为什么数据库能从数十亿条数据中瞬间找到你想要的那一条，以及它背后那个神奇的 B+ 树是如何工作的。
-## 1. 数据的进化：为什么要用数据库？
+
+
-
-
+ Current Token:
+
+ {{ currentToken?.text || '...' }}
+
-
-
-
@@ -156,43 +167,54 @@ import { ref, computed } from 'vue'
const architecture = ref('moe')
const processing = ref(false)
-const currentStep = ref(0) // 0: idle, 1: router, 2: experts, 3: output
+const currentStep = ref('idle') // idle, router, expert
+const currentToken = ref(null)
+const generatedTokens = ref([])
const experts = [
- { icon: '💻', name: '代码专家', role: 'Python/JS/Rust' },
- { icon: '🎨', name: '创意专家', role: '诗歌/小说/绘画' },
- { icon: '📐', name: '逻辑专家', role: '数学/推理/证明' },
- { icon: '🌍', name: '语言专家', role: '翻译/润色/摘要' }
+ { icon: '💻', name: 'Code', color: '#059669' }, // Green
+ { icon: '📐', name: 'Math', color: '#2563eb' }, // Blue
+ { icon: '🎨', name: 'Creative', color: '#d97706' }, // Amber
+ { icon: '📝', name: 'Grammar', color: '#7c3aed' } // Purple
]
const tasks = [
{
- label: '写 Python 脚本',
- type: '编程',
+ label: 'Python 代码示例',
icon: '🐍',
- expertIdx: 0,
- output: 'def fib(n): return n if n < 2 else...'
+ tokens: [
+ { text: 'def', expert: 0 },
+ { text: ' calc', expert: 3 },
+ { text: '_area', expert: 0 },
+ { text: '(', expert: 3 },
+ { text: 'r', expert: 0 },
+ { text: '):', expert: 0 },
+ { text: '\n ', expert: 3 },
+ { text: 'return', expert: 0 },
+ { text: ' 3.14', expert: 1 }, // Math
+ { text: ' *', expert: 1 },
+ { text: ' r', expert: 0 },
+ { text: ' **', expert: 1 },
+ { text: ' 2', expert: 1 }
+ ]
},
{
- label: '写七言绝句',
- type: '文学',
- icon: '🌸',
- expertIdx: 1,
- output: '窗含西岭千秋雪，门泊东吴万里船...'
- },
- {
- label: '解二元方程',
- type: '数学',
- icon: '✖️',
- expertIdx: 2,
- output: 'x = 5, y = -2 (过程略)'
- },
- {
- label: '翻译成英文',
- type: '翻译',
- icon: '🔤',
- expertIdx: 3,
- output: 'To be, or not to be, that is the question.'
+ label: '科幻小说片段',
+ icon: '🚀',
+ tokens: [
+ { text: 'The', expert: 3 },
+ { text: ' spaceship', expert: 2 },
+ { text: ' warped', expert: 2 },
+ { text: ' into', expert: 3 },
+ { text: ' dimension', expert: 1 }, // Logic/Math concept
+ { text: ' X', expert: 2 },
+ { text: '.', expert: 3 },
+ { text: ' Coordinates', expert: 1 },
+ { text: ':', expert: 3 },
+ { text: ' 42', expert: 1 },
+ { text: '.', expert: 3 },
+ { text: '00', expert: 1 }
+ ]
}
]
@@ -211,33 +233,39 @@ const selectTask = (task) => {
}
const resetDemo = () => {
- currentStep.value = 0
+ currentStep.value = 'idle'
+ generatedTokens.value = []
+ currentToken.value = null
}
-const isExpertSelected = (idx) => {
- if (architecture.value === 'dense') return true // All active in dense
- return idx === selectedTask.value.expertIdx
+const getExpertColor = (expertIdx) => {
+ if (expertIdx === undefined || architecture.value === 'dense') return 'var(--vp-c-text-1)'
+ return experts[expertIdx].color
}
const runDemo = async () => {
if (processing.value) return
processing.value = true
- currentStep.value = 0
+ resetDemo()
- // Step 1: Input -> Router
- await wait(300)
- currentStep.value = 1
+ for (const token of selectedTask.value.tokens) {
+ currentToken.value = token
+
+ // Step 1: Router (MoE only) or Prep (Dense)
+ currentStep.value = 'router'
+ await wait(architecture.value === 'moe' ? 400 : 200)
- // Step 2: Router -> Expert / Dense Processing
- await wait(800)
- currentStep.value = 2
+ // Step 2: Expert Processing
+ currentStep.value = 'expert'
+ await wait(architecture.value === 'moe' ? 600 : 400) // Dense might be slower in reality, but for demo keep it brisk
- // Step 3: Expert -> Output
- await wait(1200)
- currentStep.value = 3
+ // Step 3: Output
+ generatedTokens.value.push(token)
+ await wait(200)
+ }
- // Finish
- await wait(500)
+ currentStep.value = 'idle'
+ currentToken.value = null
processing.value = false
}
@@ -246,8 +274,7 @@ const wait = (ms) => new Promise((resolve) => setTimeout(resolve, ms))
+
\ No newline at end of file
diff --git a/docs/.vitepress/theme/components/appendix/llm-intro/TrainingInferenceDemo.vue b/docs/.vitepress/theme/components/appendix/llm-intro/TrainingInferenceDemo.vue
index 6eb4c29..c1ffbe8 100644
--- a/docs/.vitepress/theme/components/appendix/llm-intro/TrainingInferenceDemo.vue
+++ b/docs/.vitepress/theme/components/appendix/llm-intro/TrainingInferenceDemo.vue
@@ -238,8 +238,8 @@
>
{{
isPredictionCorrect
- ? '✅ Parameters Good'
- : '❌ Update Weights'
+ ? '✅ Good Prediction'
+ : '🔧 Adjusting Weights'
}}
门控路由 (Router)
-
- 🔍 识别意图: "{{ selectedTask.type }}"
-
+
+
+
-
-
+ 2. 模型处理 (Processing)
+ 生成中...
-
-
+
+
-
-
-
-
-
+
+
+
-
-
+ {{ expert.name }}
- {{ expert.role }}
+ Dense FFN Layers
+
+
+
+
+ 🔥 激活率: 100% (All Parameters)
+
+
+
+
+
+
+
+ Router (Token 分发)
+
+ Routing "{{ currentToken.text.trim() }}" → {{ experts[currentToken.expert].name }}
+
+
+
+
+
+
+
- ✅ 激活
+
+
{{ expert.name }}
+
+ ⚡ Active
+
⬇️
-
-
@@ -145,7 +156,7 @@
3. 生成结果 (Output)
-
-
-
- {{ selectedTask.output }}
-
- 等待处理...
+ 3. 逐步生成 (Output Stream)
+
+
+ {{ token.text }}
+ |
+
+
点击运行查看生成过程...
${i}
`
-}
-```
+### 2.3 避坑指南：重排 (Reflow) 与重绘 (Repaint)
-**优化**：
+在这个流程中，最累人的步骤是 **Layout (排版)**。
-```javascript
-// 使用文档片段，只触发一次重排
-const fragment = document.createDocumentFragment()
-for (let i = 0; i < 1000; i++) {
- const div = document.createElement('div')
- div.textContent = i
- fragment.appendChild(div)
-}
-document.body.appendChild(fragment)
-```
-
-**使用虚拟 DOM**：
-
-- Vue、React 使用虚拟 DOM 减少真实 DOM 操作
-- 批量更新，减少重排次数
-
-### 3.3 CSS 优化
-
-**减少 CSS 大小**：
-
-- 移除未使用的 CSS（使用 PurgeCSS）
-- 压缩 CSS（移除空格、注释）
-
-**优化 CSS 选择器**：
-
-```css
-/* 慢：从右向左匹配 */
-.container div ul li a {
-}
-
-/* 快：使用类选择器 */
-.link {
-}
-```
-
-**关键 CSS 内联**：
-
-- 把首屏需要的 CSS 内联到 HTML
-- 减少渲染阻塞
-
-```html
-
-```
-
-### 3.4 重排与重绘
+- **重排 (Reflow)**：如果你改变了元素的大小或位置，浏览器通过重新计算所有元素的位置。这就像因为桌子移了一下，整个餐厅的椅子都要重新摆一遍。**非常消耗性能！**
+- **重绘 (Repaint)**：如果你只是改变了颜色，浏览器只需要重新上色。这就像给桌布换个颜色，简单多了。
`，浏览器的内存会瞬间爆炸，渲染树会变得巨大无比，每动一下都会卡死。
+这就好比餐厅里只有 10 张桌子，你却非要一次性接待 10,000 个客人，结果就是谁也吃不上饭。
+
+### 3.2 解决方案：虚拟列表 (Virtual Scrolling)
+
+聪明的工程师想出了**虚拟列表**。
+它的核心思想是：**欺骗眼睛**。
+
+既然屏幕只能显示 10 条数据，那我就只渲染这 10 条（加上前后一点缓冲）。当用户滚动时，我快速地把移出屏幕的 DOM 销毁，把新进入屏幕的数据填进去。
+用户感觉他在滚一个无限长的列表，但实际上浏览器里永远只有几十个 DOM 节点。
+
+
- 
-
-```
-
-### 5.2 响应式图片
-
-**根据屏幕尺寸加载不同尺寸的图片**：
-
-```html
-
-```
-
-**解释**：
-
-- `srcset`：定义不同尺寸的图片
-- `sizes`：告诉浏览器图片在不同屏幕上的显示尺寸
-- 浏览器自动选择最合适的图片
-
-### 5.3 懒加载
-
-
-
-```
-
-**解释**：
-
-- `srcset`：定义不同尺寸的图片
-- `sizes`：告诉浏览器图片在不同屏幕上的显示尺寸
-- 浏览器自动选择最合适的图片
-
-### 5.3 懒加载
-
-
-```
-
-**方法 2：使用 Intersection Observer**：
-
-```javascript
-const observer = new IntersectionObserver((entries) => {
- entries.forEach((entry) => {
- if (entry.isIntersecting) {
- const img = entry.target
- img.src = img.dataset.src
- observer.unobserve(img)
- }
- })
-})
-
-document.querySelectorAll('img[data-src]').forEach((img) => {
- observer.observe(img)
-})
-```
-
-### 5.4 压缩与裁剪
+### 5.3 压缩与裁剪
**使用工具压缩图片**：
@@ -782,74 +468,39 @@ export default defineConfig({
## 9. 实战案例
-### 9.1 案例 1：优化一个慢页面
+### 9.1 案例 1：新闻列表页优化
-**问题**：一个电商商品页加载需要 8 秒
+**问题**：首屏加载慢，滚动卡顿
-**诊断**：
+**优化**：
-- 图片总和：3 MB
-- JavaScript：1.2 MB
-- CSS：400 KB
-- 45 个资源请求
+1. **图片**：WebP + 懒加载
+2. **列表**：虚拟列表（只渲染可见的 10 项）
+3. **数据**：分页加载
-**优化措施**：
+**结果**：LCP 2.5s -> 0.8s
-1. 压缩图片 → 减少 60%（1.2 MB）
-2. 使用 WebP → 再减少 30%（800 KB）
-3. 图片懒加载 → 首屏只加载 3 张图
-4. 代码分割 → 首屏 JS 减少到 300 KB
-5. 启用 Gzip → CSS 减少到 150 KB
+### 9.2 案例 2：数据可视化大屏
-**结果**：
+**问题**：渲染大量节点卡死
-- 首屏时间：8 秒 → 1.8 秒（减少 77%）
-- Lighthouse 性能评分：35 → 92
+**优化**：
-### 9.2 案例 2：大型应用的性能优化
+1. **渲染**：Canvas 代替 DOM
+2. **计算**：Web Worker 处理数据
-**问题**：单页应用（SPA）首次加载慢
+**结果**：FPS 10 -> 60
-**优化策略**：
+### 9.3 案例 3：移动端活动页
-1. **路由懒加载**：每个路由单独打包
-2. **组件懒加载**：非首屏组件延迟加载
-3. **虚拟列表**：长列表只渲染可见部分
-4. **预加载下一页**：用户可能访问的页面预加载
-5. **SSR（服务端渲染）**：首屏由服务器渲染
+**问题**：白屏时间长
-**技术选型**：
+**优化**：
-- 使用 **Vite**（快速构建）
-- 使用 **Vue 3**（更好的性能）
-- 使用 **Pinia**（轻量状态管理）
-- 使用 **Vant**（按需引入的 UI 组件库）
+1. **资源**：预加载 (Preload) 关键图
+2. **体验**：骨架屏 (Skeleton)
-**结果**：
-
-- 首屏加载时间：4.5 秒 → 1.2 秒
-- Time to Interactive：6 秒 → 1.8 秒
-
-### 9.3 案例 3：移动端性能优化
-
-**移动端特殊挑战**：
-
-- CPU 性能弱
-- 网络慢
-- 内存有限
-
-**优化措施**：
-
-1. **减少动画**：使用 CSS 动画代替 JS 动画
-2. **触摸优化**：避免 `click` 延迟，使用 `touchstart`
-3. **减少重排**：使用 `transform` 代替 `top/left`
-4. **减少资源**：移动端加载更小的图片
-5. **PWA**：支持离线访问，提供类原生体验
-
-**结果**：
-
-- 移动端评分：45 → 95
-- 用户留存率提升：+30%
+**结果**：白屏减少 60%
---
@@ -863,69 +514,46 @@ export default defineConfig({
- ✅ 使用 CDN 加速静态资源
- ✅ 实施代码分割和懒加载
- ✅ 压缩和优化图片
-- ✅ 使用 WebP/AVIF 格式
**渲染优化**：
- ✅ 减少重排和重绘
-- ✅ 使用 CSS 动画（transform、opacity）
- ✅ 优化关键渲染路径
-- ✅ 内联关键 CSS
+- ✅ 使用 CSS 动画代替 JS 动画
-**JavaScript 优化**：
+**执行优化**：
-- ✅ 压缩和 Tree Shaking
-- ✅ 避免长任务（时间切片）
-- ✅ 使用 Web Workers
-- ✅ 防抖和节流
+- ✅ 使用 Web Workers 处理重计算
+- ✅ 避免长任务（Long Tasks）
+- ✅ 合理使用防抖和节流
**缓存优化**：
-- ✅ 配置 HTTP 缓存
-- ✅ 使用 Service Worker
-- ✅ 合理使用 LocalStorage
+- ✅ 配置 HTTP 强缓存和协商缓存
+- ✅ 考虑使用 Service Worker
-**监控优化**：
+### 10.2 持续学习
-- ✅ 设置性能预算
-- ✅ 使用 RUM 和合成监控
-- ✅ 定期审计性能
-
-### 10.2 性能优化原则
-
-1. **测量优先**：先测量，再优化
-2. **抓大放小**：先优化最大的瓶颈
-3. **用户体验第一**：关注真实用户感受
-4. **持续改进**：性能优化是持续的过程
-5. **团队协作**：让整个团队都关注性能
-
-### 10.3 常见陷阱
-
-- ❌ 过早优化：没有测量就开始优化
-- ❌ 过度优化：为了优化而优化，得不偿失
-- ❌ 只关注分数：Lighthouse 分数高不代表用户体验好
-- ❌ 忽视移动端：移动端性能更重要
-- ❌ 一次性优化：性能需要持续监控和改进
-
-### 10.4 学习资源
-
-**工具**：
-
-- [Lighthouse](https://developers.google.com/web/tools/lighthouse)
-- [WebPageTest](https://www.webpagetest.org)
-- [PageSpeed Insights](https://pagespeed.web.dev)
-
-**文档**：
-
-- [Web.dev Performance](https://web.dev/performance/)
-- [MDN Performance](https://developer.mozilla.org/en-US/docs/Web/Performance)
-
-**书籍**：
-
-- 《高性能网站建设指南》
-- 《高性能网站建设进阶指南》
-- 《Web 性能权威指南》
+前端性能优化是一个不断发展的领域，新的标准（如 INP）和新的工具（如 Vite, Turbopack）层出不穷。保持好奇心，多看 Performance 面板，是你最好的老师。
---
-**记住**：性能优化不是炫技，而是为用户创造价值。快的体验就是好的体验。
+## 11. 名词速查表 (Glossary)
+
+| 名词 | 全称 | 解释 |
+| :--- | :--- | :--- |
+| **FP / FCP** | First Paint / First Contentful Paint | **首屏时间**。用户看到页面第一个像素/第一块内容的时间。 |
+| **LCP** | Largest Contentful Paint | **最大内容绘制**。页面主要内容加载完成的时间（衡量加载速度的核心指标）。 |
+| **INP** | Interaction to Next Paint | **交互到下一次绘制**。衡量页面响应速度的新指标（替代 FID），关注点击后的反馈延迟。 |
+| **CLS** | Cumulative Layout Shift | **累积布局偏移**。页面加载时元素乱跳的程度（衡量视觉稳定性）。 |
+| **TTFB** | Time to First Byte | **首字节时间**。从发出请求到接收到服务器第一个字节的时间（衡量后端响应速度）。 |
+| **TBT** | Total Blocking Time | **总阻塞时间**。主线程被长任务阻塞的总时间（衡量页面交互流畅度）。 |
+| **Reflow** | Reflow (Layout) | **重排**。浏览器重新计算元素位置和大小的过程。成本高，应避免。 |
+| **Repaint** | Repaint | **重绘**。浏览器重新绘制元素外观（如颜色）的过程。成本中等。 |
+| **CDN** | Content Delivery Network | **内容分发网络**。把文件存在离用户最近的服务器上，加速下载。 |
+| **SSR** | Server-Side Rendering | **服务端渲染**。在服务器端生成 HTML，加快首屏显示，利于 SEO。 |
+| **CSR** | Client-Side Rendering | **客户端渲染**。在浏览器端通过 JS 生成 HTML，交互体验好，但首屏慢。 |
+| **SSG** | Static Site Generation | **静态站点生成**。构建时生成静态 HTML，访问速度极快。 |
+| **Tree Shaking** | Tree Shaking | **摇树优化**。构建时移除未使用的代码，减小包体积。 |
+| **Code Splitting** | Code Splitting | **代码分割**。将代码拆分成小块，按需加载。 |
+| **Preload / Prefetch** | Preload / Prefetch | **预加载/预获取**。提前告知浏览器加载关键资源或未来可能用到的资源。 |
diff --git a/docs/zh-cn/appendix/llm-intro.md b/docs/zh-cn/appendix/llm-intro.md
index ca4d079..6a5df75 100644
--- a/docs/zh-cn/appendix/llm-intro.md
+++ b/docs/zh-cn/appendix/llm-intro.md
@@ -39,11 +39,41 @@
它就像是一个翻译官，负责将人类的文字翻译成机器能读懂的数字序列。
现代 LLM (如 GPT-4) 通常使用 **Subword Tokenization (子词分词)** 技术（如 BPE 算法）。
-它的聪明之处在于：
+它的聪明之处在于：**常用词保持完整，生僻词拆分**。
-- **常用词**（如 "apple"）保持完整，作为一个 Token。
-- **生僻词**（如 "applepie"）拆分成常见片段（"apple" + "pie"）。
- 这样既能覆盖所有词汇，又不会让词表变得无限大。
+以下是一个真实的 BPE 分词示例（基于 GPT-4 Tokenizer）：
+
+**Input**: `"The quick brown fox jumps over the lazy dog. \n今天天气真不错！"`
+
+**Token List**:
+
+```text
+index=791, string='The'
+index=4062, string=' quick'
+index=14198, string=' brown'
+index=39935, string=' fox'
+index=83368, string=' jumps' <-- 如果被拆分，可能会是 ' jump' + 's'
+index=927, string=' over'
+index=279, string=' the'
+index=16053, string=' lazy'
+index=3290, string=' dog'
+index=13, string='.'
+index=198, string='\n' <-- 换行符
+index=33838, string='今天' <-- 常用词直接合并
+index=54580, string='天气'
+index=20265, string='真'
+index=57672, string='不错'
+index=171, string='！'
+```
+
+> **关于生僻字的处理**：
+> 如果遇到词表中不存在的生僻字（假设“今”字很生僻），模型会回退到 **Byte 级别** 进行编码。
+> 1. Raw Input: `今`
+> 2. Bytes: `\xE4 \xBB \x8A`
+> 3. BPE 查找: 先找 `\xE4\xBB\x8A` -> 没找到 -> 拆分为 `\xE4\xBB` (ID=1001) + `\x8A` (ID=2002)。
+> 4. 最终 Token: `[1001, 2002]`。
+>
+> 这种机制保证了**无论输入什么字符，模型都能处理，永远不会出现 OOV (Out Of Vocabulary) 问题**。