1、esbuild 是使用go语言编写的一个前端构建工具
相对于nodeJs的构建工具如webpack。go语言是纯机器码，没有js的解释过程；go新开了一个进程多线程并行，而js是单线程串行化的，所以从开发语言层面来说就更快。当nodejs还在解析打包程序的js的时候，go已经在解析要构建的js了。
2、esbuild内置了部分的loader直接使用go语言编写，可以直接使用
相对于nodeJs的构建工具中相同功能的loader相比也更快。不同于webpack中loader都要配置添加。比如内置了对.js、.jsx、.ts、.tsx 、.css、.module.css 等的支持，其他文件类型则需要添加社区的loader或者手写插件进行处理，比如：less、sass、img、字体图标库等。
esbuild的生态还不完善，很多插件其实只是包装了开源的loader框架，本质上还是用的js实现的，而且很多社区提供的插件都存在各种问题，需要自己实现插件，比如对css进行浏览器兼容添加浏览器前缀等问题
3、esbuild的代码分割很鸡肋
代码分割可以减小了初始加载时的文件体积，加速页面加载时间；也能提高缓存利用率，节省带宽成本；多个小块的代码可以并行下载，提高整体加载效率。而esbuild的代码分割，只支持esm 格式，对浏览器版本有限制；能对动态 import 的内容或多入口同时用到的代码进行分割。无法做到像webpack一样将使用到的某个库单独打包出去。
4、esbuild不支持HMR，需要借助插件实现。
5、esbuild目前的应用
主要因为esbuild在代码分割、css处理、不支持HMR、没有提供AST能力（不能转换成兼容低版本浏览器代码）等问题，虽然它很快，但它不适合直接用于生产环境，而更适合作为一种偏底层的模块打包工具，需要在它的基础上二次封装。在其他的构建工具中，只是将esbuild应用于开发环境，从而有更快的开发体验，比如在vite中 ，开发环境下使用esbuild快速构建，而构建部署版本时则使用的是rollup；在umi/mfsu中，开发环境下使用esbuild-loader替代label，而构建部署版本时则还是使用的babel。
总的来说，esbuild具有极快的构建速度、可扩展性、支持多种格式、不需要设置各种 loader，配置简单等。但还有很多不足：
- 社区生态很弱，跟 Webpack 和 Vite 完全不在一个量级
- 插件之间兼容性问题很严重
- 代码分割能力太弱，只能基于入口进行分割
- 对目标浏览器版本有一定要求
- 不支持 HMR
- 为了保持结构的一致性，没有提供转化的 AST 的 API
- 由于工具和插件还是采用 JavaScript 编写，存在解析速度相对较慢的可能性
- 对于复杂场景，配置还是像 Webpack 一样复杂
- 可以在简单项目或类库开发中使用
总之，esbuild 不是像 Webpack 是一个大一统项目，提供完善的插件机制，而是在极度精简之后的打包工具，快才是它的追求目标。
文章内容只做学习记录，内容转自别的大佬博客，主要参考：
Esbuild深度调研：吹了三年，能上生产了吗？