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/4-server-and-backend/rate-limiting-backpressure.md

@@ -1,3 +1,131 @@
 # 限流与背压控制
 
-> 待实现
+::: tip 前言
+**双十一零点，几亿用户同时涌入——服务器扛得住吗？** 任何系统都有处理能力的上限。当请求量超过系统承载能力时，如果不加控制，结果就是所有人都用不了。限流和背压就是保护系统不被"压垮"的两道防线。
+:::
+
+**这篇文章会带你学什么？**
+
+学完这章后，你将获得：
+
+- **限流必要性**：理解为什么需要主动拒绝部分请求来保护系统
+- **限流算法**：掌握令牌桶、漏桶、滑动窗口三种核心算法的原理和差异
+- **背压机制**：理解当上游速度超过下游时的处理策略
+- **多层限流**：了解从客户端到网关到服务的多层限流架构
+- **实战能力**：知道在什么场景下选择什么限流策略
+
+| 章节 | 内容 | 核心概念 |
+|-----|------|---------|
+| **第 1 章** | 为什么需要限流 | 雪崩效应、服务保护 |
+| **第 2 章** | 限流算法 | 令牌桶、漏桶、滑动窗口 |
+| **第 3 章** | 背压控制 | 缓冲区、丢弃策略、弹性扩容 |
+| **第 4 章** | 多层限流架构 | 客户端、网关、服务端 |
+| **第 5 章** | 实战与选型 | Nginx、Redis、Sentinel |
+
+---
+
+## 0. 全景图：为什么要"拒绝"用户？
+
+这听起来很反直觉——我们不是应该服务好每一个用户吗？但现实是：**不拒绝一部分请求，所有请求都会失败**。
+
+想象一个只能坐 100 人的餐厅，突然涌进来 1000 人。如果不限流，结果不是 1000 人都能吃上饭，而是厨房崩溃、服务员瘫痪，1000 人谁都吃不上。正确的做法是在门口排队限流，让 100 人先进去，其余人等候。
+
+::: tip 限流的核心目标
+- **保护系统**：防止过载导致服务完全不可用
+- **公平分配**：确保已接受的请求能正常处理
+- **优雅降级**：被限流的请求收到明确的 429 状态码，而不是超时或 500 错误
+:::
+
+---
+
+## 1. 限流算法：三种经典方案
+
+限流的核心问题是：**在单位时间内，最多允许多少个请求通过？** 不同的算法在精确度、突发流量处理、实现复杂度上各有取舍。
+
+<RateLimitAlgorithmDemo />
+
+| 算法 | 原理 | 突发流量 | 精确度 | 实现复杂度 |
+|------|------|---------|--------|-----------|
+| 令牌桶 | 固定速率放令牌，请求消耗令牌 | 允许（桶中有存量） | 高 | 中 |
+| 漏桶 | 请求排队，固定速率处理 | 不允许（完全平滑） | 高 | 中 |
+| 滑动窗口 | 统计窗口内请求数 | 部分允许 | 较高 | 低 |
+| 固定窗口 | 按时间窗口计数 | 边界处可能突发 | 低 | 最低 |
+
+::: tip 选哪个算法？
+- **API 限流**：令牌桶最常用，允许合理的突发流量
+- **流量整形**：漏桶适合需要恒定输出速率的场景
+- **简单计数**：滑动窗口实现简单，适合大多数 Web 应用
+:::
+
+---
+
+## 2. 背压控制：当上游比下游快
+
+限流解决的是"外部请求太多"的问题，而**背压（Backpressure）**解决的是"内部组件速度不匹配"的问题。
+
+当生产者产生数据的速度持续超过消费者处理数据的速度时，中间的缓冲区会不断膨胀，最终导致内存溢出或数据丢失。背压机制就是让消费者能够"反向通知"生产者减速。
+
+<BackpressureDemo />
+
+::: tip 背压的四种策略
+1. **丢弃（Drop）**：缓冲区满时丢弃新数据或旧数据，适合实时性要求高但允许丢失的场景
+2. **阻塞（Block）**：让生产者暂停，等消费者处理完再继续，适合数据不能丢失的场景
+3. **采样（Sample）**：只处理部分数据，适合高频数据流
+4. **弹性扩容（Scale）**：动态增加消费者数量，适合云原生环境
+:::
+
+---
+
+## 3. 多层限流架构
+
+生产环境中，限流不是在某一个点做就够了，而是需要**多层防护**，每一层解决不同粒度的问题。
+
+| 层级 | 位置 | 限流粒度 | 工具 |
+|------|------|---------|------|
+| 客户端 | 前端/App | 按钮防抖、请求节流 | lodash.throttle、debounce |
+| CDN/WAF | 边缘节点 | IP 级别、地域级别 | Cloudflare Rate Limiting |
+| API 网关 | 入口网关 | 路由级别、用户级别 | Nginx limit_req、Kong |
+| 服务端 | 应用内部 | 接口级别、资源级别 | Sentinel、Resilience4j |
+| 数据库 | 存储层 | 连接数、QPS | 连接池配置、慢查询熔断 |
+
+::: tip 限流的 HTTP 规范
+被限流的请求应该返回 `429 Too Many Requests` 状态码，并在响应头中包含：
+- `Retry-After`: 建议客户端多久后重试（秒数或日期）
+- `X-RateLimit-Limit`: 限流上限
+- `X-RateLimit-Remaining`: 剩余配额
+- `X-RateLimit-Reset`: 配额重置时间
+:::
+
+---
+
+## 4. 实战选型
+
+| 场景 | 推荐方案 | 说明 |
+|------|---------|------|
+| Nginx 入口限流 | `limit_req_zone` | 基于漏桶算法，配置简单 |
+| 分布式限流 | Redis + Lua 脚本 | 令牌桶或滑动窗口，多实例共享计数 |
+| Java 微服务 | Sentinel / Resilience4j | 支持熔断、降级、热点限流 |
+| Node.js API | express-rate-limit | 简单易用，支持 Redis 存储 |
+| Go 服务 | golang.org/x/time/rate | 标准库令牌桶实现 |
+
+---
+
+## 总结
+
+限流和背压是保护系统稳定性的两道关键防线。限流控制外部流量的涌入速度，背压协调内部组件的处理速度。
+
+回顾本章的关键要点：
+
+1. **限流的必要性**：不拒绝部分请求，所有请求都会失败
+2. **三种核心算法**：令牌桶（允许突发）、漏桶（完全平滑）、滑动窗口（简单精确）
+3. **背压机制**：丢弃、阻塞、采样、扩容四种策略
+4. **多层防护**：从客户端到数据库，每层解决不同粒度的问题
+5. **429 规范**：被限流时返回标准状态码和限流头信息
+
+## 延伸阅读
+
+- [Stripe 的限流实践](https://stripe.com/blog/rate-limiters) - 支付系统的限流设计
+- [Nginx limit_req 文档](https://nginx.org/en/docs/http/ngx_http_limit_req_module.html) - Nginx 限流模块
+- [Alibaba Sentinel](https://sentinelguard.io/) - 面向分布式服务的流量控制组件
+- [Resilience4j](https://resilience4j.readme.io/) - Java 轻量级容错库
+- [Token Bucket 算法详解](https://en.wikipedia.org/wiki/Token_bucket) - 令牌桶算法的数学原理