feat(docs): update computer fundamentals content and demos

- Refactor frontend framework demo descriptions for clarity - Remove interactive features from triad and field map demos - Add new computer organization and DSL documentation links - Split type systems and compilers into separate pages - Enhance power-on-to-web article with relay race analogy - Add new interactive demos for type systems and compilation - Improve visual presentation of boot process and hardware flow - Introduce new Vibe Coding flow demo component
2026-02-25 01:38:27 +08:00
parent 3af119a598
commit f44c842fe7
41 changed files with 7721 additions and 1290 deletions
@@ -0,0 +1,255 @@
+# 编译原理入门
+
+::: tip 前言
+**当你按下"运行"按钮，代码是怎么变成屏幕上的结果的？** 你写的每一行代码，计算机其实都"看不懂"——它只认识 0 和 1。编译器就是那个把人类语言翻译成机器语言的"翻译官"。理解编译原理，你就能理解报错信息从哪来、为什么有些语言快有些慢、以及代码优化的底层逻辑。
+:::
+
+**这篇文章会带你学什么？**
+
+学完这章后，你将获得：
+
+- **全局视野**：掌握从源代码到可执行程序的完整编译流水线
+- **词法分析**：理解编译器如何把代码拆成一个个 Token
+- **语法分析**：理解 AST（抽象语法树）的构建过程
+- **AST 可视化**：直观看到代码的树形结构
+- **语义分析与优化**：理解类型检查和代码优化的原理
+- **优化技术实战**：掌握常量折叠、死代码消除等核心优化手段
+- **执行模型**：区分编译型、解释型和 JIT 三种执行方式
+
+| 章节 | 内容 | 核心概念 |
+|-----|------|---------|
+| **第 1 章** | 编译器是什么 | 翻译官类比、编译流水线 |
+| **第 2 章** | 词法分析 | Token、词法规则 |
+| **第 3 章** | 语法分析 | AST、语法树、优先级 |
+| **第 4 章** | AST 可视化 | 交互式语法树、节点类型 |
+| **第 5 章** | 语义分析与优化 | 类型检查、常量折叠、死代码消除 |
+| **第 6 章** | 优化技术实战 | 函数内联、循环外提、常量传播 |
+| **第 7 章** | 编译型 vs 解释型 vs JIT | 三种执行模型对比 |
+
+---
+
+## 0. 全景图：代码的"翻译之旅"
+
+想象你是一个翻译官，要把一本中文小说翻译成英文。你不会一个字一个字地直译，而是：
+
+1. **识别词语** — 把句子拆成一个个词（词法分析）
+2. **理解句法** — 判断句子结构是否正确（语法分析）
+3. **理解语义** — 确保意思通顺、没有矛盾（语义分析）
+4. **润色优化** — 让译文更地道流畅（代码优化）
+5. **输出译文** — 写出最终的英文版本（代码生成）
+
+编译器做的事情完全一样，只不过它翻译的是编程语言。
+
+<CompilerAnalogyDemo />
+
+---
+
+## 1. 编译器的六步流水线
+
+编译器的工作可以分为六个阶段，像工厂流水线一样，每个阶段处理完交给下一个阶段。
+
+<CompilerDemo />
+
+::: tip 编译流水线
+1. **词法分析（Lexical Analysis）**：把源代码拆成一个个 Token（单词）
+2. **语法分析（Syntax Analysis）**：把 Token 组织成语法树（AST）
+3. **语义分析（Semantic Analysis）**：检查类型是否正确、变量是否声明
+4. **中间代码生成（IR Generation）**：生成与平台无关的中间表示
+5. **代码优化（Optimization）**：让中间代码更高效
+6. **代码生成（Code Generation）**：生成目标平台的机器码
+:::
+
+| 阶段 | 输入 | 输出 | 类比 |
+|------|------|------|------|
+| 词法分析 | 源代码字符流 | Token 流 | 把句子拆成单词 |
+| 语法分析 | Token 流 | AST（语法树） | 分析句子结构 |
+| 语义分析 | AST | 带类型的 AST | 检查意思是否通顺 |
+| 中间代码 | 带类型的 AST | IR | 写出初稿 |
+| 代码优化 | IR | 优化后的 IR | 润色删减 |
+| 代码生成 | 优化后的 IR | 机器码 | 输出终稿 |
+
+---
+
+## 2. 词法分析：把代码拆成"单词"
+
+词法分析是编译的第一步。编译器从左到右扫描源代码的每个字符，把它们组合成有意义的**Token（词法单元）**。
+
+<LexerTokenDemo />
+
+就像读英文句子时，你的大脑会自动把字母组合成单词一样，词法分析器把字符组合成 Token：
+
+```
+源代码: let x = 10 + 5;
+
+Token 流:
+[let]   → 关键字（语言保留字）
+[x]     → 标识符（变量名）
+[=]     → 运算符（赋值）
+[10]    → 数字字面量
+[+]     → 运算符（加法）
+[5]     → 数字字面量
+[;]     → 分隔符（语句结束）
+```
+
+::: tip Token 的五大类型
+- **关键字**：语言保留的特殊单词，如 `let`、`if`、`return`、`function`
+- **标识符**：程序员定义的名字，如变量名、函数名
+- **字面量**：直接写在代码里的值，如数字 `42`、字符串 `"hello"`
+- **运算符**：执行运算的符号，如 `+`、`-`、`=`、`===`
+- **分隔符**：分隔代码结构的符号，如 `;`、`,`、`(`、`)`
+:::
+
+---
+
+## 3. 语法分析：构建语法树（AST）
+
+词法分析把代码拆成了 Token，但 Token 只是一个个孤立的"单词"。语法分析的任务是把这些 Token 按照语法规则组织成一棵**抽象语法树（Abstract Syntax Tree, AST）**——它反映了代码的结构和运算优先级。
+
+```
+表达式: 1 + 2 * 3
+
+语法树:        为什么这样？
+       +       因为 * 的优先级
+      / \      高于 +，所以
+     1   *     2 * 3 先结合
+        / \    成为一个子树
+       2   3
+```
+
+::: tip AST 的重要性
+AST 是编译器的"核心数据结构"，后续的语义分析、优化、代码生成都基于它进行。现代开发工具也大量使用 AST：
+- **ESLint**：解析代码为 AST，检查是否违反规则
+- **Prettier**：解析为 AST 后重新格式化输出
+- **Babel**：解析 AST → 转换 → 生成兼容代码
+- **IDE 重构**：基于 AST 进行安全的变量重命名、函数提取
+:::
+
+| 语法结构 | Token 序列 | AST 节点 |
+|---------|-----------|---------|
+| 变量声明 | `let` `x` `=` `10` | VariableDeclaration → Identifier + Literal |
+| 函数调用 | `add` `(` `1` `,` `2` `)` | CallExpression → Identifier + Arguments |
+| 条件语句 | `if` `(` `a` `>` `b` `)` | IfStatement → BinaryExpression + Block |
+
+---
+
+## 4. AST 可视化：看见代码的"骨架"
+
+上面我们用文字描述了 AST 的结构，但"看到"比"读到"更直观。下面的交互组件让你选择不同的表达式，实时观察它们的语法树长什么样。
+
+<ASTVisualizerDemo />
+
+通过可视化你会发现，AST 的核心规律其实很简单：
+
+| 代码结构 | AST 根节点 | 子节点 |
+|---------|-----------|-------|
+| `1 + 2 * 3` | BinaryExpression (+) | 左: NumericLiteral(1)，右: BinaryExpression(*) |
+| `let x = 10` | VariableDeclaration | VariableDeclarator → Identifier(x) + NumericLiteral(10) |
+| `add(a, b)` | CallExpression | Identifier(add) + Arguments(a, b) |
+
+::: tip AST 在日常开发中的应用
+你可能没直接写过编译器，但你每天都在用基于 AST 的工具：
+- **ESLint / Prettier**：解析代码为 AST，检查规则或重新格式化
+- **Babel / SWC**：解析 AST → 转换语法 → 生成兼容代码
+- **IDE 重构**：基于 AST 做安全的重命名、提取函数
+- **Tree-shaking**：分析 AST 中的 import/export，删除未使用的代码
+:::
+
+---
+
+## 5. 语义分析与代码优化
+
+语法分析确保代码"结构正确"，但结构正确不代表"意思正确"。语义分析负责检查代码的含义是否合法，代码优化则让程序跑得更快。
+
+<CompilationPracticeDemo />
+
+### 4.1 语义分析：检查"意思"对不对
+
+| 检查内容 | 示例 | 结果 |
+|---------|------|------|
+| 类型检查 | `int x = "hello"` | ❌ 类型不匹配 |
+| 作用域检查 | 使用未声明的变量 `y` | ❌ 变量不存在 |
+| 类型推断 | `1 + 2.0` | ✅ 推断结果为 float |
+| 参数检查 | `add(1, 2, 3)` 但函数只接受 2 个参数 | ❌ 参数数量不匹配 |
+
+::: tip 你见过的报错，大多来自语义分析
+- `TypeError: Cannot read properties of undefined` — 类型检查
+- `ReferenceError: x is not defined` — 作用域检查
+- `Expected 2 arguments, but got 3` — 参数检查
+:::
+
+### 4.2 代码优化：让程序更快
+
+编译器在生成最终代码前，会对中间代码做各种优化。这些优化对程序员透明，但能显著提升性能。
+
+| 优化技术 | 优化前 | 优化后 | 原理 |
+|---------|-------|-------|------|
+| 常量折叠 | `x = 10 + 5` | `x = 15` | 编译时直接算出结果 |
+| 死代码消除 | `if (false) { ... }` | 直接删除 | 永远不会执行的代码 |
+| 常量传播 | `x = 15; y = x * 2` | `y = 30` | 已知值直接替换 |
+| 循环不变量外提 | 循环内重复计算 `len = arr.length` | 提到循环外 | 避免重复计算 |
+
+---
+
+## 6. 优化技术实战：编译器如何让代码更快
+
+上面我们提到了几种优化技术的名字，现在来深入看看编译器具体是怎么做的。下面的交互组件展示了 5 种最常见的编译器优化，你可以直观对比优化前后的代码差异。
+
+<CodeOptimizationDemo />
+
+现代编译器和 JIT 引擎（如 V8、GCC、LLVM）会自动应用数十种优化。作为开发者，你不需要手动做这些优化，但理解它们能帮你：
+
+- **写出更容易被优化的代码**：比如用 `const` 而不是 `let`，编译器更容易做常量折叠
+- **理解性能差异**：为什么小函数比大函数快？因为编译器能内联它们
+- **避免"反优化"**：某些写法会阻止编译器优化，比如 `eval()` 和 `with`
+
+| 优化技术 | 触发条件 | 性能影响 | 开发者能做什么 |
+|---------|---------|---------|-------------|
+| 常量折叠 | 表达式中全是常量 | 消除运行时计算 | 多用 const 声明 |
+| 死代码消除 | 代码不可达或结果未使用 | 减小代码体积 | 及时清理无用代码 |
+| 循环不变量外提 | 循环内有不变的计算 | 减少重复计算 | 手动提取也是好习惯 |
+| 函数内联 | 小函数被频繁调用 | 消除调用开销 | 保持函数小而专注 |
+| 常量传播 | 变量值在编译时可确定 | 整条计算链被消除 | 用常量代替魔法数字 |
+
+---
+
+## 7. 编译型 vs 解释型 vs JIT
+
+代码写完后，有三种"翻译方式"让它运行起来。这三种方式各有优劣，直接决定了语言的性能特征和使用场景。
+
+<CompileVsInterpretDemo />
+
+| 维度 | 编译型 | 解释型 | JIT 即时编译 |
+|------|-------|-------|------------|
+| 过程 | 先全量编译成机器码，再执行 | 边读边执行，逐行翻译 | 先解释执行，热点代码再编译 |
+| 运行速度 | 最快 | 最慢 | 中等（热点接近编译型） |
+| 启动速度 | 慢（需要编译） | 快（直接运行） | 中等（需要预热） |
+| 跨平台 | 需要重新编译 | 天然跨平台 | 跨平台 |
+| 代表语言 | C, Rust, Go | Python, Ruby | JavaScript (V8), Java |
+
+::: tip 为什么 JavaScript 这么快？
+V8 引擎的 JIT 编译器会监测哪些代码被频繁执行（热点代码），然后把它们编译成高度优化的机器码。所以虽然 JavaScript 是"解释型语言"，但在 V8 中它的性能可以接近编译型语言。这也是 Node.js 能做服务端的底气。
+:::
+
+---
+
+## 总结
+
+编译原理不是只有编译器开发者才需要了解的知识。理解编译流程，能帮你更好地理解报错信息、选择合适的语言、写出更高效的代码。
+
+回顾本章的关键要点：
+
+1. **编译器是翻译官**：把人类可读的代码翻译成机器可执行的指令
+2. **六步流水线**：词法分析 → 语法分析 → 语义分析 → 中间代码 → 优化 → 代码生成
+3. **词法分析拆 Token**：把字符流拆成关键字、标识符、运算符等有意义的单元
+4. **语法分析建 AST**：按语法规则把 Token 组织成树形结构，反映运算优先级
+5. **语义分析保正确**：类型检查、作用域检查，你见过的大多数报错都来自这里
+6. **编译器自动优化**：常量折叠、死代码消除、函数内联等技术让代码自动变快
+7. **三种执行模型**：编译型最快、解释型最灵活、JIT 兼顾两者
+
+## 延伸阅读
+
+- [AST Explorer](https://astexplorer.net/) - 在线查看代码的 AST 结构
+- [Crafting Interpreters](https://craftinginterpreters.com/) - 从零实现一门编程语言（免费在线书）
+- [The Super Tiny Compiler](https://github.com/jamiebuilds/the-super-tiny-compiler) - 用 JavaScript 实现的超小编译器
+- [V8 Blog](https://v8.dev/blog) - V8 引擎的 JIT 编译技术博客
+- [LLVM 官网](https://llvm.org/) - 最流行的编译器基础设施
@@ -0,0 +1,485 @@
+# 计算机组成原理
+
+::: tip 前言
+**从晶体管到 CPU 后，计算机如何组成完整系统？** 上一章我们从晶体管出发，构建了加法器、寄存器、运算单元，最终拼出了 CPU 核心。但仅有 CPU 是不够的——它需要和内存、I/O 设备协同工作，需要总线连接各个部件，需要指令系统来驱动。这一章我们将从 CPU 的内部视角转向整个计算机系统的视角，深入理解冯诺依曼架构、指令系统、存储层次、总线与 I/O 的专业原理。
+:::
+
+**这篇文章会带你学什么？**
+
+学完这章后，你将获得：
+
+- **系统视角**：理解 CPU、内存、I/O 是如何协同工作的不再是孤立的硬件爱好者
+- **硬件专业术语**：掌握指令周期、流水线、CPI、缓存命中率等硬核概念
+- **性能思维**：理解计算机组成中的瓶颈与优化手段
+- **后续学习基础**：为操作系统、体系结构、嵌入式开发打下专业基础
+
+| 章节 | 内容 | 核心概念 |
+|-----|------|---------|
+| **第 1 章** | 冯诺依曼架构 | 存储程序、五大组成部件、数据通路 |
+| **第 2 章** | 指令系统 | 指令格式、寻址方式、CISC vs RISC |
+| **第 3 章** | CPU 控制器 | 控制单元、微操作、指令周期 |
+| **第 4 章** | 存储体系 | 缓存、主存、虚拟内存、分页机制 |
+| **第 5 章** | 总线与 I/O | 总线仲裁、DMA、中断机制 |
+
+---
+
+## 0. 全景图：计算机硬件系统
+
+在上一章"从晶体管到 CPU"中，我们已经理解了 CPU 内部是如何工作的——从取指、译码、执行到写回。但 CPU 本身只是一个执行单元，要让计算机真正"能用"，还需要一系列外围部件的配合。
+
+<CpuArchitectureDemo />
+
+::: tip 逐层解构：计算机硬件系统
+- **第一层：CPU 核心**
+  负责指令执行，包括控制单元（发出控制信号）和运算单元（执行算术逻辑运算）
+
+- **第二层：寄存器组**
+  CPU 内部的高速存储单元，包括通用寄存器和专用寄存器（PC、IR、MAR、MDR 等）
+
+- **第三层：主存储器**
+  用于存放程序和数据的内存，CPU 通过地址总线和数据总线访问
+
+- **第四层：I/O 设备**
+  输入输出设备通过 I/O 控制器与系统总线相连
+
+- **第五层：系统总线**
+  连接 CPU、内存、I/O 的数据通道，包括地址总线、数据总线、控制总线
+:::
+
+---
+
+## 1. 冯诺依曼架构：现代计算机的"宪法"
+
+### 1.1 存储程序原理
+
+1945 年，数学家约翰·冯·诺依曼（John von Neumann）提出了划时代的**存储程序（Stored-program）**架构思想。这一思想奠定了现代计算机的基础。
+
+::: tip 核心概念
+**存储程序**：程序本身作为一种特殊的数据，和普通数据一样存储在内存中。CPU 可以像读写数据一样读取并执行存储在内存中的程序指令。
+:::
+
+这意味着：
+- **早期计算机**：程序是固定布线实现的，改变程序需要重新焊接电路
+- **冯诺依曼架构**：程序存储在内存中，改变程序只需修改内存内容
+
+### 1.2 五大组成部件
+
+冯诺依曼架构将计算机划分为五个核心组成部分：
+
+<RegisterDemo />
+
+| 部件 | 英文 | 功能 | 主要组成 |
+|------|------|------|---------|
+| **运算器** | ALU (Arithmetic Logic Unit) | 执行算术和逻辑运算 | 加法器、移位器、比较器 |
+| **控制器** | CU (Control Unit) | 指挥协调各部件工作 | 指令寄存器、译码器、时序发生器 |
+| **存储器** | Memory | 存储程序和数据 | 内存地址寄存器(MAR)、内存数据寄存器(MDR) |
+| **输入设备** | Input | 信息输入 | 键盘、鼠标、扫描仪 |
+| **输出设备** | Output | 信息输出 | 显示器、打印机 |
+
+### 1.3 数据通路
+
+**数据通路（Data Path）**是数据在各个功能部件之间流动的路径。在 CPU 内部，数据通路连接了：
+
+- 寄存器组
+- 算术逻辑单元(ALU)
+- 内存数据寄存器(MDR)
+
+数据通路的宽度（一次能传输多少位）直接影响了计算机的性能。
+
+### 1.4 冯诺依曼瓶颈
+
+冯诺依曼架构有一个著名的**性能瓶颈**：
+
+> CPU 与内存之间的数据传输速度，远低于 CPU 的处理速度。
+
+这导致 CPU 经常处于"等待数据"的空闲状态。现代计算机的很多优化技术都是围绕这个问题展开的：
+
+| 优化技术 | 原理 |
+|---------|------|
+| **缓存(Cache)** | 在 CPU 附近放置小容量高速存储 |
+| **指令流水线** | 让多条指令同时处于不同阶段 |
+| **超标量** | 同一时钟周期发射多条指令 |
+| **多核并行** | 多个 CPU 核心分担计算任务 |
+
+---
+
+## 2. 指令系统：CPU 与软件的接口
+
+上一节我们知道了冯诺依曼架构的核心思想：**程序和数据一样存储在内存中**。但这引出了一个关键问题——存在内存里的"程序"到底长什么样？CPU 怎么读懂它？
+
+答案就是**指令系统（Instruction Set Architecture, ISA）**。如果把 CPU 比作一个服务，那指令系统就是它的 **API 文档**——它定义了 CPU 能听懂的所有命令、每条命令的格式、以及命令能操作的数据范围。你写的每一行代码，最终都会被编译器翻译成这套"API"的调用序列。
+
+### 2.1 从代码到指令：一行代码的翻译之旅
+
+我们先建立一个全局认知：你在编辑器里写的代码，和 CPU 实际执行的东西，中间隔了好几层翻译。
+
+<CodeToInstructionDemo />
+
+这个翻译链路是理解指令系统的关键：
+
+| 层次 | 内容 | 谁能看懂 |
+|------|------|---------|
+| 高级语言 | `int a = 10 + 5;` | 人类 |
+| 汇编语言 | `MOV R1, #10` / `ADD R3, R1, R2` | 人类（需要训练） |
+| 机器码 | `0001 0001 0000 1010` | CPU |
+
+::: tip 为什么要理解这个链路？
+- 看到编译报错时，你知道错误发生在"高级语言→汇编"这一步
+- 看到运行时崩溃时，你知道问题出在 CPU 执行指令的阶段
+- 理解性能优化时，你知道编译器在"翻译"过程中做了哪些优化
+- 选择 CPU 架构时（x86 vs ARM），你知道差异在于"指令集 API"不同
+:::
+
+### 2.2 一条指令长什么样？
+
+知道了代码会被翻译成指令，下一个问题是：**一条指令的内部结构是什么？**
+
+每条机器指令本质上就是一串二进制数字，但它有严格的内部格式。最核心的两个部分：
+
+- **操作码（Opcode）**：告诉 CPU「做什么」——是加法？跳转？还是读内存？
+- **操作数（Operand）**：告诉 CPU「对谁做」——哪个寄存器？哪个内存地址？什么常数？
+
+就像一句话有「动词 + 宾语」的结构，指令也有「操作 + 对象」的结构：
+
+```
+指令:  ADD  R3, R1, R2
+       ───  ──────────
+       操作码  操作数
+       (做加法) (R3 = R1 + R2)
+```
+
+根据操作数的数量，指令格式从简单到复杂分为四种：
+
+<InstructionFormatDemo />
+
+| 格式 | 结构 | 例子 | 使用场景 |
+|------|------|------|---------|
+| 零地址 | 只有操作码 | `RET`（返回） | 堆栈计算机，操作数隐含在栈顶 |
+| 一地址 | 操作码 + 1个地址 | `INC R1`（R1加1） | 单操作数运算 |
+| 二地址 | 操作码 + 2个地址 | `MOV R1, R2` | 最常用，数据传送和运算 |
+| 三地址 | 操作码 + 3个地址 | `ADD R3, R1, R2` | 不破坏源操作数 |
+
+::: tip 为什么有这么多格式？
+这是**空间和灵活性的权衡**。零地址指令最短（省内存），但需要额外的栈操作；三地址指令最灵活（不破坏源数据），但占用更多位数。不同 CPU 架构会选择不同的指令格式组合。
+:::
+
+### 2.3 CPU 怎么找到数据？——寻址方式
+
+指令告诉 CPU「做加法」，但加法的两个数在哪里？可能直接写在指令里，可能在寄存器里，也可能在内存的某个地址。**寻址方式**就是告诉 CPU「去哪里找操作数」的规则。
+
+用生活中「找人」来类比：
+
+| 寻址方式 | 类比 | 指令示例 | 说明 |
+|---------|------|---------|------|
+| **立即数寻址** | 人就站在你面前 | `MOV R1, #100` | 数据直接写在指令里，最快 |
+| **寄存器寻址** | 打内线电话找同事 | `MOV R1, R2` | 数据在 CPU 内部的寄存器里，很快 |
+| **直接寻址** | 知道门牌号，直接上门 | `MOV R1, [0x1000]` | 指令里写了内存地址 |
+| **间接寻址** | 问前台「张三在哪个房间」 | `MOV R1, [R2]` | 寄存器里存的是地址，要多查一次 |
+| **变址寻址** | 「3号楼 + 5层」算出房间 | `MOV R1, [R2+10]` | 基地址 + 偏移量，用于数组访问 |
+
+<AddressingModeDemo />
+
+::: tip 为什么需要这么多寻址方式？
+不同场景需要不同的「找数据」策略：
+- **常量赋值**（`x = 100`）→ 立即数寻址，数据就在指令里
+- **变量运算**（`a + b`）→ 寄存器寻址，数据已经加载到寄存器
+- **数组访问**（`arr[i]`）→ 变址寻址，基地址 + 下标偏移
+- **指针操作**（`*ptr`）→ 间接寻址，寄存器里存的是地址
+
+你写 `arr[i]` 时不会想到寻址方式，但编译器会自动选择最合适的方式。
+:::
+
+### 2.4 CPU 的能力清单——指令分类
+
+现在我们知道了指令的格式和寻址方式，最后一个问题：**CPU 到底能做哪些事？**
+
+所有指令可以归为六大类，它们覆盖了计算机能做的一切操作：
+
+| 类型 | 做什么 | 代表指令 | 对应你写的代码 |
+|------|-------|---------|-------------|
+| **数据传送** | 搬运数据 | MOV, LOAD, STORE | `let x = y`、函数传参 |
+| **算术运算** | 加减乘除 | ADD, SUB, MUL, DIV | `a + b`、`count++` |
+| **逻辑运算** | 位操作 | AND, OR, NOT, XOR | `flags & 0xFF`、权限判断 |
+| **移位操作** | 左移右移 | SHL, SHR | `x << 2`（等价于乘4） |
+| **控制转移** | 跳转和调用 | JMP, CALL, RET | `if`、`for`、函数调用 |
+| **输入输出** | 与外设通信 | IN, OUT | 读键盘、写屏幕 |
+
+::: tip 一个关键洞察
+你写的所有代码——不管多复杂的业务逻辑、多炫酷的 UI 动画——最终都会被拆解成这六类基本操作的组合。CPU 的"智能"不在于它能做多复杂的事，而在于它能以每秒几十亿次的速度执行这些简单操作。
+:::
+
+### 2.5 两种设计哲学：CISC vs RISC
+
+指令系统的设计有一个根本性的分歧：**是让每条指令尽可能强大，还是让每条指令尽可能简单？**
+
+这个分歧产生了两大阵营，直接影响了你今天用的每一台设备：
+
+<CISCvsRISCDemo />
+
+用一个类比来理解：
+- **CISC 像瑞士军刀**：一把刀集成了剪刀、开瓶器、螺丝刀……功能多但每个不一定最好用
+- **RISC 像专业工具套装**：每个工具只做一件事，但做得又快又好
+
+::: tip 为什么你的手机用 ARM、电脑用 x86？
+- **x86 (CISC)** 统治了 PC 和服务器市场 40 年，积累了庞大的软件生态。换架构意味着所有软件都要重新编译
+- **ARM (RISC)** 凭借低功耗优势统治了移动设备。手机电池小，每一毫瓦都很珍贵
+- **Apple Silicon** 证明了 RISC 也能做到高性能——M 系列芯片在性能和功耗上同时超越了 x86 对手
+- **RISC-V** 是开源的 RISC 架构，正在 IoT、教育、AI 芯片领域快速崛起
+:::
+
+---
+
+> **小结**：指令系统是连接软件和硬件的桥梁。你写的代码通过编译器翻译成指令，指令通过操作码和操作数告诉 CPU 做什么、对谁做，寻址方式决定了数据从哪里来。不同的指令集设计（CISC/RISC）决定了 CPU 的性能特征和适用场景。
+>
+> 现在我们知道了指令的「静态结构」——它长什么样、有哪些类型。下一个问题是：**CPU 内部是怎么一步步执行这些指令的？** 这就是控制器的工作。
+
+---
+
+## 3. 控制器：CPU 的"指挥中心"
+
+### 3.1 控制器的组成
+
+控制器是 CPU 的"大脑"，负责协调各部件按指令要求工作：
+
+<ControllerDemo />
+
+| 组件 | 功能 |
+|------|------|
+| **程序计数器 (PC)** | 存放下一条指令的地址 |
+| **指令寄存器 (IR)** | 存放当前正在执行的指令 |
+| **指令译码器** | 解析指令的操作码和操作数 |
+| **时序发生器** | 产生节拍信号，控制各部件时序 |
+| **微操作序列生成器** | 产生执行指令所需的一系列控制信号 |
+
+<PSWFlagDemo />
+
+### 3.2 指令周期
+
+CPU 执行一条指令需要经历一个完整的**指令周期**，通常包括：
+
+1. **取指周期 (Fetch)**: 从内存读取指令到 IR
+2. **译码周期 (Decode)**: 解析指令含义
+3. **执行周期 (Execute)**: 执行操作
+4. **访存周期 (Memory Access)**: 如果需要访存，访问内存
+5. **写回周期 (Write Back)**: 把结果写回寄存器或内存
+
+### 3.3 微操作
+
+**微操作**是控制信号驱动下的最基本操作。例如，"取指"这个阶段可以分解为以下微操作：
+
+| 节拍 | 微操作 | 控制信号 |
+|------|--------|---------|
+| T1 | PC → MAR | PCout, MARin |
+| T2 | MEM → MDR | MEMout, MDRin |
+| T3 | MDR → IR | MDRout, IRin |
+| T4 | PC + 1 → PC | PC+1, PCin |
+
+### 3.4 硬布线 vs 微程序控制器
+
+| 特性 | 硬布线控制器 | 微程序控制器 |
+|------|------------|-------------|
+| **实现方式** | 组合逻辑电路 | 微指令序列(固件) |
+| **速度** | 快 | 稍慢 |
+| **设计难度** | 复杂 | 较简单 |
+| **灵活性** | 差(改动需重新设计电路) | 好(修改微程序即可) |
+| **典型应用** | RISC 处理器 | CISC 处理器早期 |
+
+---
+
+## 4. 存储体系：为什么需要缓存？
+
+### 4.1 存储层次结构
+
+计算机的存储设备构成了一个金字塔结构：
+
+<StorageHierarchyDemo />
+
+| 层次 | 存储类型 | 访问时间 | 典型容量 | 位置 |
+|------|---------|---------|---------|------|
+| **寄存器** | SRAM | <1ns | 几 KB | CPU 内部 |
+| **L1 缓存** | SRAM | ~1ns | 32-64KB | CPU 核心附近 |
+| **L2 缓存** | SRAM | ~3-10ns | 256KB-1MB | CPU 芯片内 |
+| **L3 缓存** | SRAM | ~10-20ns | 2-16MB | CPU 芯片内/共享 |
+| **主存(内存)** | DRAM | ~50-100ns | 8-64GB | 主板上 |
+| **SSD** | Flash | ~10-100μs | 256GB-2TB | 主板上 |
+| **HDD** | 磁盘 | ~5-10ms | 1-10TB | 机箱内 |
+
+::: tip 速度差异的比喻
+如果把 CPU 访问 L1 缓存比作**从桌上拿一张纸**：
+- 访问内存 → 坐电梯去楼下便利店买纸
+- 访问 SSD → 开车去另一个城市买纸
+- 访问 HDD → 坐飞机去另一个国家买纸
+
+速度差异可达**上百万倍**！
+:::
+
+### 4.2 缓存原理
+
+**缓存(Cache)** 是位于 CPU 和内存之间的快速存储，其核心思想基于两个局部性原理：
+
+::: tip 局部性原理
+- **时间局部性**：如果一个数据刚被访问，它很可能很快又被访问
+- **空间局部性**：如果一个数据被访问，它附近的数据很可能也被访问
+:::
+
+#### 缓存的工作方式
+
+1. **命中(Hit)**：CPU 要的数据在缓存中，直接读取
+2. **缺失(Miss)**：数据不在缓存中，需要从内存加载
+
+```
+命中率 = 命中次数 / 总访问次数
+平均访问时间 = 命中率 × 缓存时间 + (1-命中率) × 内存时间
+```
+
+<CacheDemo />
+
+### 4.3 缓存映射方式
+
+| 方式 | 原理 | 优点 | 缺点 |
+|------|------|------|------|
+| **直接映射** | 每个内存块只能放到一个固定位置 | 简单快速 | 冲突率高 |
+| **组相联** | 每个内存块可以放到 N 个位置(N路) | 平衡速度与命中率 | 实现复杂 |
+| **全相联** | 任意位置 | 最低冲突率 | 实现困难(需要比较所有标签) |
+
+### 4.4 虚拟内存
+
+**虚拟内存**是操作系统提供的重要抽象：
+
+- 每个进程都认为自己拥有完整的虚拟地址空间
+- 操作系统负责把虚拟地址翻译成物理地址
+- 不常用的页面可以换出到磁盘(交换空间)
+
+::: tip 虚拟内存的比喻
+把虚拟内存想象成**酒店管理房间**：
+- 你(进程)以为整栋楼都是你的
+- 实际上酒店(OS)只给你分配当前需要的房间
+- 不住的房间会被"换出"到仓库(磁盘)
+- 需要的房间可以随时"换入"
+:::
+
+---
+
+## 5. 总线与 I/O：计算机的"血管"
+
+### 5.1 系统总线
+
+**总线(Bus)** 是连接计算机各部件的数据通道：
+
+<BusSystemDemo />
+
+| 总线类型 | 功能 | 方向 | 典型宽度 |
+|---------|------|------|---------|
+| **地址总线** | 传送内存地址 | 单向(CPU→内存) | 32位/64位 |
+| **数据总线** | 传送数据 | 双向 | 32位/64位 |
+| **控制总线** | 传送控制信号 | 双向 | 多个信号线 |
+
+### 5.2 总线仲裁
+
+当多个设备同时请求使用总线时，需要**仲裁**机制决定谁先使用：
+
+| 仲裁方式 | 说明 |
+|---------|------|
+| **集中仲裁** | 中央仲裁器统一决定 |
+| **分布式仲裁** | 各设备自行协商 |
+
+### 5.3 I/O 设备访问方式
+
+| 方式 | 原理 | 优点 | 缺点 |
+|------|------|------|------|
+| **程序查询** | CPU 轮询检查 I/O 状态 | 简单 | CPU 利用率低 |
+| **中断方式** | I/O 完成后主动通知 CPU | CPU 可并行工作 | 中断处理有开销 |
+| **DMA** | I/O 设备直接访问内存 | CPU 完全不参与 | 需要 DMA 控制器 |
+
+<IOMethodDemo />
+
+### 5.4 DMA 原理
+
+**DMA (Direct Memory Access，直接内存访问)** 允许 I/O 设备直接与内存交换数据：
+
+<NetworkOverviewDemo />
+
+- **无 DMA**：CPU 全程参与数据传送，CPU 无法做其他事
+- **有 DMA**：CPU 告诉 DMA 控制器"从哪里传到哪里、传多少"，然后去执行其他任务，DMA 完成后通知 CPU
+
+::: tip DMA 的比喻
+这就像**点外卖**：
+- **没有 DMA**：你亲自去超市买菜、回家、洗菜、炒菜（全过程参与）
+- **有 DMA**：你打电话下单，外卖小哥直接送到厨房（别人帮你搞定，你只需要最后"收货"）
+:::
+
+### 5.5 中断机制
+
+**中断**是计算机系统中非常重要的机制：
+
+1. I/O 设备完成操作后，向 CPU 发送**中断请求**
+2. CPU 正在执行指令，完成当前指令后响应中断
+3. CPU 保存当前状态，跳转到中断处理程序
+4. 处理完成后，恢复状态继续执行
+
+---
+
+## 6. CPU 性能优化：流水线技术
+
+### 6.1 指令流水线
+
+**指令流水线**是一种让 CPU 效率最大化的并行技术：
+
+<PipelineDemo />
+
+#### 流水线的工作原理
+
+```
+顺序执行（5条指令，15个周期）：
+指令1: IF→ID→EX→MEM→WB
+指令2:            IF→ID→EX→MEM→WB
+指令3:                         IF→ID→EX→MEM→WB
+...
+
+流水线执行（5条指令，9个周期）：
+指令1: IF→ID→EX→MEM→WB
+指令2:    IF→ID→EX→MEM→WB
+指令3:       IF→ID→EX→MEM→WB
+...
+```
+
+理想情况下，N 条指令的 CPI(每指令周期数) ≈ 1
+
+### 6.2 流水线冒险
+
+流水线虽然能提高性能，但也会带来**冒险(Hazard)** 问题：
+
+| 类型 | 原因 | 解决方案 |
+|------|------|---------|
+| **结构冒险** | 硬件资源冲突 | 增加硬件/错开执行 |
+| **数据冒险** | 后面的指令需要前面的结果 | 数据转发/气泡/调度 |
+| **控制冒险** | 跳转指令改变执行流 | 延迟槽/分支预测 |
+
+---
+
+## 7. 总结：计算机是如何"跑起来"的？
+
+让我们用专业术语串联整个流程：
+
+> **程序启动后，操作系统将可执行文件从磁盘加载到内存。CPU 的取指单元(IF)通过地址总线从内存读取指令到指令寄存器(IR)。控制器对指令进行译码(ID)，识别出操作类型后产生相应的控制信号。运算单元(EX)执行算术逻辑运算，如果需要访存则通过数据总线访问内存(MEM)，最后结果写回(WB)到寄存器或内存。整个过程由时钟驱动，控制器发出的微操作序列协调各部件有序工作。**
+
+---
+
+## 延伸阅读
+
+| 主题 | 推荐深入学习内容 |
+|------|-----------------|
+| 计算机体系结构 | 《计算机组成与设计：硬件/软件接口》- Patterson & Hennessy |
+| CPU 微架构 | 《深入理解计算机系统》- Bryant & O'Hallaron |
+| 指令集架构 | ARMv8 架构手册、Intel x64 手册 |
+| 缓存原理 | 缓存一致性协议(MESI)、缓存写策略 |
+| 操作系统 | 后续章节《操作系统》 |
+
+---
+
+## 下一步
+
+现在你已经掌握了计算机组成原理的专业知识。接下来可以继续学习：
+
+- **[操作系统](./operating-systems.md)**：了解程序是如何在操作系统上运行的，进程、线程、内存管理是如何实现的
+- **[数据的编码、存储与传输](./data-encoding-storage.md)**：深入理解数据在计算机中的表示方式
@@ -3,15 +3,22 @@
 ::: tip 前言
 你有没有想过，当你按下电脑电源键，到最终在浏览器中看到网页，这中间到底发生了什么？

-这个过程涉及**硬件启动**、**操作系统加载**、**网络通信**等多个环节。理解这个过程，能帮助你建立对计算机系统的整体认知，也是成为全栈工程师的必经之路。
+这个过程就像一场**接力赛**——硬件通电后唤醒固件，固件检查完毕后交棒给操作系统，操作系统准备好环境后才能运行浏览器，浏览器再通过网络去远方的服务器取回网页。每一个环节都**依赖上一个环节的成功完成**，任何一棒掉链子，后面的步骤都无法进行。
+
+理解这条完整的链路，能帮助你建立对计算机系统的整体认知，也是成为全栈工程师的必经之路。
 :::

 **你会学到什么？**

- 电脑从通电到显示桌面的完整过程
- 操作系统是如何启动的
- 浏览器是如何工作的
- 当你访问一个 URL 时，网络请求是如何完成的
+这篇文章按照事件发生的真实顺序，带你走完从按下电源到看到网页的五个阶段：
+
+1. **硬件启动**（第 1 节）→ 电流如何唤醒 CPU
+2. **固件自检**（第 2 节）→ BIOS/UEFI 如何确认硬件正常并找到启动设备
+3. **操作系统启动**（第 3 节）→ 内核如何加载、桌面如何出现
+4. **浏览器启动**（第 4 节）→ 应用程序如何被操作系统运行起来
+5. **网络请求**（第 5 节）→ 从输入 URL 到页面渲染的完整网络之旅
+
+每一步都建立在前一步的基础上，缺一不可。

 ---

@@ -37,6 +44,12 @@ CPU 接收到复位信号后，把内部所有寄存器和缓存清零，从一

 ---

+> **接力第一棒完成** ⛳ 到这里，硬件层面的工作已经完成：电源把交流电转成了稳定的直流电，主板芯片组被唤醒并开始协调各部件，CPU 也完成了复位、清空了寄存器，准备好执行第一条指令。
+>
+> 但请注意——此刻的 CPU 就像一个"刚睁开眼的婴儿"。它虽然能执行指令，却对自己所在的环境一无所知：电脑里装了多少内存？显卡能不能用？硬盘在哪里？该从哪个设备启动操作系统？这些问题 CPU 自己回答不了。
+>
+> 所以，CPU 复位后执行的第一条指令，就是跳转到一个**固定的内存地址**——这个地址指向主板上焊死的 BIOS/UEFI 固件芯片。从这一刻起，控制权从纯硬件交到了固件手中。BIOS/UEFI 的任务很明确：**检查所有硬件是否正常，然后找到操作系统并把它启动起来**。这就是接力赛的第二棒。
+
 ## 2. BIOS/UEFI：硬件的自检

 ### 2.1 什么是 BIOS/UEFI？
@@ -83,6 +96,12 @@ BIOS/UEFI 会按照设定的**启动顺序**查找启动设备：

 ---

+> **接力第二棒完成** ⛳ BIOS/UEFI 圆满完成了它的三项使命：通过 POST 自检确认内存、显卡、键盘等硬件全部工作正常；初始化各硬件的工作模式；按照启动顺序找到了硬盘上的启动扇区。
+>
+> 但 BIOS/UEFI 的角色到此为止——它本质上是一个"体检医生 + 调度员"。它能检查硬件健不健康、能决定从哪个设备启动，但它不会管理你的文件，不会运行你的应用程序，也不会给你显示一个漂亮的桌面。这些复杂的任务，需要一个更强大的软件来接管——那就是**操作系统**。
+>
+> 交接的方式很具体：BIOS/UEFI 读取硬盘第一个扇区（启动扇区）里的引导程序代码，把它加载到内存中，然后让 CPU 跳转到这段代码开始执行。从这一刻起，控制权正式从固件交给了操作系统的引导程序。引导程序会一步步把操作系统内核加载进来，启动系统服务，最终呈现出你熟悉的桌面。这条链路中最复杂的一棒，开始了。
+
 ## 3. 操作系统启动：从内核到桌面

 ### 3.1 什么是操作系统？
@@ -176,6 +195,12 @@ BIOS → GRUB → vmlinuz (内核) → systemd → 系统服务 → 桌面环境

 ---

+> **接力第三棒完成** ⛳ 操作系统已经完全启动，桌面呈现在你眼前。回顾一下这一棒做了什么：引导程序从硬盘读取内核、内核接管了 CPU 和内存的控制权、系统服务逐个启动（网络、音频、安全中心……）、最后图形界面渲染出桌面。
+>
+> 此刻的操作系统就像一座已经通水通电、物业入驻的大楼——**进程管理**负责给每个住户（程序）分配房间，**内存管理**负责分配空间，**文件系统**负责管理仓库，**网络协议栈**负责对外通信。这些"公共服务"是所有应用程序运行的基础设施，没有它们，任何程序都无法启动。
+>
+> 现在你想上网，于是双击了桌面上的浏览器图标。这个简单的动作背后，操作系统要做一系列工作：查找浏览器的可执行文件在硬盘的哪个位置、为它创建一个独立的进程、分配内存空间、加载程序代码……这就是操作系统"进程管理"能力的直接体现。接下来，让我们看看浏览器是如何被启动起来的。
+
 ## 4. 打开浏览器：应用程序的启动

 ### 4.1 应用程序的启动过程
@@ -217,6 +242,12 @@ BIOS → GRUB → vmlinuz (内核) → systemd → 系统服务 → 桌面环境

 ---

+> **接力第四棒完成** ⛳ 浏览器已经成功启动。操作系统为它创建了独立的进程，分配了内存空间，浏览器自身的各个模块也已初始化完毕：渲染引擎准备好解析 HTML/CSS，JavaScript 引擎准备好执行脚本，网络模块准备好发送和接收数据。
+>
+> 你可以把此刻的浏览器想象成一辆已经发动的汽车——引擎在运转、仪表盘亮起、导航系统就绪，但车还停在原地，因为司机（你）还没有告诉它"去哪里"。浏览器窗口此刻是空白的，地址栏闪烁着光标，等待你的输入。
+>
+> 当你在地址栏敲入 `https://www.example.com` 并按下回车，一场跨越整个互联网的旅程就开始了。浏览器的网络模块会接管这个请求：先解析 URL 的结构，再通过 DNS 把域名翻译成 IP 地址，然后跨越网络与远方的服务器建立 TCP 连接，协商加密通道，发送 HTTP 请求，等待服务器响应，最后把收到的 HTML/CSS/JS 代码交给渲染引擎绘制成你看到的网页。这是整条接力链中步骤最多、涉及协议最丰富的一棒——也是 Web 开发者最需要理解的一段。
+
 ## 5. 访问 URL：网络请求的全过程

 ### 5.1 什么是 URL？
@@ -385,6 +416,12 @@ HTTP 响应格式：

 ---

+> **接力最后一棒完成** ⛳ 网页终于显示在你眼前了！回顾这最后一棒经历了多少环节：浏览器解析 URL 提取出协议和域名，通过 DNS 层层查询把域名翻译成 IP 地址，经过 TCP 三次握手与服务器建立可靠连接，再通过 TLS 握手建立加密通道，然后发送 HTTP 请求，服务器处理业务逻辑、查询数据库、组装响应数据返回，最后浏览器的渲染引擎把 HTML 解析成 DOM 树、CSS 计算成样式规则、两者合并成渲染树、计算布局、逐像素绘制到屏幕上。
+>
+> 现在，让我们把视角拉远，从头到尾审视这场接力赛的全貌。从按下电源键的那一刻算起：电流唤醒硬件（第 1 棒）→ 固件检查设备并找到启动盘（第 2 棒）→ 操作系统从内核到桌面完整启动（第 3 棒）→ 浏览器作为应用程序被操作系统运行起来（第 4 棒）→ 网络请求跨越互联网取回数据并渲染成页面（第 5 棒）。五棒环环相扣，每一棒都建立在前一棒的成果之上，缺少任何一个环节，你都无法看到眼前的这个网页。
+>
+> 接下来，让我们用一张完整的流程图把这五个阶段串在一起，直观地看看它们之间的依赖关系。
+
 ## 6. 完整流程回顾

 让我们把整个过程串起来：
@@ -415,6 +452,12 @@ HTTP 响应格式：

 ---

+> 看完整条链路，你会发现一个有趣的规律：每个阶段解决的问题完全不同，背后涉及的技术领域也截然不同。第 1 棒是**电子工程**的领域——电源转换、电路设计、信号传输；第 2 棒属于**固件编程**——用底层代码直接操控硬件；第 3 棒是**操作系统**的世界——进程调度、内存管理、文件系统，这是计算机科学的核心课题；第 4 棒涉及**应用开发**——如何设计一个像浏览器这样复杂的软件架构；第 5 棒则横跨**计算机网络**和**前端开发**——从 DNS、TCP/IP、HTTP 等网络协议，到 HTML/CSS/JS 的解析与渲染。
+>
+> 这也解释了为什么"全栈工程师"需要广泛的知识面：你写的每一行前端代码，最终都要经过这整条链路才能呈现给用户。理解链路中的每一环，能帮助你在遇到问题时快速定位——是网络层的问题？是服务器的问题？还是浏览器渲染的问题？
+>
+> 下面这张知识地图把这些技术领域梳理清楚，也为你后续的深入学习指明方向。
+
 ## 7. 知识地图

 这一章涉及的知识领域：
@@ -1,170 +0,0 @@
-# 类型系统与编译原理入门
-
-::: tip 前言
-当你写下 `int x = 10 + 5;` 时，编译器是如何理解每个字符、检查类型是否正确、最终生成机器指令的？本章用两个核心概念——**类型系统**和**编译流程**——帮你理解编程语言背后的"翻译机制"。
-:::
-
-**这篇文章会带你学什么？**
-
-学完这章后，你将获得：
-
- **问题诊断能力**：看到 `TypeError` 报错时，能快速定位是类型不匹配还是隐式转换惹的祸
- **语言选择依据**：理解为什么 TypeScript 适合大型项目、Python 适合快速原型开发
- **类型安全思维**：在写代码时就预见可能的类型错误，而不是等到运行时才发现
- **后续学习基础**：为编译原理、语言设计等高级话题打下基础
-
-| 章节 | 内容 | 核心概念 |
-|-----|------|---------|
-| **第 1 章** | 类型系统 | 静态/动态类型、强/弱类型 |
-| **第 2 章** | 编译流程 | 词法分析、语法分析、代码生成 |
-
---
-
-## 0. 想象你是翻译官
-
-翻译一本书，你需要：
-
-1. **识别单词** — 把句子拆成一个个单词（词法分析）
-2. **理解语法** — 判断句子是否符合语法规则（语法分析）
-3. **理解含义** — 确保句子意思正确，类型不冲突（语义分析）
-4. **优化表达** — 让句子更简洁流畅（代码优化）
-5. **翻译输出** — 翻译成目标语言（代码生成）
-
-**编译器就是编程语言的"翻译官"**，将你写的代码转换为机器能执行的指令。而**类型系统**就是翻译过程中的"语法检查器"——确保你不会把数字当文字用。
-
---
-
-## 1. 类型系统：数据的交通规则
-
-👇 动手点点看：探索四种类型系统的区别
-
-<TypeSystemDemo />
-
-::: tip 💡 一句话总结
-类型系统在两个维度上做选择：**何时检查**（编译时 vs 运行时）和**是否允许隐式转换**（强类型 vs 弱类型）。没有最好的组合，只有最适合的场景。
-:::
-
---
-
-### 1.1 静态类型 vs 动态类型
-
-| | 静态类型 | 动态类型 |
-|---|---|---|
-| **检查时机** | 编译时（还没运行就检查） | 运行时（跑到那行才检查） |
-| **发现 bug** | 早（写完就知道） | 晚（用户操作时才暴露） |
-| **灵活性** | 较低（类型固定） | 较高（类型可变） |
-| **IDE 支持** | 好（自动补全、重构） | 差（运行时才知道类型） |
-| **代表** | Java, TypeScript, Rust | Python, JavaScript, Ruby |
-
-### 1.2 强类型 vs 弱类型
-
-**核心区别**：`"1" + 1` 会发生什么？
-
- **强类型（Python）**：直接报错 `TypeError` — "你得明确告诉我怎么转"
- **弱类型（JavaScript）**：悄悄转成 `"11"` — "我猜你想拼字符串"
-
-弱类型的"好意"常常带来意想不到的 bug。
-
-### 1.3 类型推断：两全其美
-
-现代语言的类型推断让你**写着像动态语言，编译器检查像静态语言**：
-
-```typescript
-let x = 1           // 编译器自动推断为 number
-let arr = [1, 2, 3] // 推断为 number[]
-x = "hello"         // ❌ 编译错误！类型不匹配
-```
-
-你不用显式写类型声明，编译器也能帮你严格检查。
-
---
-
-## 2. 编译流程：从代码到机器码
-
-👇 动手点点看：输入代码，观察编译器的六步翻译过程
-
-<CompilerDemo />
-
-::: tip 💡 一句话总结
-编译器的六步流水线：源代码 → Token（词法分析）→ AST（语法分析）→ 带类型的 AST（语义分析）→ IR（中间代码）→ 优化后的 IR → 机器码。
-:::
-
---
-
-### 2.1 词法分析：拆出每个"单词"
-
-```
-源代码: int x = 10 + 5;
-
-Token 流:
-[int]   → 关键字
-[x]     → 标识符
-[=]     → 运算符
-[10]    → 数字
-[+]     → 运算符
-[5]     → 数字
-[;]     → 分隔符
-```
-
-### 2.2 语法分析：构建语法树（AST）
-
-```
-表达式: 1 + 2 * 3
-
-语法树:        为什么？
-       +       因为 * 的优先级
-      / \      高于 +，所以
-     1   *     2 * 3 先结合
-        / \
-       2   3
-```
-
-### 2.3 语义分析：检查"意思"是否正确
-
-| 检查内容 | 示例 | 结果 |
-|---|---|---|
-| 类型检查 | `int x = "hello"` | ❌ 类型不匹配 |
-| 作用域分析 | 使用未声明的变量 | ❌ 变量不存在 |
-| 类型推断 | `1 + 2.0` | ✅ 推断为 float |
-
-### 2.4 代码优化：让程序跑得更快
-
-| 优化技术 | 优化前 | 优化后 |
-|---|---|---|
-| 常量折叠 | `x = 10 + 5` | `x = 15` |
-| 死代码消除 | `if (false) { ... }` | 直接删除 |
-| 常量传播 | `y = x * 2`（x=15） | `y = 30` |
-
---
-
-## 3. 编译型 vs 解释型 vs JIT
-
-程序写完后，有三种"翻译方式"让它运行：
-
-| | 编译型 | 解释型 | JIT 即时编译 |
-|---|---|---|---|
-| **过程** | 先编译成机器码，再执行 | 边读边执行 | 先解释，热点代码再编译 |
-| **速度** | 最快 | 最慢 | 中等（热点代码接近编译型） |
-| **启动** | 慢（需编译） | 快（直接运行） | 中等（需预热） |
-| **跨平台** | 需要重新编译 | 天然跨平台 | 跨平台 |
-| **代表** | C, Rust, Go | Python, Ruby | Java, JavaScript (V8) |
-
-::: tip 💡 为什么 JavaScript 这么快？
-V8 引擎的 JIT 编译器会监测哪些代码被频繁执行（热点代码），然后把它们编译成高度优化的机器码。所以虽然 JavaScript 是"解释型语言"，但在 V8 中它的性能可以接近编译型语言。
-:::
-
---
-
-## 4. 总结
-
-::: tip 📚 核心要点
-1. **类型系统**：静态/动态决定检查时机，强/弱决定是否允许隐式转换
-2. **编译六步**：词法分析 → 语法分析 → 语义分析 → 中间代码 → 优化 → 代码生成
-3. **三种执行**：编译型快但需编译，解释型灵活但慢，JIT 兼顾两者
-4. **类型推断**：现代语言让你享受动态语言的简洁和静态语言的安全
-:::
-
-**下一步学习**：
- [编程语言图谱](./programming-languages) - 了解更多编程语言
- [数据结构](./data-structures) - 理解数据的组织方式
- [算法思维入门](./algorithm-thinking) - 学习解决问题的方法
@@ -0,0 +1,211 @@
+# 类型系统入门
+
+::: tip 前言
+**为什么 `"1" + 1` 在 JavaScript 里得到 `"11"`，在 Python 里却直接报错？** 这背后就是类型系统在起作用。类型系统是编程语言的"交通规则"——它决定了数据能怎么用、能和谁运算、什么时候检查合不合法。理解类型系统，你就能理解不同语言的"性格差异"。
+:::
+
+**这篇文章会带你学什么？**
+
+学完这章后，你将获得：
+
+- **分类能力**：掌握静态/动态、强/弱类型的四象限分类法
+- **问题诊断**：看到 `TypeError` 时能快速定位是类型不匹配还是隐式转换
+- **语言选择**：理解为什么 TypeScript 适合大型项目、Python 适合快速原型
+- **类型推断**：理解现代语言如何兼顾简洁和安全
+- **实践意识**：掌握类型安全的编码习惯
+
+| 章节 | 内容 | 核心概念 |
+|-----|------|---------|
+| **第 1 章** | 什么是类型系统 | 类型的本质、为什么需要类型 |
+| **第 2 章** | 静态类型 vs 动态类型 | 检查时机、IDE 支持、安全性 |
+| **第 3 章** | 强类型 vs 弱类型 | 隐式转换、类型安全 |
+| **第 4 章** | 类型推断 | 自动推断、两全其美 |
+| **第 5 章** | 泛型：写一次，适用所有类型 | 类型参数、类型约束、复用 |
+| **第 6 章** | 类型安全实战 | 常见陷阱、防御策略 |
+| **第 7 章** | 语言类型象限图 | 四象限分类、语言选择 |
+
+---
+
+## 0. 全景图：类型是数据的"身份证"
+
+在现实世界中，你不会把一本书塞进咖啡杯里——因为它们是不同"类型"的东西。编程世界也一样：数字、字符串、布尔值、数组……每种数据都有自己的"身份"，决定了它能参与什么运算。
+
+**类型系统**就是编程语言用来管理这些"身份"的规则体系。它回答两个核心问题：
+
+::: tip 类型系统的两个核心问题
+- **何时检查？** 是写代码时就检查（静态类型），还是运行时才检查（动态类型）？
+- **多严格？** 是严格禁止混用（强类型），还是自动帮你转换（弱类型）？
+:::
+
+---
+
+## 1. 什么是类型系统：数据的交通规则
+
+<TypeSystemDemo />
+
+类型系统的本质是一套**约束规则**，它告诉编译器或解释器：
+
+- 这个变量能存什么值？
+- 这两个值能不能做加法？
+- 这个函数的参数应该是什么？
+
+没有类型系统的世界就像没有交通规则的马路——任何数据都能和任何数据运算，结果完全不可预测。
+
+| 类型系统的作用 | 说明 | 例子 |
+|-------------|------|------|
+| 防止非法运算 | 阻止无意义的操作 | 不能对字符串做除法 |
+| 提供文档信息 | 类型就是最好的文档 | `function add(a: number, b: number)` 一目了然 |
+| 辅助 IDE 工具 | 自动补全、重构、跳转 | 输入 `user.` 自动提示所有属性 |
+| 优化性能 | 编译器知道类型后能生成更快的代码 | 知道是整数就用整数指令 |
+
+---
+
+## 2. 静态类型 vs 动态类型：什么时候检查？
+
+这是类型系统最重要的分类维度——**检查时机**。
+
+<StaticVsDynamicDemo />
+
+::: tip 核心区别
+- **静态类型**：变量的类型在编译时就确定了，写完代码、还没运行就能发现类型错误。代表：Java、TypeScript、Rust、Go。
+- **动态类型**：变量的类型在运行时才确定，同一个变量可以先存数字再存字符串。代表：Python、JavaScript、Ruby、PHP。
+:::
+
+| 维度 | 静态类型 | 动态类型 |
+|------|---------|---------|
+| 检查时机 | 编译时（还没运行就检查） | 运行时（跑到那行才检查） |
+| 发现 bug | 早（写完就知道） | 晚（用户操作时才暴露） |
+| 灵活性 | 较低（类型固定） | 较高（类型可变） |
+| IDE 支持 | 好（自动补全、重构） | 较弱（运行时才知道类型） |
+| 开发速度 | 前期慢（要写类型） | 前期快（不用管类型） |
+| 维护成本 | 低（类型即文档） | 高（缺少类型信息） |
+
+::: tip 趋势：动态语言在"静态化"
+Python 加了 Type Hints，JavaScript 社区转向 TypeScript——动态语言也在拥抱静态类型的好处。这说明在大型项目中，静态类型的安全性优势越来越被认可。
+:::
+
+---
+
+## 3. 强类型 vs 弱类型：允不允许"偷偷转换"？
+
+第二个分类维度是**类型转换的严格程度**。
+
+<StrongVsWeakDemo />
+
+::: tip 核心区别
+- **强类型**：不允许隐式类型转换，类型不匹配就报错。你必须显式地告诉语言"我要把字符串转成数字"。
+- **弱类型**：允许隐式类型转换，语言会"好心"帮你自动转。但这种"好心"经常带来意想不到的 bug。
+:::
+
+| 维度 | 强类型 | 弱类型 |
+|------|-------|-------|
+| `"1" + 1` | 报错或需显式转换 | 自动转换（可能得到 `"11"` 或 `2`） |
+| 安全性 | 高（不会悄悄出错） | 低（隐式转换可能导致 bug） |
+| 便利性 | 低（需要手动转换） | 高（自动转换省事） |
+| 可预测性 | 高（行为确定） | 低（转换规则复杂） |
+
+---
+
+## 4. 类型推断：两全其美的现代方案
+
+早期的静态类型语言（如 Java）要求你显式声明每个变量的类型，写起来很啰嗦。现代语言通过**类型推断**解决了这个问题——编译器自动推断类型，你不用写，但它帮你严格检查。
+
+<TypeInferenceFlowDemo />
+
+::: tip 类型推断的价值
+写着像动态语言一样简洁，编译器检查像静态语言一样严格。这是现代编程语言的主流方向。
+- **TypeScript**：`let x = 42` 自动推断为 `number`
+- **Rust**：`let v = vec![1, 2, 3]` 自动推断为 `Vec<i32>`
+- **Kotlin**：`val name = "Alice"` 自动推断为 `String`
+- **Go**：`x := 42` 短变量声明自动推断类型
+:::
+
+---
+
+## 5. 泛型：写一次，适用所有类型
+
+当你写了一个"取数组第一个元素"的函数，你会发现：数字数组要写一个、字符串数组要写一个、对象数组又要写一个……代码完全一样，只是类型不同。**泛型（Generics）**就是解决这个问题的——用一个"类型参数"代替具体类型，让一份代码适用于所有类型。
+
+<GenericTypeDemo />
+
+::: tip 泛型的核心价值
+- **代码复用**：一个函数/类适用于所有类型，不用重复写
+- **类型安全**：不像 `any` 那样放弃类型检查，泛型全程保持类型信息
+- **类型约束**：用 `extends` 限制泛型的范围，既灵活又安全
+:::
+
+| 泛型特性 | 说明 | 示例 |
+|---------|------|------|
+| 泛型函数 | 函数的参数/返回值使用类型参数 | `function first<T>(arr: T[]): T` |
+| 泛型类 | 类的属性/方法使用类型参数 | `class Box<T> { value: T }` |
+| 泛型约束 | 用 extends 限制 T 的范围 | `<T extends HasLength>` |
+| 多个类型参数 | 同时使用多个类型变量 | `function pair<K, V>(k: K, v: V)` |
+
+---
+
+## 6. 类型安全实战：常见陷阱与防御
+
+理论学完了，来看看实际开发中最容易踩的类型坑。这些陷阱不分语言，几乎每个开发者都会遇到。
+
+<TypeSafetyPracticeDemo />
+
+::: tip 类型安全的四条黄金法则
+1. **开启严格模式**：TypeScript 的 `strict: true`、Python 的 `mypy --strict`
+2. **避免 any**：用 `unknown` 代替 `any`，强制你做类型检查后再使用
+3. **显式处理 null**：用可选链 `?.` 和空值合并 `??` 安全访问
+4. **为 API 定义接口**：外部数据永远不可信，用接口 + 运行时校验双重保障
+:::
+
+| 陷阱 | 危险程度 | 防御手段 |
+|------|---------|---------|
+| null/undefined 引用 | ⭐⭐⭐⭐⭐ | strictNullChecks + 可选链 |
+| any 类型滥用 | ⭐⭐⭐⭐ | 用 unknown + 类型守卫 |
+| 隐式类型转换 | ⭐⭐⭐ | 严格比较 === + ESLint |
+| 数组类型不一致 | ⭐⭐⭐ | 显式声明数组元素类型 |
+
+---
+
+## 7. 语言类型象限图：给编程语言"画像"
+
+把"静态/动态"和"强/弱"两个维度组合起来，就得到了一个四象限分类图。每种编程语言都可以放进这个图里。
+
+<LanguageTypeModelDemo />
+
+| 象限 | 特点 | 代表语言 | 适用场景 |
+|------|------|---------|---------|
+| 静态 + 强类型 | 最安全，编译时严格检查 | Rust, Java, Haskell | 大型系统、安全关键 |
+| 静态 + 弱类型 | 编译时检查但允许隐式转换 | C, C++ | 系统编程、性能敏感 |
+| 动态 + 强类型 | 运行时检查，不允许隐式转换 | Python, Ruby | 脚本、快速原型 |
+| 动态 + 弱类型 | 最灵活，也最容易出 bug | JavaScript, PHP | Web 前端、小型脚本 |
+
+::: tip 没有"最好"的类型系统
+选择语言时，类型系统是重要考量因素之一：
+- **快速原型**：动态类型（Python）开发速度快
+- **大型项目**：静态类型（TypeScript、Java）维护成本低
+- **系统编程**：强类型 + 静态（Rust）安全性最高
+- **团队协作**：静态类型提供更好的代码可读性和 IDE 支持
+:::
+
+---
+
+## 总结
+
+类型系统是理解编程语言差异的关键视角。它不是枯燥的理论，而是直接影响你写代码的体验和代码的质量。
+
+回顾本章的关键要点：
+
+1. **类型是身份证**：每种数据都有类型，类型决定了数据能参与什么运算
+2. **静态 vs 动态**：何时检查类型——编译时还是运行时
+3. **强 vs 弱**：是否允许隐式类型转换
+4. **类型推断**：现代语言让你享受动态的简洁和静态的安全
+5. **泛型**：用类型参数实现代码复用，兼顾灵活性和类型安全
+6. **类型安全实战**：null 引用、any 滥用、隐式转换是最常见的类型陷阱
+7. **四象限分类**：没有最好的类型系统，只有最适合场景的选择
+
+## 延伸阅读
+
+- [TypeScript 官方文档](https://www.typescriptlang.org/docs/) - 最流行的静态类型 JavaScript 超集
+- [Python Type Hints](https://docs.python.org/3/library/typing.html) - Python 的类型提示系统
+- [Rust Book - Data Types](https://doc.rust-lang.org/book/ch03-02-data-types.html) - Rust 的类型系统入门
+- [Type Systems (Wikipedia)](https://en.wikipedia.org/wiki/Type_system) - 类型系统的学术概述
+- [What To Know Before Debating Type Systems](https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/) - 关于类型系统的经典讨论
@@ -33,19 +33,7 @@

 想象一下以前的软件开发：

-```
-传统开发流程：
-你 → 学习语法 → 写代码 → 调试 → 查文档 → 修改 → 运行
-        ↑___________________反复循环___________________↓
-```
-
-现在有了 AI 辅助：
-
-```
-Vibe Coding 流程：
-你 → 用自然语言描述需求 → AI 生成代码 → 你审核修改 → 运行
-              ↑____________快速迭代____________↓
-```
+<VibeCodingFlowDemo />

 **核心变化**：从"怎么写代码"变成"怎么描述需求"。

@@ -130,7 +118,7 @@ AI 能帮你写代码，但以下能力 AI 替代不了：

 <FrontendFrameworkDemo />

-**核心原因**：当页面变得复杂（比如淘宝、微信网页版），直接操作 DOM 会变得非常混乱。框架帮你"管理复杂性"。
+**核心原因**：当页面变得复杂（比如淘宝、微信网页版），直接用代码一个个操控页面元素会变得非常混乱。框架帮你"管理复杂性"。

 ### 2.4 前端工程师的一天

@@ -306,28 +294,30 @@ AI 能帮你写代码，但以下能力 AI 替代不了：
 ### 6.2 AI 工程师的技能树

 ```
-AI 算法工程师
+AI 工程师（2025）
    │
-    ├── 数学基础
-    │   ├── 线性代数（矩阵运算）
-    │   ├── 概率统计（分布、期望）
-    │   └── 微积分（梯度、优化）
-    │
-    ├── 编程能力
+    ├── 基础能力
    │   ├── Python（主力语言）
-    │   ├── PyTorch / TensorFlow（深度学习框架）
-    │   └── 数据处理（Pandas, NumPy）
+    │   ├── 数据处理（Pandas, NumPy）
+    │   └── 基本数学直觉（线性代数、概率统计）
    │
-    ├── 机器学习
-    │   ├── 监督学习（分类、回归）
-    │   ├── 无监督学习（聚类、降维）
-    │   └── 模型评估方法
+    ├── 大模型应用（最热门方向）
+    │   ├── Prompt Engineering（提示词工程）
+    │   ├── RAG（检索增强生成）
+    │   ├── AI Agent（智能体，让 AI 自主完成任务）
+    │   ├── Function Calling / MCP（让 AI 调用外部工具）
+    │   └── 微调与部署（LoRA, vLLM）
    │
-    └── 深度学习
-        ├── 神经网络基础
-        ├── CNN（图像）
-        ├── RNN / Transformer（序列）
-        └── 大模型（LLM）
+    ├── 生成式 AI（GenAI）
+    │   ├── 文本生成（GPT, Claude, Gemini）
+    │   ├── 图像生成（Stable Diffusion, Midjourney, FLUX）
+    │   ├── 视频生成（Sora, Kling）
+    │   └── 多模态（文本 + 图像 + 音频）
+    │
+    └── 传统机器学习（仍然重要）
+        ├── 监督学习（分类、回归）
+        ├── 深度学习框架（PyTorch）
+        └── 模型评估与优化
 ```

 ### 6.3 AI 工程师的一天