ESBuild在Vite中发挥了什么作用？
ESBuild有多种作用：
- 作为打包器
- 作为代码转译(Transfomer)的工具，比如将jsx文件转译成js
- 作为代码压缩混淆的工具
依赖预构建------ ESBuild 作为打包工具
ESBuild是由Go开发的，通过并行等技术，任务执行效率非常之高
由Vite构建的项目中，在开发环境中Vite采用no-bundle的方式对源代码进行（不）打包，利用现代浏览器原生支持ESM的特性，实现开发服务器的快速启动。相对于 Webpack 一次性将所有代码进行打包后再启动开发服务器的方式快了100倍不止。
但Vite是完全不打包吗？显然不是的。在Vite的开发服务器里，项目中每一个import导入都是一个http请求，源代码中的import倒还不算多，但第三方依赖中的模块导入就非常之多了，甚至二次依赖都是非常普遍的。这就会导致出现请求瀑布，严重影响页面的首屏性能------打开页面动辄要发起上千个http请求，这对浏览器的压力是巨大的，要知道浏览器对同一个域名下最多只能维护 6 个 TCP连接。
Vite的方案是仅对第三方包进行打包，也就是所谓的预构建(Pre-Build) ，在预构建之前，ESBuild还会将那些仅支持 CommonJS 的第三方依赖转换为 ESM 模块格式，但是不用担心效率问题，ESBuild的执行效率非常之高。
ESBuild作为Bundle 工具速度这么快，但也存在一些缺点：
- 无法进行语法降级和polyfill
- 无法操作打包后的产物。比如rollup就有
renderChunk钩子来灵活操作打包后的chunk文件 - 不支持 Code Splitting拆包策略，而webpack和rollup都能够自定义拆包策略
正是以上局限性的限制，导致即便ESBuild性能如此优秀，但Vite在生产环境仍然采用的是功能更加成熟的rollup进行代码打包。
总的来说，ESbuild作为打包器的作用就是对第三方包进行ESM格式转换，并进行预构建。当然，预构建也是可以通过配置进行手动控制的，比如通过include配置对动态导入的模块和虚拟模块进行提前预构建
单文件编译------ 作为 TS 和 JSX 的转译工具
过去 transform 的任务通常由 Babel 或 TSC 完成，但其效率远远比不上 ESBuild，为了提升转译效率，Vite采用ESBuild 进行代码转译，比如对 TS 或 JSX 代码转译。我们以一个巨大的，50 多 MB 的纯代码文件为例，来对比 Esbuild 、 Babel 、 TSC 包括 SWC 的编译性能 ：
可以看到性能提升是非常之大了，但是ESBuild也有其缺点 ：不能进行类型检查，它仅仅能抹去TS中的类型标注。因此，在生产环境下，我们执行build命令时，会先执行tsc做类型检查再打包代码。
代码压缩------作为构建产物的压缩混淆工具
在Vite架构图的生产环境部分可以看到，Vite采用了ESBuild进行代码压缩。既然用rollup来构建的，拿为什么不用rollup的terser 插件呢？
原因是ESBuild是在是太快了，而 terser 的速度太慢了，原因是：
- ESbuild内部共用同一个 AST，因此代码压缩时省去了许多重复的解析工作，比如将代码转换为 AST 的时间。而rollup各个插件中比如babel和terser之间就无法公用同一个AST
- terser是JS所实现的，而JS作为解释性+JIT（即时编译）语言，对于代码压缩任务来说，其执行效率肯定是比不上golong这种编译型语言的，毕竟人家是提前就编译好二进制机器码的。
总结
总的来说，Vite为了将效率提升到极致，可以说是把ESBuild的各项能力（Transfomer，Bundle，Minify）长处发挥的淋漓尽致。