标题提到的Vite 4.0，在本文写作时（2022年10月）尚未正式发布，正式版于2022年12月发布。本文基于Vite 3.0的源码和Vite 4.0的爆料信息，深入剖析Vite的底层机制。

很多人用Vite，只知道它快，但不知道为什么快。本文从源码层面，深入剖析Vite的底层机制，包括开发服务器原理、依赖预构建、模块解析、HMR原理、构建原理、插件机制，以及Vite为什么快。

一、Vite的整体架构

1. 两大组成部分

Vite由两大部分组成：

开发服务器（Dev Server）：

  • 基于Koa的HTTP服务器
  • 利用浏览器原生ES模块
  • 按需编译，不打包
  • 提供HMR（热模块替换）

构建工具（Build）：

  • 基于Rollup
  • 生产环境打包
  • 代码分割、tree-shaking、压缩
  • 输出优化后的静态文件

2. 为什么分两部分

开发环境和生产环境的需求不同：

  • 开发环境：追求启动速度和热更新速度，不需要打包
  • 生产环境：追求加载性能和兼容性，需要打包

所以Vite用了两套不同的机制：开发环境用原生ES模块，生产环境用Rollup打包。

3. 核心思想

Vite的核心思想：

  • 开发环境：不打包，利用浏览器原生ES模块，按需加载
  • 依赖预构建：用ESBuild预构建依赖，减少请求
  • HMR：只更新变更的模块，不刷新页面
  • 生产环境：用Rollup打包，优化输出

二、开发服务器原理

1. 基于Koa

Vite的开发服务器，基于Koa。

Koa是一个轻量级的Node.js Web框架，中间件机制很灵活。

Vite的开发服务器，由一系列中间件组成：

  • 静态文件服务中间件
  • 模块解析中间件
  • 转换中间件（编译TypeScript、JSX等）
  • HMR中间件
  • 代理中间件
  • 错误处理中间件

每个中间件处理一个环节，请求经过中间件链，最终返回处理后的结果。

2. 原生ES模块

Vite利用浏览器原生ES模块。

在HTML中：

<script type="module" src="/src/main.js"></script>

浏览器请求main.js，Vite服务器返回编译后的JS。main.js中import了其他模块，浏览器再请求这些模块。

这样，Vite不需要打包整个项目，浏览器请求哪个模块，就编译哪个模块。启动速度和项目大小无关。

3. 按需编译

Vite的编译是按需的：

  • 浏览器请求哪个模块，就编译哪个模块
  • 编译结果缓存起来，下次请求直接返回缓存
  • 文件变化时，清除对应模块的缓存

按需编译，是Vite快的关键之一。项目再大，启动也只需要编译入口文件，不用全部编译。

三、依赖预构建

1. 为什么需要预构建

依赖预构建，是Vite的核心机制之一。

为什么需要预构建：

  • CommonJS兼容：很多依赖是CommonJS格式，浏览器不支持
  • 性能优化：一个依赖可能有很多小文件，逐个请求很慢，打包成一个文件减少请求
  • 缓存：预构建的依赖缓存起来，不用每次都重新构建

2. ESBuild预构建

Vite用ESBuild预构建依赖。

ESBuild是用Go写的打包器，速度极快，比JavaScript写的打包器快10-100倍。

预构建的过程：

  • 扫描项目中的import，找出所有依赖
  • 用ESBuild把每个依赖打包成单个ES模块文件
  • 存到node_modules/.vite目录下
  • 项目中import依赖时，重定向到预构建的文件

3. 预构建的缓存

预构建的结果会缓存：

  • 缓存目录：node_modules/.vite
  • 缓存键：依赖的版本、Vite的配置
  • 依赖变化时，重新预构建
  • 可以用--force强制重新预构建

缓存机制，保证了预构建只在第一次启动或依赖变化时执行，平时启动直接用缓存。

4. 预构建的配置

可以通过配置优化预构建：

export default {
  optimizeDeps: {
    include: ['some-dep'],  // 强制预构建
    exclude: ['some-dep'],  // 不预构建
    entries: ['index.html'], // 入口文件
    esbuildOptions: {
      // ESBuild的配置
    }
  }
}

