项目中预构建和配置文件中优化的区别

在项目中引入预构建的 vendor.dll.js（通过 <script> 标签直接加载）和直接在配置文件中优化打包/代码分割（如 Webpack 的 splitChunks）是两种不同的依赖管理策略，它们的核心区别如下：

---

1. 预构建 vendor.dll.js（DLL 方式）

原理

• 使用 Webpack 的 DllPlugin 提前将第三方库（如 vue、axios）打包成一个独立的 vendor.dll.js 文件，并通过 DllReferencePlugin 在主构建中引用。
• 配套的 vendor.manifest.json 用于描述 vendor.dll.js 中的模块信息。

优点

• 构建速度极快 ：
  第三方库只需构建一次，后续开发时主构建过程直接跳过这些依赖（尤其适合大型项目）。
• 缓存利用率高 ：
  vendor.dll.js 的文件名通常包含哈希，可长期缓存（除非依赖版本变化）。

缺点

• 配置复杂 ：
  需要维护单独的 DLL 构建脚本和 manifest 文件。
• 灵活性差 ：
  依赖更新时需要手动重新生成 DLL 文件。
• 现代工具支持弱 ：
  Webpack 5 已弃用 DllPlugin，推荐使用更简单的替代方案（如 splitChunks）。

适用场景

• 传统大型项目，依赖稳定且极少变更。
• 需要极致优化开发环境构建速度。

---

2. 直接在配置文件中优化（如 splitChunks）

原理

• 使用 Webpack 的 optimization.splitChunks 或 Vite/Rollup 的代码分割功能，动态将第三方库拆分到单独的 chunk 文件（如 vendor-xxxx.js）。

优点

• 零配置或低配置 ：
  现代工具（如 Webpack 5、Vite）默认支持自动拆分 node_modules。
• 动态优化 ：
  自动根据实际引用情况拆分代码，支持按需加载。
• 维护简单 ：
  依赖更新时无需手动干预，构建工具自动处理。

缺点

• 首次构建较慢 ：
  每次构建都需要分析依赖关系（但可通过缓存缓解）。
• 缓存粒度较细 ：
  每个拆分的 chunk 需单独缓存（需合理配置哈希策略）。

适用场景

• 现代前端项目（尤其是基于 Webpack 5+ 或 Vite）。
• 依赖频繁更新或需要动态加载的场景。

---

关键对比表

对比项	DLL 方式 (vendor.dll.js)	配置文件优化 (splitChunks)
构建速度	极快（依赖预构建）	较慢（需每次分析依赖）
配置复杂度	高（需单独 DLL 配置）	低（现代工具默认支持）
缓存效率	高（整个 vendor 长期缓存）	中（按 chunk 缓存）
依赖更新灵活性	差（需手动重新生成 DLL）	好（自动处理）
适用场景	传统大型项目	现代项目（尤其是 SPA/微前端）

---

如何选择？

1. 优先现代方案 ：

   如果是新项目，直接用 Webpack 5 的 splitChunks 或 Vite 的代码分割，无需折腾 DLL。

   // Webpack 示例
   optimization: {
     splitChunks: {
       chunks: 'all',
       cacheGroups: {
         vendor: {
           test: /[\/]node_modules[\/]/,
           name: 'vendors',
         },
       },
     },
   }

2. 遗留项目优化 ：

   如果已是 DLL 方式且构建速度满意，可以保持，但建议逐步迁移到现代方案。

3. 特殊需求 ：

   如果需要强制分离某些库（如 echarts），可通过 cacheGroups 精细控制：

   cacheGroups: {
     echarts: {
       test: /[\/]node_modules[\/]echarts[\/]/,
       name: 'echarts',
       priority: 10, // 优先级
     },
   }

---

总结

• vendor.dll.js 是传统优化手段，适合特定场景，但已逐渐被现代工具淘汰。
• splitChunks 代码分割 是当前主流方案，兼顾灵活性和性能，推荐优先使用。

根据项目规模和工具链选择最适合的方式即可。