这几年做前端项目，我越来越依赖Vite。

尤其是在Vue 3 + TypeScript项目里，Vite基本已经成了很自然的选择。

刚开始用Vite的时候，最直接的感受就是：

启动项目真的很快。

但真正了解之后才发现，Vite的核心并不是简单地"比Webpack优化得更好"。

它解决开发环境问题的思路，本身就不太一样。

传统打包工具的问题

传统前端开发流程，通常需要先构建依赖关系。

简单来说：

源代码
 ↓
解析模块
 ↓
构建依赖图
 ↓
打包
 ↓
启动开发服务器

项目越大，需要处理的模块越多，第一次启动的成本就越明显。

而Vite在开发环境下采用了不同的思路。

Vite利用了浏览器原生ES Module

现代浏览器本身已经支持ES Module。

比如：

import { add } from './math.ts'

Vite开发服务器并不会像传统打包器那样，把整个项目先打包成一个巨大bundle。

浏览器请求哪个模块，开发服务器就处理哪个模块。

所以流程更接近：

浏览器
 ↓
请求index.html
 ↓
请求main.ts
 ↓
请求App.vue
 ↓
继续请求依赖

这就是为什么大型项目的启动速度也能保持得比较快。

那node\_modules怎么办？

第三方依赖通常不是直接就能用的。

Vite会对依赖进行预构建。

比如：

node_modules
      ↓
依赖预构建
      ↓
浏览器可使用的模块

这个过程主要由esbuild等工具参与完成。

因为第三方依赖通常不会频繁变化，所以预构建结果可以被缓存。

热更新为什么很快

Vite另一个体验很好的地方是HMR。

比如我修改了：

src/components/UserList.vue

传统流程可能需要重新构建大量模块。

而Vite可以直接定位到发生变化的模块。

大致过程：

修改UserList.vue
        ↓
Vite检测文件变化
        ↓
定位模块
        ↓
发送HMR更新
        ↓
浏览器更新

所以开发时通常只需要很短的时间就能看到修改结果。

Vite配置并不需要很复杂

一个基础的Vue项目：

import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

export default defineConfig({
  plugins: [
    vue()
  ]
})

然后：

npm run dev

就可以启动开发服务器了。

随着项目增长，再慢慢加入：

resolve: {
  alias: {
    '@': '/src'
  }
}

或者：

server: {
  port: 3000
}

没必要一开始就把配置文件写得特别复杂。

开发环境和生产环境是两回事

这也是刚开始用Vite时比较容易搞混的地方。

Vite的开发模式主要追求：

• 快速启动
• 快速模块加载
• 快速HMR

而生产环境仍然需要完整构建：

npm run build

生产构建会对代码做：

• 模块处理
• Tree Shaking
• 代码压缩
• Chunk拆分
• 静态资源处理

所以不能简单理解成：

Vite不需要打包。

更准确的说法是：

Vite在开发环境尽可能减少不必要的打包工作，生产环境仍然需要构建优化。

Vite对现代前端开发的意义

我觉得Vite最大的价值不是"构建速度快"这么简单。

它实际上改变了前端开发服务器的工作方式。

过去：

代码
 ↓
打包
 ↓
开发服务器
 ↓
浏览器

现在：

源代码
 ↓
开发服务器
 ↓
浏览器原生模块

再结合快速的依赖预构建和HMR，开发体验的提升确实很明显。

对于现在的Vue 3 + TypeScript项目，我基本已经把Vite当成默认的基础设施了。