3. 开发与构建的边界 ​

我们已经知道，Vite 有两种截然不同的工作模式：

• 在开发时，它使用一个基于原生 ES 模块的开发服务器，追求极致的速度和响应能力。
• 在构建时，它使用 Rollup 将我们的代码打包成高效、优化的静态文件，准备部署到生产环境。

你可能会问：为什么需要这两种模式？为什么不能用一套方案解决所有问题？

要回答这个问题，我们需要理解开发（Development）和生产（Production）这两个环境的核心目标是完全不同的。

厨师的厨房 vs. 顾客的餐盘 ​

让我们用一个比喻来理解这件事。想象你是一位顶级大厨。

开发环境，就像是你的厨房 (dev)。

在厨房里，你的第一要务是效率和灵活性。你需要：

• 快速拿到食材：你不会把所有食材都提前混合好。相反，你会把它们分门别类地放在手边（就像 Vite 按需提供模块），需要哪个就立刻拿哪个。
• 随时品尝和调整：你炒菜时，会不断地尝味道（就像 HMR），如果淡了就加点盐，如果咸了就加点糖。这个反馈循环必须非常快。
• 清晰的调试：如果一道菜味道不对，你需要能立刻追溯到是哪个食材或哪步操作出了问题（就像在浏览器里直接调试源码）。

在厨房里，你不会太在意摆盘是否精美，或者食材是否被压缩到了最小体积。速度和创造力是这里的主旋律。

生产环境，就像是最终端到顾客面前的餐盘 (build)。

当菜品要上桌时，你的目标变成了最佳的用户体验。你需要：

• 完美的呈现：所有食材都被精心烹饪、组合、摆盘，成为一道色香味俱全的佳肴（就像代码被打包、优化、压缩）。
• 高效的“入口”体验：你不会让顾客一道道菜去点，而是把一整套搭配好的套餐（一个或几个优化过的 JS 包）一次性端上桌，减少顾客的等待时间（减少网络请求）。
• 广泛的“兼容性”：你需要确保这道菜符合大众的口味，即使是一些口味挑剔的顾客也能接受（就像处理浏览器兼容性）。

在餐盘上，你追求的是最终的性能、稳定性和用户满意度。

目标不同，工具自然不同 ​

Vite 的设计哲学正是基于这种清晰的边界划分：

开发模式 (Dev)

• 核心目标：极速的反馈循环、强大的调试能力
• Vite 的策略：原生 ESM 开发服务器
• 优点：冷启动快如闪电、HMR 瞬时完成
• 缺点：页面初次加载时网络请求多、依赖预构建过程复杂

构建模式 (Build)

• 核心目标：最佳的加载性能、更小的代码体积
• Vite 的策略：基于 Rollup 的打包
• 优点：请求次数少、代码经过极致优化、Tree-shaking 效果好
• 缺点：构建过程相对较慢

开发与构建的边界，本质上是两种不同优化目标之间的权衡。

Vite 没有试图用一把“万能钥匙”去开两把完全不同的锁，而是聪明地为每个场景选择了最合适的工具。

• 在开发中，它拥抱现代浏览器的原生能力，把“打包”这个最耗时的步骤延迟到浏览器请求时，从而换来了无与伦比的开发体验。
• 在生产中，它回归到经过千锤百炼的“打包”模式，利用 Rollup 的强大优化能力，确保最终用户的体验达到最佳。

理解了这个边界，你就理解了 Vite 设计思想的精髓。它不仅仅是一个工具，更是一种解决问题的哲学：根据场景定义问题，然后为问题选择最合适的解决方案。

在后续的章节中，我们会看到这个“边界”是如何体现在 Vite 的配置、插件 API 以及内部实现中的。你会发现，Vite 的许多设计决策，都源于对这个边界的深刻理解和尊重。