介绍
vite插件和rollup的不同
# 问题
vite开发阶段首屏一直是比较糟糕的，vite3做了一些优化，比如二次依赖预购建延迟之类的，但本质没有解决，因为这个首屏问题是相当特殊的，前端常规上说的首屏问题，大多源于文件过大传输过久，或者执行js时间太长，而vite开发阶段的首屏问题，是一个服务端的问题，是源于vite-devserver的性能局限，本质相当于用单进程nodejs服务器（即devserver)去做高并发(bundless的项目请求文件会非常多,和webpack那种只有四类chunk的不同），而且每个并发还有cpu型操作(即插件中的transform),想要做优化比较难，具体方法我之前在那个预加载中写过，大体就是把压力从首屏转成懒加载，再通过prefetch优化懒加载。
优化到这个样子就是极限了，主要关注的是，不要去做一些破坏性的操作，比如ast操作，这会导致vite省下来的性能统统还回去。之前看别人讲座说了一基于vite的组件库大方案，里面提到了基于ts的注释去生成操作控件，具体原理没有讲，但我隐隐约约感觉不太对劲，解析注释大概率用ast（用正则这会各种奇葩问题的，tsdoc明确说了）,如果用过dts，就是打包vue组件产生types，会明显感觉慢特别多，（无论用什么工具，babel还是tsc）
顺带一提，esbuild很快，但这个快只能用于打包，它不会做任何类型检查，和babel一样，目前能做类型检查的，只有tsc（别想着用esbuild偷懒）
# 尝试解决
这里其实有一个可以取巧的点，因为这个大量请求文件，不会持续很久，也就是devserver在开发的大部分时间里，都是闲置的，也即是，可以拖到闲置的时候，再去做一些奢侈的操作（个人建议直接开个新进程or线程就完事了），操作的结果怎么回到浏览器呢？主要是轮询和推送，轮询自然就是前端过一会儿请求一次，而推送的话，直接利用热更新现成的websocket就行了，
这对应nodejs的pull与epoll 前提是，开发环境