四、模块解析

1. 路径解析

Vite需要解析模块的路径：

  • 绝对路径：/src/main.js
  • 相对路径：./utils.js
  • 裸模块：vue、lodash（需要重定向到预构建的依赖）
  • 别名：@/utils（需要解析别名配置）

Vite的模块解析，基于Node.js的模块解析算法，并做了扩展。

2. 重写import

Vite会重写JS文件中的import语句：

// 原始代码
import { createApp } from 'vue'
import App from './App.vue'
import utils from '@/utils'

// 重写后
import { createApp } from '/node_modules/.vite/vue.js'
import App from '/src/App.vue'
import utils from '/src/utils/index.js'

重写的目的：

  • 裸模块重定向到预构建的依赖
  • 相对路径转成绝对路径
  • 别名解析成实际路径
  • 加上文件扩展名（浏览器需要）

3. 特殊模块的处理

Vite对一些特殊模块做了处理：

  • .vue文件：编译成JS模块（template、script、style分开处理）
  • .css文件：编译成JS，动态插入style标签
  • .json文件：转成ES模块，导出对象
  • 图片等资源：返回URL
  • ?raw：返回文件原始内容
  • ?url：返回文件URL

五、HMR原理

1. 什么是HMR

HMR（Hot Module Replacement，热模块替换），是指修改代码后，不刷新页面，只更新变更的模块。

HMR的好处：

  • 保留应用状态
  • 更新速度快
  • 开发体验好

2. HMR的流程

Vite的HMR流程：

  1. 文件变化：开发者修改了文件
  2. 服务器检测：Vite用chokidar监听文件变化
  3. 分析影响：分析这个模块的依赖关系，找出受影响的模块
  4. WebSocket通知：通过WebSocket通知浏览器，哪些模块更新了
  5. 浏览器请求：浏览器请求更新的模块
  6. 替换模块：用新模块替换旧模块
  7. 执行accept回调：如果模块注册了HMR accept回调，执行回调

3. HMR边界

HMR有一个概念叫"HMR边界"。

不是所有模块都能热更新。一个模块修改后，Vite会向上找，找到第一个"接受"HMR的模块，这个模块就是HMR边界。

比如：

  • 修改了一个工具函数，这个函数被很多地方引用
  • 如果这些地方都没有accept HMR，就会冒泡到根模块
  • 根模块也没有accept，就会刷新页面

所以，框架（如Vue、React）会提供HMR支持，让组件可以热更新。

4. Vue的HMR

Vue文件的HMR，由@vitejs/plugin-vue处理：

  • 修改template：重新渲染组件，保留状态
  • 修改script：重新创建组件，状态可能丢失
  • 修改style：只更新样式，不重新渲染

Vue的HMR体验很好，修改代码后，页面几乎即时更新，状态保留。

六、构建原理

1. 基于Rollup

Vite的生产构建，基于Rollup。

Rollup是一个基于ES模块的打包器，tree-shaking很好，输出干净。

Vite在Rollup的基础上，做了很多优化：

  • 预配置了常用的插件
  • 代码分割策略
  • 资源处理
  • 压缩优化

2. 构建流程

Vite的构建流程：

  1. 解析配置
  2. 收集入口文件
  3. 用Rollup打包
  4. 代码分割
  5. 资源处理（图片、字体等）
  6. 压缩（JS、CSS、HTML）
  7. 输出到dist目录

3. 代码分割

Vite的代码分割策略：

  • 入口文件：每个入口一个chunk
  • 第三方依赖：node_modules中的依赖，单独打包
  • 动态导入：import()的模块，单独打包
  • 公共代码：多个入口共用的代码，单独打包

代码分割的目的：

  • 并行加载，提高加载速度
  • 按需加载，减少首屏加载量
  • 利用浏览器缓存，依赖不变就不用重新下载

4. 压缩

Vite支持两种压缩方式：

  • esbuild：快，压缩率一般
  • terser：慢，压缩率高

默认用esbuild，因为快。如果对体积要求高，可以换成terser。

七、插件机制

