第 31 章：实战：范围与需求定义 ​

理论的探索终将回归实践的沃土。在本书的前九个部分，我们已经像解剖学家一样，深入剖析了 Vite 内部的每一个“器官”：开发服务器、插件系统、模块图、HMR、构建流程…… 我们理解了它们各自的功能以及它们之间是如何协同工作的。

现在，我们将扮演“造物主”的角色，亲手构建一个属于我们自己的、简化版的 Vite——mini-vite。这个过程不仅是对前面所有理论知识的终极检验，更是一次激动人心的创造之旅。

在开始编写第一行代码之前，一个至关重要的步骤是：定义范围与需求。这就像在建造一艘船之前，我们必须先确定这艘船是用于湖中泛舟的皮划艇，还是用于远洋航行的万吨巨轮。明确的目标将决定我们的技术选型、架构设计和实现优先级。

mini-vite 的核心目标：聚焦于“快”的本质 ​

Vite 的核心价值主张是其闪电般的 开发服务器启动速度 和 热模块更新（HMR）速度。这一切都源于它创新的、基于浏览器原生 ES 模块（ESM）的架构。因此，我们的 mini-vite 也必须将这两个核心特性作为最高优先级。

我们的目标不是复制 Vite 的全部功能，而是要抓住其精髓。mini-vite 的使命是：

构建一个功能最小化但核心理念与 Vite 完全一致的现代前端开发服务器。

这意味着，我们将专注于实现那些直接支撑“快速开发”的核心机制，而有策略地忽略那些与核心无关或过于复杂的边缘功能。

功能需求清单：我们要实现什么？ ​

根据我们的核心目标，我们将 mini-vite 的功能需求分解为以下几个关键模块。这就像是我们“皮划艇”的施工蓝图。

1. 核心开发服务器 (Core Dev Server) ​

这是 mini-vite 的骨架。它必须能够：

• 启动一个本地 HTTP 服务器：使用 Node.js 的 http 模块，监听一个指定端口。
• 提供静态资源服务：能够正确处理对 HTML、图片等静态文件的请求。
• 拦截和转换 JavaScript/TypeScript 请求：这是核心中的核心。当浏览器请求一个 .js、.ts 或 .jsx 文件时，服务器不能直接返回源文件，而是需要：
  • 读取文件内容。
  • 调用转换器（我们将使用 esbuild）将其转换为浏览器可执行的 JavaScript。
  • 将转换后的代码返回给浏览器。
• 重写裸模块导入路径：将 import React from 'react' 这样的“裸模块”路径，重写为浏览器可以理解的、指向 node_modules 中具体文件的路径，例如 import React from '/node_modules/react/index.js'。

2. 模块图与依赖分析 (Module Graph) ​

为了实现高效的 HMR，服务器必须在内存中维护一个模块依赖图。这个图需要记录：

• 模块节点：每个被请求过的文件都是一个节点。
• 依赖关系：记录每个模块 import 了哪些其他模块（importedBy），以及它被哪些模块所 import（importers）。
• 转换结果缓存：缓存每个模块的转换结果，避免对未变更的文件进行重复转换。

3. 热模块更新 (HMR) ​

这是 mini-vite 的灵魂。当一个文件发生变更时，mini-vite 需要能够：

• 监听文件变更：使用 chokidar 等库监听项目源文件的增、删、改。
• 定位更新边界：当一个文件变更时，根据模块图向上查找，直到找到一个能够“接受”该更新的模块（即调用了 import.meta.hot.accept 的模块），或者到达根节点。
• 建立 WebSocket 通信：启动一个 WebSocket 服务器，并在客户端（浏览器）和服务器之间建立持久连接。
• 推送 HMR 消息：向客户端发送一个精确的 HMR 载荷（Payload），告诉客户端哪个模块需要更新，以及更新的类型（update 或 full-reload）。
• 注入 HMR 客户端：向 index.html 中自动注入一段客户端脚本，该脚本负责连接 WebSocket、接收消息并执行热替换逻辑。

4. 简化版插件系统 (Simplified Plugin System) ​

Vite 的强大之处在于其可扩展的插件系统。mini-vite 将实现一个极简的插件模型，以理解其核心思想。这个系统至少需要支持：

• resolveId 钩子：用于解析模块的导入路径，这是实现裸模块重写的关键。
• load 钩子：用于加载模块的源代码。
• transform 钩子：用于转换模块的源代码。

我们不实现什么？(Non-Goals) ​

同样重要的是要明确我们 不 做什么。这将帮助我们保持专注，避免项目范围的无休止膨胀。

• 复杂的配置系统：mini-vite 将使用硬编码的配置，而非像 Vite 那样支持 vite.config.js 文件和大量的配置选项。
• 依赖预构建（Pre-bundling）：Vite 使用 esbuild 对依赖进行预构建以提升性能和处理 CommonJS 模块。mini-vite 将跳过这一步，假设所有依赖都是 ESM 格式。
• 生产环境构建（build 命令）：我们将只关注开发服务器，不实现基于 Rollup 的生产环境打包功能。
• SSR：虽然我们前面章节深入探讨了 SSR，但为了保持核心实现的简洁，mini-vite 将不包含 SSR 功能。
• 对 CSS 和静态资源的复杂处理：我们将只提供基础的静态服务，不处理 CSS 的代码分割、预处理器等。
• 大量的内置插件：Vite 内置了大量插件来处理各种文件类型和框架集成。mini-vite 将只关注核心的 JS/TS 转换。

总结 ​

通过这份清晰的需求清单，我们为 mini-vite 的构建之旅设定了明确的航标。我们的目标是小而美的——一个能够清晰地、可运行地展示 Vite 核心工作原理的教学项目。

在接下来的章节中，我们将按照这份蓝图，一步一个脚印地将 mini-vite 从概念变为现实。准备好，我们的编码之旅即将开始！