[!info] 关联笔记

• 对象：Vite
• 路线：Vite 学习路线 MOC
• 后续：开发与构建双路径 · 依赖预构建 · HMR 与模块图

Vite 的设计动机

这个概念为什么出现

当应用从“几个 jQuery 文件”长成“数千模块的组件树”后，传统打包器开发模式（先打包再服务）会在两个体验上失真：

1. 冷启动：改一行也要等整图构建思路的残余成本，或至少处理巨大依赖图
2. 热更新：模块变了却难以精确只让相关边界失效，HMR 变慢甚至整页刷新

Vite 的回答不是“把同一条打包管线优化 10%”，而是承认：开发时浏览器已经能理解 ESM，源码可以按需编译；生产环境才需要为缓存、兼容与部署做打包。

[!abstract] 一句话理解 Vite 把“开发反馈速度”和“生产产物约束”拆开优化：开发站在原生 ESM 与 esbuild 预构建上，生产站在 Rollup 上。

最小可对照示例

场景：订单后台从 3 个页面长到 300 个路由模块

团队每天早上打开 npm start，打包器要把业务源码与 node_modules 依赖图先理顺，咖啡凉了才出页面。改一个 OrderStatusBadge.tsx，HMR 有时牵连半棵树。
下面不是完整 Vite 源码，而是开发请求路径的对照模型：浏览器直接请求模块，工具只编译被点到的文件。

传统打包器开发（简化）:
  源码 + 依赖 ──打包/构建图──> 大 bundle ──> 浏览器

Vite 开发（简化）:
  浏览器 ──GET /src/pages/OrderList.tsx──> Vite 按需转换 ──> 浏览器
  浏览器 ──GET /node_modules/.vite/deps/vue.js──> 预构建依赖（缓存）

建议观察：

pnpm create vite demo-order --template vue-ts
cd demo-order && pnpm i && pnpm dev
# 打开 Network：源码以 .tsx/.vue 模块形式请求，而非单一 app.js 巨包

期望现象：

首屏只转换入口链路相关模块；
修改单个组件时，多数情况下局部 HMR，而不是全量重打包心智。

结合场景再看三个关注点

1. 按需：没打开的路由模块不必在启动时全部编译完。
2. 依赖预构建：node_modules 里 CJS/巨型包不适合直接当上千次 ESM 请求。
3. 生产仍打包：上线要少请求、强缓存、tree-shake——这是 Rollup 路径的职责。

核心概念与准确模型

压力	设计选择	直接收益	代价/边界
冷启动慢	源码原生 ESM + 按需编译	启动与页面切换反馈快	需现代浏览器/dev 目标
依赖请求风暴	esbuild 依赖预构建	合并与转换依赖	要理解 optimizeDeps 缓存
HMR 不准	模块图精确失效	局部更新	特定边界仍会 full reload
生产质量	Rollup 构建	生态与拆包成熟	dev/prod 行为可能有差，需验证

设计动机

1. 承认平台能力变化：浏览器 ESM 已足够支撑 dev 主路径。
2. 用对的工具做对的阶段：esbuild 适合高速转换/压缩依赖；Rollup 适合应用打包语义。
3. 统一插件体验：尽量让插件在 dev/build 间复用，降低工具分裂。

常见误区

[!warning] 常见误区：Vite = 只是更快的 Webpack 速度是结果；模型变化才是原因。把 loader 全家桶心智原样搬来，会错过 ESM 按需与预构建边界。

工程实践

• 新建项目优先官方模板，先跑通再加代理与别名。
• 任何“dev 正常 prod 挂”优先对比双路径差异，而不是只调一个 flag。
• 与框架集成时，框架插件负责 JSX/SFC 等转换，Vite 负责模块图与构建编排。

本节总结

Vite 的设计起点是开发服务器模型的换代，不是皮肤级性能补丁。理解动机后，再读双路径、预构建与 HMR 才不会变成配置备忘录。

自测题

1. 为什么依赖要预构建，而业务源码开发时按需编译？
2. 为什么生产还需要打包？

参考答案

1. 业务源码常改、应按需；依赖少改但模块多/格式杂，预构建可缓存并降请求。
2. 生产要考虑 HTTP 请求数、缓存粒度、tree-shaking 与部署兼容，打包仍更合适。

延伸阅读与资料来源

资料	类型	支撑内容
Vite Guide	官方文档	为什么构建、主特性
Vite Features	官方文档	能力边界