Vite 依赖预构建

解释 Vite 开发阶段用 esbuild 预构建依赖的原因、缓存位置与 optimizeDeps 常见调整场景。

#type / concept #status / growing #tech / dev / frontend #resource / javascript

[!info] 关联笔记

所属：开发服务器与 HMR MOC

前置：双路径

后续：HMR 与模块图

Vite 依赖预构建

这个概念为什么出现

node_modules 里的包常常是：

CommonJS 或混合导出
内部拆成成百上千小文件
开发中很少修改

若浏览器对每个深层文件都发 ESM 请求，开发服务器会被依赖图拖死。预构建把依赖转换成 dev 友好的 ESM，并合并请求。

[!abstract] 一句话理解预构建是开发期对依赖的“缓存型编译”，不是生产 Rollup 的同一过程。

最小可观察示例

场景：接入图表库后首页变慢

// 业务：库存趋势图
import * as echarts from 'echarts'

export function renderStockTrend(el: HTMLElement, points: number[]) {
  const chart = echarts.init(el)
  chart.setOption({
    xAxis: { type: 'category' },
    yAxis: { type: 'value' },
    series: [{ type: 'line', data: points }],
  })
  return chart
}

建议观察：

pnpm dev
# 首次启动日志中的 dependency pre-bundling / optimizing
ls node_modules/.vite/deps 2>/dev/null | head

期望：

依赖被写到 node_modules/.vite/deps 一类缓存目录；
后续冷启动命中缓存则明显更快。

结合场景关注点

改业务源码通常不必重做全部依赖预构建。
增删依赖/改 optimizeDeps 常使缓存失效。
预构建修的是 dev 体验，不能代替 prod 分析。

核心规则

工具：esbuild（高速转换）
配置入口：optimizeDeps.include / exclude
当出现“依赖导出在 dev 下行为怪异”时，优先查是否应强制 include

常见误区

[!warning] 常见误区：把 optimizeDeps 当成万能拆包配置生产拆包看 build.rollupOptions；optimizeDeps 主战场在开发。

本节总结

预构建让“依赖少改、源码常改”的不对称性被正确利用。

自测题

为什么预构建主要针对依赖而不是 src？

参考答案

依赖变更频率低、模块数多、格式复杂；源码需要按需即时编译以保持编辑反馈。

延伸阅读

资料	类型	支撑内容
Dependency Pre-Bundling	官方	机制与配置