1. 基于Rollup插件

Vite的插件机制，基于Rollup插件，并做了扩展。

Vite插件 = Rollup插件 + Vite特有钩子。

Rollup插件的钩子：

  • options：获取配置
  • buildStart：构建开始
  • resolveId：解析模块ID
  • load：加载模块
  • transform：转换模块
  • buildEnd：构建结束
  • generateBundle：生成产物

Vite特有的钩子：

  • config：修改Vite配置
  • configureServer：配置开发服务器
  • transformIndexHtml：转换HTML
  • handleHotUpdate：处理HMR更新

2. 插件的执行顺序

Vite插件的执行顺序：

  1. 别名解析（alias）
  2. 预构建相关
  3. 用户插件（按顺序）
  4. 内置插件（Vue、CSS等）
  5. 构建相关

插件的顺序很重要，顺序不对可能导致问题。

3. 常用插件

Vite的常用插件：

  • @vitejs/plugin-vue：Vue支持
  • @vitejs/plugin-react：React支持
  • @vitejs/plugin-legacy：旧浏览器兼容
  • vite-plugin-imagemin：图片压缩
  • unplugin-auto-import：自动导入
  • unplugin-vue-components：组件自动注册

八、Vite为什么快

总结一下，Vite为什么快：

1. 开发环境不打包

这是最核心的原因。

Webpack在开发环境也要打包，项目越大，打包越慢。Vite利用浏览器原生ES模块，不打包，启动速度和项目大小无关。

2. 按需编译

Vite只编译浏览器请求的模块，不编译整个项目。

Webpack要编译整个项目，Vite只编译当前页面需要的模块。

3. ESBuild预构建

依赖预构建用ESBuild，速度极快。

ESBuild用Go写的，比JavaScript打包器快10-100倍。

4. HMR快

Vite的HMR只更新变更的模块，不重新打包。

Webpack的HMR要重新打包相关模块，项目越大越慢。Vite的HMR速度和项目大小无关。

5. 缓存

Vite有多层缓存：

  • 依赖预构建缓存
  • 模块编译缓存
  • 文件系统缓存

缓存命中时，速度极快。

九、Vite 4.0的新特性

根据爆料，Vite 4.0可能有这些新特性：

1. React SWC支持

用SWC代替Babel编译React，速度更快。

2. 环境变量改进

更灵活的环境变量配置，支持更多场景。

3. 插件API改进

更强大的插件系统，更多钩子。

4. 性能优化

更快的启动和构建。

5. Rolldown（未来）

有传言说Vite未来会用Rolldown（Rust写的Rollup兼容打包器），进一步提升构建速度。但Vite 4.0可能不会用，可能在Vite 5.0或更晚。

注意：Vite 4.0在本文写作时尚未发布，具体特性以正式版为准。

十、Vite的局限

Vite虽然快，但也有局限：

1. 只支持现代浏览器

开发环境只支持支持原生ES模块的现代浏览器。旧浏览器需要用@vitejs/plugin-legacy。

2. 生态不如Webpack

Vite比较新，插件和工具不如Webpack丰富。虽然发展很快，但还有差距。

3. 一些Webpack特性不支持

比如，Webpack的一些高级特性，Vite可能不支持或支持不好。

4. 大型项目的构建

虽然开发环境快，但大型项目的生产构建，还是需要时间。Rollup的构建速度，不如ESBuild。

十一、写在最后

Vite的快，不是魔法，而是一系列设计的结果：

  • 开发环境不打包，利用原生ES模块
  • 按需编译，只编译请求的模块
  • ESBuild预构建依赖，速度极快
  • HMR只更新变更模块
  • 多层缓存，提高重复访问速度

理解了这些原理，就能更好地使用Vite，遇到问题也能更快定位。

2022年了，Vite已经发展到3.x，4.0也即将发布。它的生态越来越成熟，性能越来越强。如果你还在用Webpack，可以考虑试试Vite，体验一下"秒开"的感觉。

最后，用一句话总结："Vite的快，源于不打包。理解了原生ES模块和按需编译，就理解了Vite的核心。"

愿你的开发体验，越来越快。