vite学习

vite是什么，有什么特点

vite是新一代的前端构建工具，
核心原理：
Vite其核心原理是利用浏览器现在已经支持ES6的import，碰见import就会发送一个HTTP请求去加载文件
Vite整个过程中没有对文件进行打包编译，做到了真正的按需加载，所以其运行速度比原始的webpack开发编译速度快出许多
特点：
快速的冷启动：基于Esbuild的依赖进行预编译优化 （Esbuild 打包速度太快了，比类似的工具快10~100倍 ）
增加缓存策略：源码模块使用协商缓存，依赖模块使用强缓；因此一旦被缓存它们将不需要再次请求。
HMR（热更新）：当修改代码时，HMR 能够在不刷新页面的情况下，把页面中发生变化的模块，替换成新的模块，同时不影响其他模块的正常运作
基于 Rollup 打包：生产环境下由于esbuild对css和代码分割并使用Rollup进行打包；
高效的热更新：基于ESM实现，同时利用HTTP头来加速整个页面的重新加载，

vite原理

是一种现代化的前端开发工具，其工作原理主要分为以下几个步骤：
基于ESM构建：Vite作为一款基于ESM的前端构建工具，通过ES模块提供的动态导入功能来实现快速的开发和构建。
零配置开发：Vite允许开发者在不需要任何配置的情况下启动一个服务器进行开发，通过对文件的即时编译和缓存，来提高开发效率。
基于浏览器原生的ESM加载：Vite将所有文件视为ES模块，并且在开发时会直接从源代码加载模块，而不是打包后的文件，从而可以避免打包的过程带来的性能损失。
按需编译和缓存：Vite会按需编译和缓存依赖项，只有当需要更新时才会进行重新编译，缓存让开发者可以忽略无关的代码变化。
插件化架构：Vite的插件化架构可以方便地扩展其功能，例如使用插件来处理CSS、处理图片、压缩源代码等等。
通过以上几个步骤，Vite实现了快速、高效的前端开发和构建。

vite和webpack的区别

区别如下：
（1）构建原理： Webpack 是一个静态模块打包器，通过对项目中的 JavaScript、CSS、图片等文件进行分析，生成对应的静态资源，并且可以通过一些插件和加载器来实现各种功能；Vite 则是一种基于浏览器原生 ES 模块解析的构建工具。
（2）打包速度： Webpack 的打包速度相对较慢，Vite 的打包速度非常快。
（3）配置难度： Webpack 的配置比较复杂，因为它需要通过各种插件和加载器来实现各种功能；Vite 的配置相对简单，它可以根据不同的开发场景自动配置相应的环境变量和配置选项。
（4）插件和加载器： Webpack 有大量的插件和加载器可以使用，可以实现各种复杂的构建场景，例如代码分割、按需加载、CSS 预处理器等；Vite 的插件和加载器相对较少
（5）Vite是按需加载，webpack是全部加载： 在HMR（热更新）方面，当改动了一个模块后，vite仅需让浏览器重新请求该模块即可，不像webpack那样需要把该模块的相关依赖模块全部编译一次，效率更高。
（6）webpack是先打包再启动开发服务器，vite是直接启动开发服务器，然后按需编译依赖文件 由于vite在启动的时候不需要打包，也就意味着不需要分析模块的依赖、不需要编译，因此启动速度非常快。当浏览器请求某个模块时，再根据需要对模块内容进行编译，这种按需动态编译的方式，极大的缩减了编译时间。

vite有什么优缺点？

