前言
在前面13篇文章中，我们已经对VITE核心的逻辑进行了分析与阐述，这篇文章我们主要分析VITE提供的preview命令。
在这之前，我对VITE的这个能力还存在很大的疑问，因为在上一篇文章我们也聊过了VITE采用bundless架构存在的一些问题。
提供preview的命令是为了解决Dev阶段和生产内容不一致的问题吗？带着这个问题，我们一起进入今天的学习。
启动流程分析
首先，我们还是要像之前学习dev和build命令一样，我们得从命令行入口开始分析。
VITE提供的preview命令支持预设预览服务器的一些参数，然后导入了preview文件，创建用于预览的服务器。
我以不进行任何配置的情况下，看一下
options这个变量里面的默认值是什么：
接下来，我们就需要看一下preview文件中的实现了。
首先是校验打包的目标产物目录是否存在，不存在的话则直接抛出错误。
从这个位置，我感觉这个preview的目的跟我预想的还是有点儿不一样呢，我之前还以为是可以直接通过预览能够看出来Dev阶段和生产阶段的产物差异呢，如果有这个校验的话，那也就是说预览之前必须得打包，因为VITE的生产环境内容的构建是依赖底层的Rollup，所以当项目比较庞大的时候，这个打包速度仍然是快不起来的。
那我从现在开始对preview命令的定位就比较清楚了，提供preview这个指令可能是VITE为了方便我们尽快的可以预览构建产物。用过Webpack的同学应该都知道吧，Webpack的默认配置的打包结果需要使用一个服务器才能预览。
接着是使用之前我们在阐述DevServer的时候已经提到过的connect包，用它来帮助创建预览服务实例。
然后是收集预览阶段的生命周期
configurePreviewServer，一会儿服务配置完成就可以触发：
接着是配置中间件，其中最重要的就是配置静态资源处理中间件，静态文件中间件执行的目录就是我们配置的产物生成目录：
静态资源的处理，利用的是
sirv这个包，跟在之前Dev阶段时使用的是同一个，有疑问的同学直接查看github这个仓库的API即可。
接下来，把之前搜集到的生命周期统一触发：
接着就可以启动Http服务了：
然后是读取当前的网络情况，若用户配置了自动打开预览服务，可以直接使用默认浏览器打开到对应的页面。
看完这个命令，我觉得VITE确实为开发者考虑了很多，在以前我使用Webpack开发的时候，还自己开发了一个项目用来专门预览构建产物，现在使用VITE就用不上了，方便了很多。
总结
本文的内容相对前面的文章相对简单。
Preview命令用于向用户提供一个傻瓜式的预览构建产物的命令，可以省去自己开发预览构建产物服务器的这一重复的过程。
preview并没有解决在上文中提到的兼容性和一致性的问题，preview仅仅只是帮我们临时部署了一下构建产物，如果在使用这个命令之前没有构建产物，VITE会抛出错误。
VITE在底层还是使用的是Rollup，因为JS生态打包文件的速度相对其它非JS生态的构建工具还是很慢，所以在项目比较大的时候，打包耗时的这个问题在我研究的这个版本的VITE还是无法绕开的（在去年，Rolldown，一款基于Rust语言、完全兼容Rollup的构建工具，已经横空出世了，不知道VITE团队在什么时候迁移，哈哈哈，各位就一起期待好消息吧）
不知不觉，我们对VITE源码的学习已经接近尾声了，在下一篇文章，我们会对VITE的整体进行全面的总结，敬请期待......
