跳到主要内容

Vite 总览

Vite 现在已经不是“那个开发很快的新工具”了。它已经走过几轮大版本迭代，角色也从现代前端项目里的高效开发方案，慢慢往更完整的工具链主轴上靠。

如果印象还停在“开发阶段快、生产构建走 Rollup”，这个理解已经有点早了。到 Vite 8 和 Vite+ 这条线之后，更值得关注的是底层统一、环境抽象、构建基线和工具链收束。

建议阅读顺序​

  1. Vite 经典配置与前端集成
  2. Vite 版本演进
  3. Vite+

Vite 到底解决什么问题​

最初的痛点很明确：

  • 本地开发启动慢
  • 模块一多，HMR 越来越钝
  • 构建工具配置越来越重
  • 前端项目需要一套更贴近原生 ESM 的开发模型

Vite 的切入方式很直接：把“开发时怎么加载模块”和“生产时怎么输出产物”拆开处理。

早期 Vite 的核心模型​

开发阶段​

  • 基于原生 ESM 按需加载模块
  • 只在访问时处理当前模块
  • HMR 影响范围更小
  • 启动不需要先把整棵依赖树全量打包完

生产构建阶段​

  • 早期主线长期基于 Rollup
  • 负责代码分割、资源处理、压缩和产物输出

这也是很多人第一次接触 Vite 时最深的印象：开发很轻，构建很稳。

现在看 Vite，重点已经变了​

近几次大版本之后，Vite 的关注点不再只是“快”，而是：

  • 构建底层开始逐步统一
  • Environment API 把运行环境抽象做得更完整
  • 和现代前端基线的关系更紧
  • 开始和 Vite+ 一起向更完整的工具链方案延伸

日常最常碰到的几块能力​

别名和路径解析​

import { defineConfig } from 'vite'
import path from 'node:path'

export default defineConfig({
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'),
    },
  },
})

开发代理​

本地联调接口时，server.proxy 仍然是最常见的一层。

环境变量​

import.meta.env 是 Vite 项目里默认的环境变量入口。更要紧的是分清：哪些变量会进浏览器，哪些内容压根不该暴露。

插件系统​

Vite 插件生态强，一个重要原因就是它和 Rollup 系谱靠得很近。很多经验不是从零开始重新积累的。

SSR 与 library mode​

Vite 并不只适合 SPA。SSR、库构建、monorepo、工具类项目，它都已经有比较成熟的路径。

什么时候优先考虑 Vite​

  • 新项目
  • 现代浏览器目标环境
  • 更看重开发体验和反馈速度
  • 团队希望构建配置保持适度克制

什么时候要多算一步​

  • 历史 Webpack 体系很深
  • 构建链路高度定制
  • 对某些底层 loader / plugin 依赖很重
  • 需要和特殊运行环境做深度绑定