webpack：
1.生态比vite完善
2.基于nodejs（同步）
3.第一次冷启动较慢（打包所有相关模块后再启动服务器）
4.热刷新效率低（编辑单个文件会重新构建整个包且动态模块热重载（HMR）效率随着项目规模变大而下降）
vite：
1.生态还不够成熟
2.基于ES Module
3.项目中有些模块引用不是使用ES写法，可能是CommonJS、AMD等，vite会进行预构建，将其转换为ESM模块
4.将许多内部模块的ESM依赖转换为单个模块，以提高后续页面加载性能
5.对于JSX、TS等需要编译的文件，vite使用esbuild进行编译
6.启动速度快，不同于webpack打包编译所有模块后再启动服务器，vite是按需动态编译的方式，浏览器请求某模块再实时编译该模块并返回给浏览器（esbuild编译也够快），项目越复杂模块越多，vite优势更明显
tips：
esbuild：使用go编写并编译成机器码（速度快），大量使用并行算法，esbuild所有内容都是从零编写，避免了不必要的数据转换，更有效利用内存
webpack会先打包，然后启动开发服务器，请求服务器时直接给予打包结果。而vite是直接启动开发服务器，请求哪个模块再对该模块进行实时编译。由于现代浏览器本身就支持ES Module，会自动向依赖的Module发出请求。vite充分利用这一点，将开发环境下的模块文件，就作为浏览器要执行的文件，而不是像webpack那样进行打包合并。由于vite在启动的时候不需要打包，也就意味着不需要分析模块的依赖、不需要编译，因此启动速度非常快。当浏览器请求某个模块时，再根据需要对模块内容进行编译。这种按需动态编译的方式，极大的缩减了编译时间，项目越复杂、模块越多，vite的优势越明显。在HMR方面，当改动了一个模块后，仅需让浏览器重新请求该模块即可，不像webpack那样需要把该模块的相关依赖模块全部编译一次，效率更高。当需要打包到生产环境时，vite使用传统的rollup进行打包，因此，vite的主要优势在开发阶段。另外，由于vite利用的是ES Module，因此在代码中不可以使用CommonJS
webpack-dev-server的热更新是与本地服务器建立[socket]链接，注册hash和ok两个事件，发生文件修改时给客户端推送hash事件，客户端根据hash事件中返回的参数来拉去更新后的文件，HotModuleReplacementPlugin会在文件修改后，生成两个文件给客户端，热更新上反应的就是部分代码变更，整个模块的代码都需要重写编译然后再推送更新