优点：比webpack快，webpack会先打包，然后启动开发服务器，请求服务器时直接给予打包结果。vite是直接启动开发服务器，请求哪个模块再对该模块进行实时编译。vite在启动的时候不需要打包，意味着不需要分析模块的依赖、不需要编译，因此启动速度非常快。当浏览器请求某个模块时，再根据需要对模块内容进行编译。这种按需动态编译的方式，极大的缩减了编译时间，项目越复杂、模块越多，vite的优势越明显。在HMR方面，当改动了一个模块后，仅需让浏览器重新请求该模块即可，不像webpack那样需要把该模块的相关依赖模块全部编译一次，效率更高。
缺点：当需要打包到生产环境时，vite使用传统的rollup进行打包，因此，vite的主要优势在开发阶段。另外，由于vite利用的是ES Module，因此在代码中不可以使用CommonJS

怎么在vite中引入图片资源？

vite 是如何处理vue单文件组件的？

怎么在vite中使用css预处理器

vite支持哪些类型的模块加载器

如何在生产环境中使用vite

在使用vite时遇到的最大挑战是什么？你是怎么解决的？

使用过哪些vite的插件

构建分析：rollup-plugin-visualizer
gzip压缩：vite-plugin-compression
cdn加速：vite-plugin-cdn-import

vite是如何处理es模块的循环引用问题？

基于ESM的Dev server

在Vite出来之前，传统的打包工具如Webpack是先解析依赖、打包构建再启动开发服务器，Dev Server 必须等待所有模块构建完成后才能启动，当我们修改了 bundle模块中的一个子模块， 整个 bundle 文件都会重新打包然后输出。项目应用越大，启动时间越长。
而Vite利用浏览器对ESM的支持，当 import 模块时，浏览器就会下载被导入的模块。先启动开发服务器，当代码执行到模块加载时再请求对应模块的文件，本质上实现了动态加载。

基于ESM的HRM热更新

所有的 HMR 原理：

目前所有的打包工具实现热更新的思路都大同小异：主要是通过WebSocket创建浏览器和服务器的通信监听文件的改变，当文件被修改时，服务端发送消息通知客户端修改相应的代码，客户端对应不同的文件进行不同的操作的更新。
Vite 的表现：
Vite 监听文件系统的变更，只用对发生变更的模块重新加载，这样HMR 更新速度就不会因为应用体积的增加而变慢
而 Webpack 还要经历一次打包构建。
所以 HMR 场景下，Vite 表现也要好于 Webpack。

基于Esbuild的依赖预编译优化

Vite预编译之后，将文件缓存在node_modules/.vite/文件夹下

为什么需要预编译&预构建

支持 非ESM 格式的依赖包：Vite是基于浏览器原生支持ESM的能力实现的，因此必须将commonJs的文件提前处理，转化成 ESM 模块并缓存入 node_modules/.vite
减少模块和请求数量：Vite 将有许多内部模块的 ESM 依赖关系转换为单个模块，以提高后续页面加载性能。
如果不使用esbuild进行预构建，浏览器每检测到一个import语句就会向服务器发送一个请求，如果一个三方包被分割成很多的文件，这样就会发送很多请求，会触发浏览器并发请求限制；

Esbuild为什么为么快

Esbuild 使用 Go 语言编写，可以直接被转化为机器语言，在启动时直接执行；
而其余大多数的打包工具基于 JS 实现，是解释型语言，需要边运行边解释；
JS 本质上是单线程语言，GO语言天生具有多线程的优势，充分利用 CPU 资源；

关于首屏加载慢的原因和处理

