feat: 添加多个附录交互式组件和文档更新

- 添加浏览器前端组件：无障碍访问、国际化、实时通信 - 添加 Transformer 注意力机制系列组件 - 更新 Canvas、数据追踪等现有组件 - 修复 ESLint 变量名冲突问题 - 完善相关附录文档
2026-02-24 08:34:53 +08:00
parent 94f9db0834
commit 260d17ee8b
42 changed files with 5290 additions and 12173 deletions
@@ -1,3 +1,75 @@
-# 实时通信（WebSocket / SSE）
+# 实时通信机制（Polling / SSE / WebSocket）

-> 待实现
+::: tip 核心导读
+**浏览器如何实现数据的实时更新？** 
+传统的 HTTP 协议基于“请求-响应”模型，客户端必须主动发起请求，服务端才能返回数据。如果我们需要实现聊天室、股票行情推送等实时场景，这种模型将面临挑战。
+
+本章将介绍前端应对实时数据通信的三种主要技术：短轮询（Polling）、服务器推送事件（SSE）与全双工 WebSocket，并探讨它们的原理与适用场景。
+:::
+
+---
+
+## 1. 传统 HTTP 的局限性
+
+HTTP 协议的设计初衷是用于文档检索，它具有**无状态（Stateless）**和**由客户端单向发起**的特点：
+1. 客户端发起 HTTP 请求。
+2. 服务端处理请求并返回响应。
+3. 连接完成任务后通常会释放对应的逻辑请求（HTTP/1.1 虽然支持长连接复用，但业务层面的请求-响应模型并未改变）。
+
+在此模式下，服务端无法主动将状态的改变随时通知正在等待的客户端。为了获取最新数据，必须寻找其他技术架构方案。
+
+---
+
+## 2. 短轮询（Polling）
+
+最直接的解决方案是**短轮询**。即客户端利用定时器（如 `setInterval`），每隔一段固定的时间，自动向服务端发送 HTTP 请求，询问是否有新数据到达。
+
+<PollingDemo />
+
+**技术特点与局限：**
+- **优点**：实现机制极其简单，完全依赖标准的 HTTP 协议和 AJAX/Fetch 技术。
+- **缺点**：可能产生巨大的网络开销与资源浪费。大多数时间里，服务端的响应可能是“无新数据”。无论有无数据，每次请求都需要携带完整的 HTTP 头部（Headers、Cookies 等），在并发量较高的场景下，会导致网络资源被大量无意义的查询占据。
+
+---
+
+## 3. 服务器推送事件（Server-Sent Events）
+
+为了降低频繁建立 HTTP 连接的开销，**Server-Sent Events (SSE)** 提供了一种轻型的单向数据流推送架构。
+
+SSE 建立在 HTTP 协议之上。客户端发起一个包含特殊请求头（`Accept: text/event-stream`）的 HTTP 请求后，服务端在返回响应时会保持底层的 TCP 连接不断开。随后，服务端可以通过这条持久的通道，持续不断地向客户端推送文本格式的数据。
+
+<SSEDemo />
+
+**技术特点与局限：**
+- **优点**：连接持久化，网络开销小；浏览器原生支持断线自动重连机制；非常适合从服务端向客户端**单向**传输流式数据（例如大语言模型的文本逐字输出、实时交易行情推送）。
+- **缺点**：通信通道是单向的。如果客户端需要向服务端发起控制指令或发送新数据，必须另外建立普通的 HTTP 请求。
+
+---
+
+## 4. WebSocket：全双工通信协议
+
+当应用场景涉及高频的双向交互（如多人在线动作游戏、精密的协同文档编辑）时，我们需要一种既能降低通信开销，又能实现真正双工通信的技术——**WebSocket**。
+
+WebSocket 是一种独立的网络通信协议。它精妙地借助了 HTTP 协议来完成初始建连：
+1. **握手阶段**：客户端发送一个特殊的 HTTP 请求，声明希望将其升级为新协议（携带 `Upgrade: websocket` 头部）。
+2. **连接质变**：服务端若支持并同意该协议，则回复 `101 Switching Protocols` 状态码。
+3. **彻底自由**：此时 HTTP 的规范使命结束，底层的 TCP 连接被移交给 WebSocket 协议。此后，客户端与服务端享有平等的全双工（Full-Duplex）通信权利，双方可随时收发极简格式的数据帧。
+
+<WebSocketDemo />
+
+**技术特点与局限：**
+- **优点**：支持真正意义上的双向实时通信；数据帧的头部信息极小，通信延迟低、吞吐效率高；支持原生二进制数据（ArrayBuffer）的传输。
+- **缺点**：架构与开发复杂性较高；由于维护着持久长连接，对服务器端的系统架构、负载均衡策略和心跳监测设计提出了更严格的工程要求。
+
+---
+
+## 5. 总结：技术选型对比
+
+| 维度 | 短轮询 (Polling) | 服务器推送事件 (SSE) | WebSocket |
+| :--- | :--- | :--- | :--- |
+| **通信方向** | 客户端主动轮询拉取 (单向) | 服务端持续主动推送 (单向) | 客户端与服务端享有平等收发权 (双向全双工) |
+| **底层协议** | 标准 HTTP | 标准 HTTP | 独立的 WebSocket 协议 (基于 TCP) |
+| **数据开销** | 极高 (包含完整的 HTTP 头部) | 较低 | 极低 (极简的数据帧头部) |
+| **典型应用场景** | 定时检查后台异步任务的完成状态 | 大模型对话单向流输出、新闻或系统通知推送 | 实时音视频信令、多人在线对战、协同白板与编辑 |
+
+在实际工程中，开发者应依据具体业务场景对实时性与双向交互频率的要求，在系统的维护复杂度和通信效率之间取得平衡，选择最契合的技术栈。