Vite由两部分组成：Native-ES-modules-basedserverfordevelopment开发环境NativeES模块构建。基于Rollup的生产构建基于Rollup。传统构建工具存在的问题传统打包工具在开发服务器显示页面之前打包所有引入的依赖项。包括对每个文件的导入/导出关系的完整分析和排序，所有模块的复制和拼接。2应用越大，打包越慢。3代码拆分有利于生产性能，但不利于开发。基于JavaScript的工具存在性能瓶颈，开发服务器启动速度慢，影响开发效率。Vite的优化??方式：Vite在浏览器请求时对源码进行转换，按需提供源码，实际使用时才进行处理。减少了加载页面屏幕之前的打包时间。但是当请求更大的模块时，页面加载速度会变慢。而且当同时请求的模块过多时，也会造成浏览器请求阻塞。所以Vite还有以下优化：依赖预构建。CommonJS和UMD兼容性。Vite必须先将发布为CommonJS或UMD的依赖转换为ESM，在转换CommonJS依赖时，Vite会进行智能导入分析。*保证只为一个模块请求一次预构建。Vite将内部模块较多的ESM依赖转化为单个模块，以提高后续页面加载性能。etag和304未修改。对源码模块的请求会按照304NotModified协商缓存，而对依赖模块的请求会通过Cache-Control强缓存：max-age=31536000,immutable，所以一旦被缓存，就会不需要再次请求。在本机ESM构建模式下，代码拆分会准确地使已编辑模块与其最近的HMR边界之间的链无效，仅更新修改后的模块本身。这意味着代码拆分是开发和生产环境的性能优化。原生ESM不支持如下写法：import{someMethod}from'my-dep'Vite会检测到这种裸模块导入，并预构建它，并将其转换为ESM模式。将导入重写为合法URL，以便浏览器正确导入它们。import{createApp}from'vue'//转换为import{createApp}from'/@modules/vue'原生ESM下的HMR在Vite中，HMR是在原生ESM上执行的。在编辑文件时，Vite只需要精确地使被编辑的模块与其最近的HMR边界（大多数时候只是模块本身）之间的链失效，使得HMR更新始终快速，无论应用程序的大小。改写导入模块时记录模块引用关系。import.meta.hot标识修改模块的HMR边界。当一个模块发生变化时，它的介绍者被追溯，寻找HMR边界。HMRBoundary重新请求修改的模块并更新它们。如果引用链回溯到末尾，比如Vue应用中引入了index.js，main.js发生了变化。该应用程序仍然会完全重新加载。