处理：使用预渲染方案。预渲染是指在用户访问页面之前，提前生成并缓存页面的静态HTML内容。这样当用户首次访问页面时，不需要进行实时的服务器渲染或客户端渲染，而是直接返回预渲染的静态HTML，从而提供更快的加载速度和更好的用户体验
原理：预渲染基本上是启动无头浏览器，加载应用程序的路由，并将结果保存到静态 HTML文件中。然后，您可以使用之前使用的任何静态文件服务解决方案来服务它。它只适用于 HTML5 导航等。无需更改代码或添加服务器端呈现解决方法。
预渲染优点：
性能改善：预渲染可以显著改善初始加载时间。在传统的单页面应用（SPA）中，页面初始化需要下载和执行 JavaScript 代码，然后再进行渲染。而预渲染会生成静态 HTML 文件，使得初始加载变得更快，用户可以更快地看到内容，也就利于改善用户体验。
SEO 改进：由于搜索引擎爬虫通常不会执行 JavaScript，传统的 SPA 对于搜索引擎的可索引性存在挑战。预渲染可以生成包含实际内容的静态 HTML 页面，使搜索引擎能够更好地理解和索引你的应用。这有助于提高应用在搜索引擎结果页面（SERP）中的排名。
缓存效果：预渲染生成的静态 HTML 页面可以在服务器或 CDN 上进行缓存，从而进一步提高页面加载速度和用户体验。用户访问其他页面时，预渲染页面的缓存效果可以减少服务器的负载并提供更快的响应时间。
缺点：
构建时间增加：预渲染需要在构建过程中生成静态 HTML 页面，这可能会增加构建时间。特别是在大型应用或包含许多页面的应用中，构建时间可能会显著增加。
可缓存性限制：某些页面或内容可能是动态的，无法进行预渲染。例如，包含用户特定信息的页面或需要实时数据更新的页面，在这些情况下，预渲染的优势将减弱，可能需要其他解决方案。也就是说如果页面依赖接口请求的数据，那么页面就算使用预渲染，加载了html文件也仅仅只会有背景框架而已，类似于骨架屏的效果，还是得等待接口返回浏览器才能进行渲染页面，此时不建议使用预渲染，可能需要考虑SSR（服务端渲染）等其他方案。
使用 vite-plugin-prerender 插件

npm i vite-plugin-prerender -D

在vite.config 文件中配置 plugins 项

import vitePrerender from 'vite-plugin-prerender';
const Renderer = vitePrerender.PuppeteerRenderer;
import path from 'path'

export default () => {
  return {
    plugins: [
      ... vitePrerender({
      // 要渲染的路由
      routes: ['/'],
      // 静态文件目录
      staticDir: path.join(__dirname, 'dist'),
      // 是否压缩 HTML 文件
      minify: true,
      // 网络请求失败、404 错误等情况下应该返回的 HTML 文件
      fallback: 'index.html',
      // 渲染时是否显示浏览器窗口，值写false可用于调试
      renderer: new Renderer({
        headless: true
      })
    ],
  }
}

注意事项：
css.extract
如果您依赖内联 CSS，即您没有从包中提取 CSS，因此会遇到重复的 CSS 样式标签，需要将 CSS 提取到一个单独的文件中。可以配置css.extract为true，或者使用生产模式进行打包。

createWebHistory
插件仅适用于使用 HTML5 历史记录 API 进行路由的 SPA，所以需要使用history路由模式。尝试过如果使用hash模式的话，插件配置路由 ‘/’ ，也是可以渲染出首页的html的，hash路由模式在其他页面做预渲染无效果，原因如下：
在哈希路由中，当 URL 中的哈希发生变化时，页面不会重新加载，而是通过 JavaScript 来动态更新页面内容，以实现单页应用（Single-Page Application，SPA）的效果。哈希路由在 URL 中使用的是哈希部分，而哈希部分在传统的服务器请求中是不会发送给服务器的，因此服务器无法感知到哈希的变化。这就导致了预渲染与哈希路由的冲突。
可以通过使用其他技术手段，例如，可以使用服务端渲染（Server-Side Rendering，SSR）或静态网页生成器（Static Site Generator）来生成包含哈希路由的静态HTML页面。这样就可以在服务器端进行预渲染，并将预渲染的静态页面与前端应用配合使用，以提供更好的性能和用户体验。

查看打包生成的html，删除不必要的元素
有些内容是js控制生成在body中的，预渲染过程中将其加入进html中了，这会导致访问页面时会出现重复的内容，所以对于预渲染后的html需要仔细查看，删除页面内不必要的元素。