Q10：Vite 的依赖预构建（Pre-bundling）是什么？为什么要这么做？
⏱ 预计阅读时间：4 分钟
原题：Vite 的依赖预构建（Pre-bundling）是什么？为什么要这么做？（提示：解决 CommonJS 兼容和减少网络请求激增；Vite 8 起预构建引擎也从 esbuild 切换到 Rolldown，配置入口从
optimizeDeps.esbuildOptions变为optimizeDeps.rolldownOptions）
🎯 面试官在考什么
- 考点1：预构建解决的两个核心问题——CJS/UMD 兼容 + 网络请求激增
- 考点2：预构建的工作机制（何时触发、产物存在哪里、缓存策略）
- 考点3：Vite 8 预构建引擎从 esbuild 切换到 Rolldown 的变化
✅ 答题框架（建议顺序）
- 先说预构建是什么：Vite 在开发服务器启动前，将 node_modules 中的依赖提前打包成浏览器可识别的 ESM 格式，缓存到
node_modules/.vite/deps/目录 - 再说为什么需要：两个核心问题——①许多 npm 包只提供 CJS/UMD 格式，浏览器原生 ESM 无法直接 import ②有些包含大量内部模块（如 lodash-es 有 600+ 子模块），不预构建会导致浏览器发起数百个请求（瀑布流问题）
- 最后说 Vite 8 的变化：预构建引擎从 esbuild 切换到 Rolldown，配置入口从
optimizeDeps.esbuildOptions变为optimizeDeps.rolldownOptions。好处是预构建和生产的模块处理逻辑统一，消除了之前因 esbuild/Rollup 转换差异导致的开发/生产行为不一致
⚠️ 常见踩坑
- 认为预构建处理的是项目源码 → 预构建只处理 node_modules 中的第三方依赖，项目自身的源码是按需编译的，不参与预构建
- 忽略预构建缓存失效的条件 → 以下任一变化会导致缓存失效并重新预构建：
lockfile变化、optimizeDeps.include/exclude变化、optimizeDeps.rolldownOptions变化（Vite 8）、Node.js 版本变化 - 在 Vite 8 中仍用
optimizeDeps.esbuildOptions→ 此配置在 Vite 8 中由兼容层自动映射，但建议迁移到optimizeDeps.rolldownOptions以获得更好的类型提示和行为一致性
💎 加分项
- 提到预构建的 强制包含 配置：
optimizeDeps.include可以显式声明需要预构建的包，解决某些包被动态 import 导致未被自动发现的问题 - 提到 Vite 8 的 Full Bundle Mode（实验性）：开发阶段也对所有模块执行完整打包，进一步减少浏览器请求数，开发服务器启动快 3 倍、全量重载快 40%
- 提到预构建产物的 强 ESM 规范化：将 CJS 的
module.exports重写为 ESM 的export default，并通过代理模块处理命名导出，确保浏览器端行为一致
📚 关键知识点速查
- 依赖预构建（Pre-bundling）：Vite 启动时将 node_modules 中的依赖提前打包为 ESM 格式，缓存到
.vite/deps/ - CJS/UMD 兼容：浏览器原生 ESM 无法直接 import CJS/UMD 模块，预构建将其转换为 ESM
- 网络请求激增：未经预构建的包（如 lodash-es）可能触发数百个模块请求，预构建将其合并为单文件
optimizeDeps.include：显式声明需要预构建的包，解决动态 import 场景下的自动发现遗漏optimizeDeps.rolldownOptions：Vite 8 新的预构建配置入口，替代旧的esbuildOptions- 缓存失效：lockfile / 配置 / Node 版本变化会触发重新预构建，保证依赖一致性
优先级：🔴高频
