vite和esbuild/roolup的优缺点

esbuild

优点

1. 基于go语言，go是纯机器码
2. 不使用 AST，优化了构建流程
3. 多线程并行

缺点

1. esbuild 没有提供 AST 的操作能力。所以一些通过 AST 处理代码的 babel-plugin 没有很好的方法过渡到 esbuild 中（比如babel-plugin-import）。如果你的项目使用了 babel-plugin-import, 或者一些自定义的 babel-plugin 。在目前来看是没有很好的迁移方案的。
2. 不支持将es6转换为es5(这里不用babel是因为babel会将代码转换为cjs语法,而esbuild是基于es6语法)

roolup

优点

1. 打包结果依然完全可读

缺点

1. 模块最终都会被打包到一个函数中，无法实现HMR
2. 加载非ESM的第三方模块比较复杂

Vite

优点

1. 开发环境编译快：
   开发环境冷启动无需打包，只是使用esbuild对依赖进行预构建，将CommonJS和UMD发布的依赖转换为浏览器支持的ESM
2. 无需分析模块之间的依赖，无需在启动开发服务器前进行编译
3. 在一开始将应用中的模块区分为 依赖 和 源码 两类，源码模块协商缓存，依赖模块强缓存（依赖大多为开源的不会变动的node_modules模块，请求路径满足 /^/@modules// 格式就会被认为是依赖）
4. Vite 热更新更快：利用了ESM和浏览器缓存技术，构建后的依赖请求（http头的max-age=31536000,immutable）进行强缓存，以提高页面性能。
   更新速度与项目复杂度无关。

缺点

1. 生产环境和开发环境不一致
   由于 Vite 还是使用的 es module 模块不能直接使用生产环境（兼容性问题，如果你的项目不需要兼容 IE11 等低版本的浏览器，自然是可以使用的）,生产环境使用 rollup 打包可能会造成开发环境与生产环境的不一致。很多 第三方 sdk 没有产出 ESM格式的的代码，这个需要自己去做一些兼容。目前支持 CommonJS（CJS）代码快速转化为 ESM，但是对于一些格式不规范的代码，可能还是需要单独处理。

vite在esbuild和roolup之间如何选择

对比在开发环境Vite使用esbuild来构建依赖，生产环境Vite则使用了更加成熟的Rollup来完成整个打包过程。下面是官方原话：
尽管原生 ESM 现在得到了广泛支持，但由于嵌套导入会导致额外的网络往返，在生产环境中发布未打包的 ESM 仍然效率低下（即使使用 HTTP/2）。为了在生产环境中获得最佳的加载性能，最好还是将代码进行 tree-shaking、懒加载和 chunk 分割（以获得更好的缓存）。虽然 esbuild 快得惊人，并且已经是一个在构建库方面比较出色的工具，但一些针对构建应用的重要功能仍然还在持续开发中 —— 特别是代码分割和 CSS 处理方面。就目前来说，Rollup 在应用打包方面更加成熟和灵活。尽管如此，当未来这些功能稳定后，我们也不排除使用 esbuild 作为生产构建器的可能。

vite为什么要使用插件容器去模拟rollup行为

由于生产环境的打包，使用的是 Rollup，Vite 需要保证，同一套 Vite 配置文件和源码，在开发环境和生产环境下的表现是一致的。想要达到这个效果，只能是 Vite 在开发环境模拟 Rollup 的行为 ，在生产环境打包时，将这部分替换成 Rollup 打包。

vite中moduleGraph的作用

1. 复用模块解析结果
2. 在热刷新中判断哪些模块需要更新

vite中依赖预构建的作用

1. CommonJS 和 UMD 兼容性
   开发阶段中，Vite 的开发服务器将所有代码视为原生 ES 模块。因此，Vite 必须先将作为 CommonJS 或 UMD 发布的依赖项转换为 ESM。当转换 CommonJS 依赖时，Vite 会执行智能导入分析，这样即使导出是动态分配的（如 React），按名导入也会符合预期效果。
2. 性能
   Vite 将有许多内部模块的 ESM 依赖关系转换为单个模块，以提高后续页面加载性能。一些包将它们的 ES 模块构建作为许多单独的文件相互导入。例如，lodash-es 有超过 600 个内置模块！当我们执行 import { debounce } from ‘lodash-es’ 时，浏览器同时发出 600 多个 HTTP 请求！尽管服务器在处理这些请求时没有问题，但大量的请求会在浏览器端造成网络拥塞，导致页面的加载速度相当慢。通过预构建 lodash-es 成为一个模块，我们就只需要一个 HTTP 请求了！