docs: 重构 README 附录展示 & 新增多个附录交互组件

README 更新:
- 移除顶部 header.png 横幅图片
- 新增「附录知识库」板块，以 3×3 网格展示 9 大知识领域精选内容
- 附录链接指向部署版网站 (datawhalechina.github.io)
- 阶段表格新增「附录」行，突出 80+ 交互式专题
- 章节标题「新手入门 & PM」简化为「零基础入门」
- News 新增 2026-02-25 附录知识库更新条目

新增交互组件:
- 异步任务队列 (async-task-queues) 演示组件
- 文件存储 (file-storage) 演示组件
- 项目架构 (project-architecture) 演示组件
- 限流与背压 (rate-limiting) 演示组件
- 搜索引擎 (search-engines) 演示组件
- 计算机基础: AppLaunch/BiosUefi/OSBoot 等启动流程演示组件

新增附录文档:
- 前端项目架构 (frontend-project-architecture.md)
- 后端项目架构 (backend-project-architecture.md)

内容优化:
- 算法思维、数据结构、编程语言、调试艺术等多篇附录内容更新
- HTML/CSS 布局、请求旅程等前后端文档完善
- 附录索引页 (index.md) 同步更新

docs/zh-cn/appendix/1-computer-fundamentals/algorithm-thinking.md

@@ -69,6 +69,11 @@
 **生活类比**：猜数字游戏。我想一个 1-100 的数，你每次猜中间，我告诉你大了还是小了。最多猜 7 次就能猜中（因为 2⁷ = 128 > 100）。
 :::
 
+👇 **动手试试看**：
+下面这个演示展示了二分查找的工作原理，你可以选择顺序查找或二分查找来对比：
+
+<SearchAlgorithmDemo />
+
 ### 1.2 为什么二分查找这么快？
 
 | 数据量 | 线性查找 | 二分查找 |
@@ -78,7 +83,17 @@
 | 1,000,000 | 1,000,000 次 | 20 次 |
 | 1,000,000,000 | 1,000,000,000 次 | 30 次 |
 
-::: tip 💡 对数增长的威力
+::: tip � 逐行解读这张表
+**第一列（数据量）**：要查找的数据有多少。可以看到数据量从 100 增长到 10 亿（扩大了 1000 万倍！）
+
+**第二列（线性查找）**：最"笨"的方法，从第一个开始一个一个找。查找次数等于数据量，数据量越大，查找次数越多。
+
+**第三列（二分查找）**：聪明的方法，每次排除一半。查找次数只和数据量的对数有关，即使 10 亿数据也只需要 30 次！
+
+**对比结论**：当数据量达到 100 万时，线性查找需要 100 万次，二分查找只需要 20 次——差距达 5 万倍！
+:::
+
+::: tip � 对数增长的威力
 二分查找的时间复杂度是 O(log n)，这意味着：
 
 - 10 亿数据，最多查找 30 次
@@ -102,6 +117,20 @@
 | **归并排序** | O(n log n) | 稳定排序 | 需要稳定性的场景 |
 | **堆排序** | O(n log n) | 原地排序 | 内存受限场景 |
 
+::: tip 📊 逐行解读这张表
+**冒泡排序**：最基础的排序算法，就像水底的气泡往上冒一样。简单易懂，但速度最慢。适合学习排序思想，不适合实际使用。
+
+**选择排序**：每次选出最小的放到前面。也很简单，但无论数据是否有序都要做同样多的比较。
+
+**插入排序**：像打扑克牌时整理手牌一样。把每个元素插入到前面已经排好序的部分中。对近乎有序的数据效率很高。
+
+**快速排序**：实际开发中最常用的排序。平均情况下最快，但最坏情况（数据已经有序）会退化到 O(n²)。
+
+**归并排序**：采用"分而治之"的思想，总是 O(n log n)，但需要额外空间。适合需要稳定排序的场景。
+
+**堆排序**：利用堆这种数据结构的排序，原地排序（不需要额外空间），但实际运行往往比快速排序慢。
+:::
+
 ### 2.2 为什么快速排序"快"？
 
 ::: tip 💡 快速排序的原理
@@ -120,6 +149,11 @@
 **生活类比**：整理书架。先抽出一本书，把比它薄的放左边，比它厚的放右边。然后对左右两堆分别重复这个过程。
 :::
 
+👇 **动手试试看**：
+下面这个演示展示了排序算法的可视化，你可以生成数组，观察冒泡排序和快速排序的过程对比：
+
+<SortingAlgorithmDemo />
+
 ---
 
 ## 3. 递归：自己调用自己
@@ -153,6 +187,16 @@ function factorial(n) {
 | **性能** | 稍慢（函数调用开销） | 更快 |
 | **适用场景** | 树遍历、分治算法 | 简单重复任务 |
 
+::: tip 📊 逐行解读这张表
+**代码简洁度**：递归通常只需要几行代码就能表达复杂的逻辑（如遍历树结构），而用循环可能需要更多的变量和嵌套。
+
+**内存消耗**：递归会使用"调用栈"来保存每一层的信息，就像叠盘子一样，每递归一层就多一个盘子。循环则不需要这种开销。
+
+**性能**：每次函数调用都有开销（参数传递、栈操作等），所以递归通常比循环慢一些。
+
+**适用场景**：递归擅长处理本身就是递归结构的问题（如文件树、DOM 树）；循环擅长简单的重复操作（如遍历数组）。
+:::
+
 ::: warning ⚠️ 递归的陷阱
 **栈溢出**：递归层次太深，调用栈空间耗尽。
 
@@ -162,6 +206,11 @@ function factorial(n) {
 - 限制递归深度
 :::
 
+👇 **动手试试看**：
+下面这个演示展示了递归的调用过程，观察函数如何自己调用自己：
+
+<RecursiveThinkingDemo />
+
 ---
 
 ## 4. 贪心算法：每步选最优
@@ -197,6 +246,11 @@ function factorial(n) {
 **教训**：贪心算法简单高效，但不总是能得到最优解。使用前要证明问题满足贪心条件。
 :::
 
+👇 **动手试试看**：
+下面这个演示展示了贪心算法的实际效果，你可以尝试不同的硬币组合，观察贪心策略的表现：
+
+<GreedyThinkingDemo />
+
 ---
 
 ## 5. 算法设计范式
@@ -208,6 +262,21 @@ function factorial(n) {
 | **动态规划** | 记录子问题的解 | 背包问题、最短路径 | 有重叠子问题 |
 | **回溯** | 试错，走不通就回退 | 八皇后、全排列 | 搜索问题 |
 
+::: tip 📊 逐行解读这张表
+**分治**：把大问题拆成小问题，分别解决后再合并。就像整理房间，先分成客厅、卧室、厨房分别打扫，最后整体整洁。
+
+**贪心**：每步都选当前最好的，不考虑长远后果。像吃饭时先挑最喜欢吃的菜，可能不是最优的吃法，但速度快。
+
+**动态规划**：记住中间结果，避免重复计算。像记笔记，下次遇到同样问题直接查答案，不用重新推导。
+
+**回溯**：走不通就退回来重试。像走迷宫，此路不通就返回上一个路口尝试别的路。
+:::
+
+👇 **动手试试看**：
+下面这个演示展示了不同算法设计范式的特点和应用场景：
+
+<AlgorithmParadigmDemo />
+
 ---
 
 ## 6. 总结：算法是解决问题的艺术