9 篇博文 含有标签「知识点」

大文件历史删除​

如果你的 Git 提交历史中有大的包（例如大文件）需要删除，比如说你的包中有一个大视频之前被上传过，你可以使用以下方法：

git filter-repo​

使用 git filter-repo（推荐）： git filter-repo 是一个更现代的工具，可以有效地清理历史。首先，确保安装了这个工具：pip install git-filter-repo

然后，运行以下命令来删除历史中的大文件：git filter-repo --strip-blobs-bigger-than 10M

这个命令会删除历史中大于 10MB 的文件。你可以根据需要调整大小限制。

注意：git filter-repo 是用 Python 编写的工具，因此需要安装 Python

git filter-branch​

使用 git filter-branch（较旧的方法）： 如果你无法使用 git filter-repo，可以使用 git filter-branch

git filter-branch --index-filter 'git rm --cached --ignore-unmatch path/to/large-file' --prune-empty --tag-name-filter cat -- --all

替换 path/to/large-file 为你想删除的文件路径。

• git filter-branch：用于重写 Git 历史的命令。
• --index-filter 'git rm --cached --ignore-unmatch path/to/large-file'：这是一个索引过滤器，用于在每个提交中从索引中删除指定的文件（在这里是 path/to/large-file）。--cached 表示仅从索引中删除，而不从工作区删除；--ignore-unmatch 表示如果文件在某些提交中不存在，也不会导致错误。
• --prune-empty：在删除文件后，如果某个提交没有其他内容（变成空提交），则将其删除。
• --tag-name-filter cat：在重写历史时，保留标签的名称。
• -- --all：表示对所有分支和标签进行操作。

当你的文件内容过于复杂，（笔者的情况就是，我的个人博客有很多的图片，但是之前上传图片没有压缩，所以导致.git 文件很大，我选择直接重置.git 提交历史）

当然你得确定你以后不需要回溯历史信息

直接删除 Git 历史​

假设当前的分支为main

1. 备份当前分支（可选）： 如果你想保留当前状态，可以创建一个新的分支：git checkout -b dev

2. 重置当前分支： 使用 --orphan 创建一个新的分支，该分支没有任何历史：git checkout --orphan develop

3. 添加文件并提交： 将当前工作区的文件添加到新的分支并提交：git add . git commit -m "Initial commit without history"

4. 删除旧分支：git branch -D main

5. 将新的分支重命名为旧分支的名称：git branch -m main

6. 强制推送到远程：git push origin main --force

7. 未清理未引用的对象：在删除历史后，Git 可能仍然保留了一些未引用的对象。你可以通过以下命令来清理它们：

   1. git reflog expire --expire=now --all：

      • git reflog：用于查看和管理 Git 的引用日志（reflog），记录了所有的引用变更（例如，分支的移动）。
      • expire：这个子命令用于过期处理，将不再使用的引用标记为过期。
      • --expire=now：指定所有引用立即过期，意味着将所有未引用的对象标记为可以删除。
      • --all：作用于所有的引用，包括所有分支和标签。

   2. git gc --prune=now --aggressive：

      • git gc：执行垃圾回收，清理未引用的对象，并优化 Git 存储
      • --prune=now：指示 Git 删除所有未引用的对象，而不保留任何过期对象。now 的意思是立即删除
      • --aggressive：执行更深入的优化，可能会耗费更多时间，但能更有效地减少 .git 文件夹的大小。

8. 最后强制推到远程即可：git push origin main --force

这样你的git提交纪录就变成首次了，.git也被清除缩小了

前言​

在前端项目工程日益复杂的今天，一套完善的开发环境配置可以极大的提升开发效率，提高代码质量，方便多人合作，以及后期的项目迭代和维护，项目规范分项目目录结构规范，代码格式规范和git提交规范，本文主要讲后两种。

代码规范技术栈​

代码格式规范和语法检测​

1. vscode：统一前端编辑器。
2. editorconfig: 统一团队vscode编辑器默认配置。
3. prettier: 保存文件自动格式化代码。
4. eslint: 检测代码语法规范和错误。
5. lint-staged: 只检测暂存区文件代码，优化eslint检测速度。

代码git提交规范​

1. husky:可以监听git执行，在对应hook执行阶段做一些处理的操作。
2. pre-commit：githooks之一， 在commit提交前使用tsc和eslint对语法进行检测。
3. commit-msg：githooks之一，在commit提交前对commit备注信息进行检测。
4. commitlint：在githooks的pre-commit阶段对commit备注信息进行检测。
5. commitizen：git的规范化提交工具，辅助填写commit信息。

editorconfig统一编辑器配置​

由于每个人的vsocde编辑器默认配置可能不一样，比如有的默认缩进是4个空格，有的是2个空格，如果自己编辑器和项目代码缩进不一样，会给开发和项目代码规范带来一定影响，所以需要在项目中为编辑器配置下格式。

安装vscode插件EditorConfig​

打开vsocde插件商店，搜索EditorConfig for VS Code，然后进行安装

添加.editorconfig配置文件​

安装插件后，在根目录新增 .editorconfig配置文件:

# https://editorconfig.org
root = true # 控制配置文件 .editorconfig 是否生效的字段

[**] # 匹配全部文件
indent_style = space # 缩进风格，可选space｜tab
indent_size = 2 # 缩进的空格数
charset = utf-8 # 设置字符集
trim_trailing_whitespace = true # 删除一行中的前后空格
insert_final_newline = true # 设为true表示使文件以一个空白行结尾
end_of_line = lf

[**.md] # 匹配md文件
trim_trailing_whitespace = false

上面的配置可以规范本项目中文件的缩进风格，和缩进空格数等，会覆盖vscode的配置，来达到不同编辑器中代码默认行为一致的作用。

prettier自动格式化代码​

每个人写代码的风格习惯不一样，比如代码换行，结尾是否带分号，单双引号，缩进等，而且不能只靠口头规范来约束，项目紧急的时候可能会不太注意代码格式，这时候需要有工具来帮我们自动格式化代码，而prettier就是帮我们做这件事的。

安装vscode插件Prettier​

打开vsocde插件商店，搜索Prettier - Code formatter，然后进行安装。

添加.prettierrc.js配置文件​

安装插件后，在根目录新增 .prettierrc.js配置文件，配置内容如下：

module.exports = {
  printWidth: 80, // 一行的字符数，如果超过会进行换行
  tabWidth: 2, // 一个tab代表几个空格数，默认就是2
  singleQuote: true, // 字符串是否使用单引号
  trailingComma: 'all', // 对象或数组末尾是否添加逗号 none| es5| all
  bracketSpacing: true, // 对象大括号直接是否有空格，默认为true，效果：{ foo: bar }
  arrowParens: 'avoid', // 箭头函数如果只有一个参数则省略括号
  semi: false, // 行尾是否使用分号，默认为true
};

各个字段配置就是后面注释中的说明

添加.vscode/settings.json​

配置前两步后，虽然已经配置prettier格式化规则，但还需要让vscode来支持保存后触发格式化

在项目根目录新建 .vscode文件夹，内部新建settings.json文件配置文件，内容如下：

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true
}

这一步配置完成后，修改项目代码，把格式打乱，点击保存时就会看到编辑器自动把代码格式规范化了。

eslint+lint-staged检测代码​

安装vscode插件ESLint​

打开vsocde插件商店，搜索ESLint，然后进行安装。

安装eslint依赖​

npm i eslint -D

配置.eslintrc.js文件​

安装eslint后，执行npm init @eslint/config，选择自己需要的配置

选择完成后会在根目录下生成 .eslint.js文件

添加eslint语法检测脚本​

有些eslint报错和警告都是我们用眼睛看到的，有时候需要通过脚本执行能检测出来，在package.json的scripts中新增

"eslint": "eslint src/**/*.{ts,tsx}"

代表检测src目录下以.ts,.tsx为后缀的文件

使用lint-staged优化eslint检测速度​

上面配置的eslint会检测src文件下所有的 .ts, .tsx文件，虽然功能可以实现，但是当项目文件多的时候，检测的文件会很多，需要的时间也会越来越长，但其实只需要检测提交到暂存区，就是git add添加的文件，不在暂存区的文件不用再次检测，而lint-staged就是来帮我们做这件事情的。

安装依赖：npm i lint-staged@12.5.0 -D

在package.json添加lint-staged配置

"lint-staged": {
  "src/**/*.{ts,tsx}": [
    "npm run eslint"
  ]
},
"eslint": "eslint"

因为要检测git暂存区代码，所以需要执行git init初始化一下git，初始化完成后就可以进行测试了，先提交一下文件，执行npx lint-staged

使用tsc检测类型和报错​

在项目中使用了ts,但一些类型问题，现在配置的eslint是检测不出来的，需要使用ts提供的tsc工具进行检测,如：

在main.tsx定义了函数say,参数name是string类型，当调用传number类型参数时，页面有了明显的ts报错，但此时提交main.tsx文件到暂存区后执行npx lint-staged

发现没有检测到报错，所以需要配置下tsc来检测类型，在package.json添加脚本命令

"pre-check": "tsc && npx lint-staged"

git提交时检测语法规范​

为了避免把不规范的代码提交到远程仓库，一般会在git提交代码时对代码语法进行检测，只有检测通过时才能被提交，git提供了一系列的githooks ，而我们需要其中的pre-commit钩子，它会在git commit把代码提交到本地仓库之前执行，可以在这个阶段检测代码，如果检测不通过就退出命令行进程停止commit。

代码提交前husky检测语法​

而husky就是可以监听githooks的工具，可以借助它来完成这件事情。

安装husky：npm i husky -D

配置husky的pre-commit钩子​

生成 .husky配置文件夹（如果项目中没有初始化git,需要先执行git init）

npx husky init

会在项目根目录生成 .husky文件夹，生成文件成功后，需要让husky支持监听pre-commit钩子，监听到后执行上面定义的npm run pre-check语法检测。

在.husky下创建pre-commit，添加

#!/usr/bin/env sh
. "$(dirname "$0")/_/husky.sh"

npm run pre-check

代码提交时检测commit备注规范​

在提交代码时，良好的提交备注会方便多人开发时其他人理解本次提交修改的大致内容，也方便后面维护迭代，但每个人习惯都不一样，需要用工具来做下限制，在git提供的一系列的githooks中，commit-msg会在git commit之前执行，并获取到git commit的备注，可以通过这个钩子来验证备注是否合理，而验证是否合理肯定需要先定义一套规范，而commitlint就是用来做这件事情的，它会预先定义一套规范，然后验证git commit的备注是否符合定义的规范。

安装和配置commitlint​

安装commitlint：npm i @commitlint/config-conventional @commitlint/cli -D

在根目录创建commitlint.config.js文件,添加配置如下

module.exports = {
  // 继承的规则
  extends: ['@commitlint/config-conventional'],
  // 定义规则类型
  rules: {
    // type 类型定义，表示 git 提交的 type 必须在以下类型范围内
    'type-enum': [
      2,
      'always',
      [
        'feat', // 新功能 feature
        'fix', // 修复 bug
        'docs', // 文档注释
        'style', // 代码格式(不影响代码运行的变动)
        'refactor', // 重构(既不增加新功能，也不是修复bug)
        'perf', // 性能优化
        'test', // 增加测试
        'chore', // 构建过程或辅助工具的变动
        'revert', // 回退
        'ci', //持续集成变更
        'build', // 打包
      ],
    ],
    // subject 大小写不做校验
    'subject-case': [0],
  },
}

配置husky监听commit-msg​

上面已经安装了husky,现在需要再配置下husky，让husky支持监听commit-msg钩子，在钩子函数中使用commitlint来验证

在.husky下创建commit-msg，添加

#!/usr/bin/env sh
. "$(dirname "$0")/_/husky.sh"

npx --no-install commitlint --edit "$1"

参考链接​

【前端工程化】配置React+ts企业级代码规范及样式格式和git提交规范

commit message = subject + ：+ 空格 + message 主体

例如： git commit -m "feat：增加用户注册功能"

常见的 subject 种类以及含义如下：

1. feat: 新功能（feature）
   • 用于提交新功能
   • 例如：feat: 增加用户注册功能
2. fix: 修复 bug
   • 用于提交 bug 修复
   • 例如：fix: 修复登录页面崩溃的问题
3. docs: 文档变更
   • 用于提交仅文档相关的修改
   • 例如：docs: 更新README文件
4. style: 代码风格变动（不影响代码逻辑）
   • 用于提交仅格式化、标点符号、空白等不影响代码运行的变更
   • 例如：style: 删除多余的空行
5. refactor: 代码重构（既不是新增功能也不是修复bug的代码更改）
   • 用于提交代码重构
   • 例如：refactor: 重构用户验证逻辑
6. perf: 性能优化
   • 用于提交提升性能的代码修改
   • 例如：perf: 优化图片加载速度
7. test: 添加或修改测试
   • 用于提交测试相关的内容
   • 例如：test: 增加用户模块的单元测试
8. chore: 杂项（构建过程或辅助工具的变动）
   • 用于提交构建过程、辅助工具等相关的内容修改
   • 例如：chore: 更新依赖库
9. build: 构建系统或外部依赖项的变更
   • 用于提交影响构建系统的更改
   • 例如：build: 升级webpack到版本5
10. ci: 持续集成配置的变更
    • 用于提交CI配置文件和脚本的修改
    • 例如：ci: 修改GitHub Actions配置文件
11. revert: 回滚
    • 用于提交回滚之前的提交
    • 例如：revert: 回滚feat: 增加用户注册功能

今天学习到原来JPEG文件有两种保存方式他们分别是Baseline JPEG（标准型）和Progressive JPEG（渐进式）。两种格式有相同尺寸以及图像数据，他们的扩展名也是相同的，唯一的区别是二者显示的方式不同。

Baseline JPEG与Progressive JPEG的差异​

Baseline JPEG​

这种类型的JPEG文件存储方式是按从上到下的扫描方式，把每一行顺序的保存在JPEG文件中。打开这个文件显示它的内容时，数据将按照存储时的顺序从上到下一行一行的被显示出来，直到所有的数据都被读完，就完成了整张图片的显示。如果文件较大或者网络下载速度较慢，那么就会看到图片被一行行加载的效果，这种格式的JPEG没有什么优点，因此，一般都推荐使用Progressive JPEG。

Progressive JPEG​

和Baseline一遍扫描不同，Progressive JPEG文件包含多次扫描，这些扫描顺寻的存储在JPEG文件中。打开文件过程中，会先显示整个图片的模糊轮廓，随着扫描次数的增加，图片变得越来越清晰。这种格式的主要优点是在网络较慢的情况下，可以看到图片的轮廓知道正在加载的图片大概是什么。在一些网站打开较大图片时，你就会注意到这种技术。

图片如何保存为Progressive JPEG？​

说了这边多下面就改讲讲怎么讲图片保存为或者转化为Progressive JPEG了。

PhotoShop​

在PS中有“存储为web所用格式”，打开后选择“连续”就是渐进式JPEG。

Linux​

检测是否为progressive jpeg ： identify -verbose filename.jpg | grep Interlace（如果输出 None 说明不是progressive jpeg；如果输出 Plane 说明是 progressive jpeg。）

将basic jpeg转换成progressive jpeg：> convert infile.jpg -interlace Plane outfile.jpg

PHP​

使用imageinterlace和imagejpeg函数我们可以轻松解决转换问题。

<?php
    $im = imagecreatefromjpeg('pic.jpg');
    imageinterlace($im, 1);
    imagejpeg($im, './php_interlaced.jpg', 100);
    imagedestroy($im);
?>

Python​

import PIL
from exceptions import IOError

img = PIL.Image.open("c:\\users\\biaodianfu\\pictures\\in.jpg")
destination = "c:\\users\\biaodianfu\\pictures\\test.jpeg"
try:
    img.save(destination, "JPEG", quality=80, optimize=True, progressive=True)
except IOError:
    PIL.ImageFile.MAXBLOCK = img.size[0] * img.size[1]
    img.save(destination, "JPEG", quality=80, optimize=True, progressive=True)

C#​

using (Image source = Image.FromFile(@"D:\temp\test2.jpg")) { 
    ImageCodecInfo codec = ImageCodecInfo.GetImageEncoders().First(c => c.MimeType == "image/jpeg"); 
    EncoderParameters parameters = new EncoderParameters(3);
    parameters.Param[0] = new EncoderParameter(System.Drawing.Imaging.Encoder.Quality, 100L);
    parameters.Param[1] = new EncoderParameter(System.Drawing.Imaging.Encoder.ScanMethod, (int)EncoderValue.ScanMethodInterlaced);
    parameters.Param[2] = new EncoderParameter(System.Drawing.Imaging.Encoder.RenderMethod, (int)EncoderValue.RenderProgressive); 
    source.Save(@"D:\temp\saved.jpg", codec, parameters);
}

什么是跨域​

什么是同源策略及其限制内容​

同源策略是一种约定，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，浏览器很容易受到XSS、CSRF等攻击。所谓同源是指"协议+域名+端口"三者相同，即便两个不同的域名指向同一个ip地址，也非同源。

同源策略限制了一下行为：

• Cookie、LocalStorage 和 IndexDB 无法读取
• DOM 和 JS 对象无法获取
• Ajax请求发送不出去

跨域​

当协议、域名、端口号中任意一个不相同时，都算作不同域。不同域之间相互请求资源，就算作“跨域”。

注意：跨域请求产生时，请求是发出去了，也是有响应的，仅仅是浏览器同源策略，认为不安全，拦截了结果，不将数据传递我们使用罢了

解决方案如下​

cors​

概念​

• CORS 需要浏览器和后端同时支持
• 浏览器会自动进行 CORS 通信，实现 CORS 通信的关键是后端。只要后端实现了 CORS，就实现了跨域。
• 服务端设置 Access-Control-Allow-Origin 就可以开启 CORS。 该属性表示哪些域名可以访问资源，如果设置通配符则表示所有网站都可以访问资源。
• 虽然设置 CORS 和前端没什么关系，但是通过这种方式解决跨域问题的话，会在发送请求时出现两种情况，分别为简单请求和复杂请求。

简单请求​

只要同时满足以下两大条件，就属于简单请求

• 条件1：使用下列方法之一：

  • GET

  • HEAD

    • POST

• 条件2：HTTP的头信息不超出以下几种字段

  • Accept

  • Accept-Language

  • Content-Language

  • Last-Event-ID

  • Content-Type 的值仅限于下列三者之一：

    • text/plain

    • multipart/form-data

    • application/x-www-form-urlencoded

复杂请求​

不符合以上条件的请求就肯定是复杂请求了。 复杂请求的CORS请求，会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求,该请求是 option 方法的，通过该请求来知道服务端是否允许跨域请求。

JSONP​

JSONP原理​

利用 <script> 标签没有跨域限制，网页可以得到从其他来源动态产生的 JSON 数据。JSONP请求一定需要对方的服务器做支持才可以。

JSONP和AJAX对比​

JSONP和AJAX相同，都是客户端向服务器端发送请求，从服务器端获取数据的方式。但AJAX属于同源策略，JSONP属于非同源策略（跨域请求）

JSONP缺点​

JSONP优点是简单兼容性好，可用于解决主流浏览器的跨域数据访问的问题。缺点是仅支持get方法具有局限性,不安全可能会遭受XSS攻击。

nginx反向代理​

服务器配置代理服务器

#如果监听到请求接口地址是 www.xxx.com/api/page ，nginx就向http://www.yyy.com:9999/api/page这个地址发送请求
server {
        listen       80; 
        server_name  www.xxx.com;
        #判过滤出含有api的请求
        location /api/ { 
            proxy_pass http://www.yyy.com:9999; #真实服务器的地址
        }
}

proxy代理服务器​

// vue.config.js/webpack.config.js 
// 优点：可以配置多个代理，且可灵活控制请求是否走代理 
// 缺点：配置繁琐，发起代理请求时必须加上配置好的前缀
module.exports={
    devServer:{
        proxy:{
            '/api01':{
                target:'http://xxx.xxx.xxx:5000',
                changeOrigin:true,
                // 重写请求，根据接口详情，判断是否需要
                pathRewrite:{
                    '^/api01':''
                }
            },
            '/api02':{
                target:'http://xxx.xxx.xxx:5001',
                changeOrigin:true,
                // 重写请求，根据接口详情，判断是否需要
                pathRewrite:{
                    '^/api02':''
                }
            }
        }
    }
}
// changeOrigin设置为true时，服务器收到的请求头的host与服务器地址相同
// changeOrigin设置为false时，服务器收到的请求头的host与前端地址相同

websocket​

WebSocket 协议是一种基于 TCP 的通信协议，与 HTTP 协议不同，它不受同源策略的限制，没有使用HTTP响应头，因此也没有跨域的限制

window.name + iframe​

window.name属性可设置或者返回存放窗口名称的一个字符串。他的神器之处在于name值在不同页面或者不同域下加载后依旧存在，没有修改就不会发生变化，并且可以存储非常长的name(2MB)

其中a.html和b.html是同域的，都是http://localhost:3000;而c.html是http://localhost:4000

 // a.html(http://localhost:3000/b.html)
  <iframe src="http://localhost:4000/c.html" frameborder="0" onload="load()" id="iframe"></iframe>
  <script>
    let first = true
    // onload事件会触发2次，第1次加载跨域页，并留存数据于window.name
    function load() {
      if(first){
      // 第1次onload(跨域页)成功后，切换到同域代理页面
        let iframe = document.getElementById('iframe');
        iframe.src = 'http://localhost:3000/b.html';
        first = false;
      }else{
      // 第2次onload(同域b.html页)成功后，读取同域window.name中数据
        console.log(iframe.contentWindow.name);
      }
    }
  </script>

b.html为中间代理页，与a.html同域，内容为空。

 // c.html(http://localhost:4000/c.html)
  <script>
    window.name = '我不爱你'  
  </script>

location.hash + iframe​

原理就是通过 url 带 hash ，通过一个非跨域的中间页面来传递数据

一开始 a.html 给 c.html 传一个 hash 值，然后 c.html 收到 hash 值后，再把 hash 值传递给 b.html，最后 b.html 将结果放到 a.html 的 hash 值中。 同样的，a.html 和 b.htm l 是同域的，都是 http://localhost:8000，而 c.html 是http://localhost:8080

// a.html
<iframe src="http://localhost:8080/hash/c.html#name1"></iframe>
<script>
  console.log(location.hash);
  window.onhashchange = function() {
    console.log(location.hash);
  };
</script>

// b.html
<script>
  window.parent.parent.location.hash = location.hash;
</script>

// c.html
<body></body>
<script>
  console.log(location.hash);
  const iframe = document.createElement("iframe");
  iframe.src = "http://localhost:8000/hash/b.html#name2";
  document.body.appendChild(iframe);
</script>

document.domain + iframe​

该方式只能用于二级域名相同的情况下，比如 a.test.com 和 b.test.com 适用于该方式。 只需要给页面添加 document.domain ='test.com' 表示二级域名都相同就可以实现跨域。

实现原理：两个页面都通过js强制设置document.domain为基础主域，就实现了同域。

我们看个例子：页面a.zf1.cn:3000/a.html获取页面b.zf1.cn:3000/b.html中a的值

// a.html
<body>
 helloa
  <iframe src="http://b.zf1.cn:3000/b.html" frameborder="0" onload="load()" id="frame"></iframe>
  <script>
    document.domain = 'zf1.cn'
    function load() {
      console.log(frame.contentWindow.a);
    }
  </script>
</body>

// b.html
<body>
   hellob
   <script>
     document.domain = 'zf1.cn'
     var a = 100;
   </script>
</body>

不允许iframe的设置​

添加X-Frame-Options响应头，值为deny

for 循环100000次​

最直接的方式就是直接渲染出来，但是这样的做法肯定是不可取的，因为一次性渲染出10w个节点，是非常耗时间的

const renderList = async () => {
    console.time('列表时间')
    const list = await getList()
    list.forEach(item => {
        const div = document.createElement('div')
        div.className = 'sunshine'
        div.innerHTML = `<img src="${item.src}" /><span>${item.text}</span>`
        container.appendChild(div)
    })
    console.timeEnd('列表时间')
}
renderList()

setTimeout分页渲染(时间分片)​

这个方法就是，把10w按照每页数量limit分成总共Math.ceil(total / limit)页，然后利用setTimeout，每次渲染1页数据，这样的话，渲染出首页数据的时间大大缩减了

const renderList = async () => {
    console.time('列表时间')
    const list = await getList()
    console.log(list)
    const total = list.length
    const page = 0
    const limit = 200
    const totalPage = Math.ceil(total / limit)

    const render = (page) => {
        if (page >= totalPage) return
        setTimeout(() => {
            for (let i = page * limit; i < page * limit + limit; i++) {
                const item = list[i]
                const div = document.createElement('div')
                div.className = 'sunshine'
                div.innerHTML = `<img src="${item.src}" /><span>${item.text}</span>`
                container.appendChild(div)
            }
            render(page + 1)
        }, 0)
    }
    render(page)
    console.timeEnd('列表时间')
}

requestAnimationFrame​

requestAnimationFrame 和 setTimeout 的区别：

• requestAnimationFrame的调用频率通常为每秒60次。这意味着我们可以在每次重绘之前更新动画的状态，并确保动画流畅运行，而不会对浏览器的性能造成影响。
• setInterval与setTimeout它可以让我们在指定的时间间隔内重复执行一个操作，不考虑浏览器的重绘，而是按照指定的时间间隔执行回调函数，可能会被延迟执行，从而影响动画的流畅度。

使用requestAnimationFrame代替setTimeout，减少了重排的次数，极大提高了性能，建议大家在渲染方面多使用requestAnimationFrame

requestAnimationFrame不是定时器！不是定时器！！！只是一个用作定时器的帧函数

const renderList = async () => {
    console.time('列表时间')
    const list = await getList()
    console.log(list)
    const total = list.length
    const page = 0
    const limit = 200
    const totalPage = Math.ceil(total / limit)

    const render = (page) => {
        if (page >= totalPage) return
        // 使用requestAnimationFrame代替setTimeout
        requestAnimationFrame(() => {
            for (let i = page * limit; i < page * limit + limit; i++) {
                const item = list[i]
                const div = document.createElement('div')
                div.className = 'sunshine'
                div.innerHTML = `<img src="${item.src}" /><span>${item.text}</span>`
                container.appendChild(div)
            }
            render(page + 1)
        })
    }
    render(page)
    console.timeEnd('列表时间')
}

文档碎片 + requestAnimationFrame​

先解释一下什么是 DocumentFragment ，文献引用自MDN

DocumentFragment，文档片段接口，表示一个没有父级文件的最小文档对象。它被作为一个轻量版的`Document`使用，用于存储已排好版的或尚未打理好格式的XML片段。最大的区别是因为`DocumentFragment`不是真实DOM树的一部分，它的变化不会触发DOM树的（重新渲染) ，且不会导致性能等问题。可以使用`document.createDocumentFragment`方法或者构造函数来创建一个空的`DocumentFragment

文档碎片的好处

• 之前都是每次创建一个div标签就appendChild一次，但是有了文档碎片可以先把1页的div标签先放进文档碎片中，然后一次性appendChild到container中，这样减少了appendChild的次数，极大提高了性能
• 页面只会渲染文档碎片包裹着的元素，而不会渲染文档碎片

const renderList = async () => {
    console.time('列表时间')
    const list = await getList()
    console.log(list)
    const total = list.length
    const page = 0
    const limit = 200
    const totalPage = Math.ceil(total / limit)

    const render = (page) => {
        if (page >= totalPage) return
        requestAnimationFrame(() => {
            // 创建一个文档碎片
            const fragment = document.createDocumentFragment()
            for (let i = page * limit; i < page * limit + limit; i++) {
                const item = list[i]
                const div = document.createElement('div')
                div.className = 'sunshine'
                div.innerHTML = `<img src="${item.src}" /><span>${item.text}</span>`
                // 先塞进文档碎片
                fragment.appendChild(div)
            }
            // 一次性appendChild
            container.appendChild(fragment)
            render(page + 1)
        })
    }
    render(page)
    console.timeEnd('列表时间')
}

懒加载​

一句话解释：最开始不渲染所有数据，只展示视图上可见的数据，当滚动到页面底部时，加载更多数据

• 位置计算 + 滚动事件 (Scroll) + DataSet API

  • clientTop，offsetTop，clientHeight 以及 scrollTop 各种关于图片的高度作比对

  • 监听 window.scroll 事件

  • // 控制图片懒加载
    <img data-src="shanyue.jpg" />
    // 首先设置一个临时 Data 属性 data-src，控制加载时使用 src 代替 data-src，可利用 DataSet API 实现
     img.src = img.datset.src   
    

• getBoundingClientRect API + Scroll with Throttle + DataSet API

  • 如何判断图片出现在了当前视口？
  • Element.getBoundingClientRect() 方法返回元素的大小及其相对于视口的位置。img.getBoundingClientRect().top < document.documentElement.clientHeight;

• IntersectionObserver api

  • 上一个方案使用的方法是: window.scroll 监听 Element.getBoundingClientRect() 并使用 _.throttle 节流
  • 浏览器出了一个三合一事件: IntersectionObserver API，一个能够监听元素是否到了当前视口的事件，一步到位！

虚拟列表​

概念​

虚拟列表其实是按需显示的一种实现，即只对可见区域进行渲染，对非可见区域中的数据不渲染或部分渲染的技术，从而达到极高的渲染性能。

假设有1万条记录需要同时渲染，我们屏幕的可见区域的高度为500px,而列表项的高度为50px，则此时我们在屏幕中最多只能看到10个列表项，那么在首次渲染的时候，我们只需加载10条即可。为了防止滑动过快导致的白屏现象，我们可以使用预加载的方式多加载一些数据出来。

实现​

实现屏加载的时候，只加载可视区域内需要的列表项，当滚动发生时，动态通过计算获得可视区域内的列表项，并将非可视区域内存在的列表项删除。

• 计算当前可视区域起始数据索引(startIndex)
• 计算当前可视区域结束数据索引(endIndex)
• 计算当前可视区域的数据，并渲染到页面中
• 计算startIndex对应的数据在整个列表中的偏移位置startOffset并设置到列表上

由于只是对可视区域内的列表项进行渲染，所以为了保持列表容器的高度并可正常的触发滚动，将Html结构设计成如下结构：

<div class="infinite-list-container">
    <div class="infinite-list-phantom"></div>
    <div class="infinite-list">
      <!-- item-1 -->
      <!-- item-2 -->
      <!-- ...... -->
      <!-- item-n -->
    </div>
</div>

• infinite-list-container 为可视区域的容器
• infinite-list-phantom 为容器内的占位，高度为总列表高度，用于形成滚动条
• infinite-list 为列表项的渲染区域

接着，监听infinite-list-container的scroll事件，获取滚动位置scrollTop

• 假定可视区域高度固定，称之为screenHeight
• 假定列表每项高度固定，称之为itemSize
• 假定列表数据称之为listData
• 假定当前滚动位置称之为scrollTop

则可推算出：

• 列表总高度listHeight = listData.length * itemSize
• 可显示的列表项数visibleCount = Math.ceil(screenHeight / itemSize)
• 数据的起始索引startIndex = Math.floor(scrollTop / itemSize)
• 数据的结束索引endIndex = startIndex + visibleCount
• 列表显示数据为visibleData = listData.slice(startIndex,endIndex)

当滚动后，由于渲染区域相对于可视区域已经发生了偏移，此时我需要获取一个偏移量startOffset，通过样式控制将渲染区域偏移至可视区域中。

• 偏移量startOffset = scrollTop - (scrollTop % itemSize)

简易代码​

最终的简易代码如下：

<template>
  <div ref="list" class="infinite-list-container" @scroll="scrollEvent($event)">
    <div class="infinite-list-phantom" :style="{ height: listHeight + 'px' }"></div>
    <div class="infinite-list" :style="{ transform: getTransform }">
      <div ref="items"
        class="infinite-list-item"
        v-for="item in visibleData"
        :key="item.id"
        :style="{ height: itemSize + 'px',lineHeight: itemSize + 'px' }"
      >{{ item.value }}</div>
    </div>
  </div>
</template>

<script>
export default {
  name:'VirtualList',
  props: {
    //所有列表数据
    listData:{
      type:Array,
      default:()=>[]
    },
    //每项高度
    itemSize: {
      type: Number,
      default:200
    }
  },
  computed:{
    //列表总高度
    listHeight(){
      return this.listData.length * this.itemSize;
    },
    //可显示的列表项数
    visibleCount(){
      return Math.ceil(this.screenHeight / this.itemSize)
    },
    //偏移量对应的style
    getTransform(){
      return `translate3d(0,${this.startOffset}px,0)`;
    },
    //获取真实显示列表数据
    visibleData(){
      return this.listData.slice(this.start, Math.min(this.end,this.listData.length));
    }
  },
  mounted() {
    this.screenHeight = this.$el.clientHeight;
    this.start = 0;
    this.end = this.start + this.visibleCount;
  },
  data() {
    return {
      //可视区域高度
      screenHeight:0,
      //偏移量
      startOffset:0,
      //起始索引
      start:0,
      //结束索引
      end:null,
    };
  },
  methods: {
    scrollEvent() {
      //当前滚动位置
      let scrollTop = this.$refs.list.scrollTop;
      //此时的开始索引
      this.start = Math.floor(scrollTop / this.itemSize);
      //此时的结束索引
      this.end = this.start + this.visibleCount;
      //此时的偏移量
      this.startOffset = scrollTop - (scrollTop % this.itemSize);
    }
  }
};          
</script>

多大量数据进行处理 — Web Worker​

因为js是单线程运行的，在遇到一些需要处理大量数据的js时，可能会阻塞页面的加载，造成页面的假死。

在HTML5的新规范中，实现了 Web Worker 来引入 js 的 “多线程” 技术, 可以让我们在页面主运行的 js 线程中，加载运行另外单独的一个或者多个 js 线程

一句话： Web Worker专门处理复杂计算的，从此让前端拥有后端的计算能力

参考链接​

后端一次给你10万条数据，如何优雅展示 - 掘金 (juejin.cn)

高性能渲染十万条数据(虚拟列表) - 掘金 (juejin.cn)

写在前面​

我们知道，HTTP 是无状态的。也就是说，HTTP 请求方和响应方间无法维护状态，都是一次性的，它不知道前后的请求都发生了什么。

但有的场景下，我们需要维护状态。最典型的，一个用户登陆微博，发布、关注、评论，都应是在登录后的用户状态下的。我们知道，HTTP 是无状态的。也就是说，HTTP 请求方和响应方间无法维护状态，都是一次性的，它不知道前后的请求都发生了什么。

但有的场景下，我们需要维护状态。最典型的，一个用户登陆微博，发布、关注、评论，都应是在登录后的用户状态下的。

Session 、 Cookie 和 token 的主要目的就是为了弥补 HTTP 的无状态特性。

什么是cookie​

• cookie 存储在客户端： cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。

• cookie 是不可跨域的： 每个 cookie 都会绑定单一的域名，无法在别的域名下获取使用，一级域名和二级域名之间是允许共享使用的（靠的是 domain）。

  • Domain属性指定浏览器发出 HTTP 请求时，哪些域名要附带这个 Cookie。如果没有指定该属性，浏览器会默认将其设为当前 URL 的一级域名，比如 www.example.com 会设为 example.com，而且以后如果访问example.com的任何子域名，HTTP 请求也会带上这个 Cookie。如果服务器在Set-Cookie字段指定的域名，不属于当前域名，浏览器会拒绝这个 Cookie。

什么是session​

• session 是另一种记录服务器和客户端会话状态的机制
• session 是基于 cookie 实现的，session 存储在服务器端，sessionId 会被存储到客户端的cookie 中

session验证流程​

• 用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的 Session
• 请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器
• 浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名
• 当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。

根据以上流程可知，SessionID 是连接 Cookie 和 Session 的一道桥梁，大部分系统也是根据此原理来验证用户登录状态。

cookie和session的区别​

• 安全性： Session 比 Cookie 安全，Session 是存储在服务器端的，Cookie 是存储在客户端的。
• 存取值的类型不同：Cookie 只支持存字符串数据，想要设置其他类型的数据，需要将其转换成字符串，Session 可以存任意数据类型。
• 有效期不同： Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭（默认情况下）或者 Session 超时都会失效
• 存储大小不同： 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie，但是当访问量过多，会占用过多的服务器资源。

什么是token​

Token是在身份验证和授权过程中广泛使用的一种机制，用于确认用户的身份并获得权限。它通常是一个字符串，由服务器生成并返回给客户端（例如，Web浏览器或移动应用程序）。Token在客户端和服务器之间进行传递，用于识别和验证用户。

token身份验证流程​

1. 客户端使用用户名跟密码请求登录
2. 服务端收到请求，去验证用户名与密码
3. 验证成功后，服务端会签发一个 token 并把这个 token 发送给客户端
4. 客户端收到 token 以后，会把它存储起来，比如放在 cookie 里或者 localStorage 里
5. 客户端每次向服务端请求资源的时候需要带着服务端签发的 token
6. 服务端收到请求，然后去验证客户端请求里面带着的 token ，如果验证成功，就向客户端返回请求的数据

• 每一次请求都需要携带 token，需要把 token 放到 HTTP 的 Header 里
• 基于 token 的用户认证是一种服务端无状态的认证方式，服务端不用存放 token 数据。用解析 token 的计算时间换取 session 的存储空间，从而减轻服务器的压力，减少频繁的查询数据库
• token 完全由应用管理，所以它可以避开同源策略

token和session的区别​

1. 定义和作用：
   • Token（令牌）：Token是在身份验证和授权过程中用于确认用户身份和获得权限的一种机制。它通常是一个字符串，由服务器生成并返回给客户端，用于在客户端和服务器之间传递身份验证和授权信息。
   • Session（会话）：Session是服务器端用于维护用户状态和身份信息的一种机制。服务器为每个客户端创建一个会话，用于跟踪用户的状态，通过Session ID标识不同的会话。
2. 存储位置：
   • Token：Token通常存储在客户端，比如浏览器的Cookie或本地存储中，以便客户端可以将其附加到后续请求中。
   • Session：Session数据通常存储在服务器端，而不是在客户端。服务器通过Session ID来标识每个客户端的会话状态。
3. 状态维护：
   • Token：Token是无状态的，服务器不需要在后端存储Token的状态信息，因为所有必要的信息都包含在Token本身中。
   • Session：Session是有状态的，服务器需要在后端维护会话状态信息，以便跟踪用户状态和保存临时数据。
4. 应用场景：
   • Token：Token在Web API、移动应用和分布式系统中广泛使用，特别适合跨服务器进行身份验证和授权。
   • Session：Session通常在传统的Web应用中使用，用于跟踪用户状态和保存用户相关的数据。
5. 安全性：
   • Token：由于Token包含所有必要的验证信息，因此必须谨慎处理，确保其不被非法获取或篡改，通常通过加密和签名来增加安全性。
   • Session：Session数据存储在服务器端，相对较安全，但仍然需要采取措施防止会话劫持和其他安全漏洞。

有了 Cookie 为什么还需要 Token​

Cookie 作为 HTTP 规范，其出现历史久远，因此存在一些历史遗留问题，比如跨域限制等，并且 Cookie 作为 HTTP 规范中的内容，其存在默认存储以及默认发送的行为，存在一定的安全性问题。相较于 Cookie，token 需要自己存储，自己进行发送，不存在跨域限制，因此 Token 更加的灵活，没有 Cookie 那么多的“历史包袱”束缚，在安全性上也能够做更多的优化。

Token 有什么 优势？​

Token的无状态特性、安全性、可扩展性以及跨平台和跨语言的支持，使得它成为现代Web应用和API身份验证和授权的首选机制。

单页面程序(SPA)​

概念

单页应用程序(SPA)全称是: Single-page application，SPA应用是在客户端渲染的（我们称之为CSR）

• SPA应用默认只返回一个空HTML页面，如body只有<div id= "app”></div>
• 而整个应用程序的内容都是通过Javascript动态加载，包括应用程序的逻辑、UI以及与服务器通信相关的所有数据。
• 常见的SPA应用框架有Vue、React等

优点

• 只需加载一次：SPA应用程序只需要在第一次请求时加载页面,页面切换不需重新加载，而传统的Web应用程序必须在每次请求时都得加载页面，需要花费更多时间。因此，SPA页面加载速度要比传统 Web应用程序更快。

• 更好的用户体验

  • SPA提供类似于桌面或移动应用程序的体验。用户切换页面不必重新加载新页面
  • 切换页面只是内容发生了变化，页面并没有重新加载，从而使体验变得更加流畅

• 可轻松的构建功能丰富的Web应用程序

缺点

• SPA应用默认只返回一个空HTML页面，不利于SEO
• 首屏加载的资源过大时，一样会影响首屏的渲染
• 也不利于构建复杂的项目，复杂Web应用程序的大文件可能变得难以维护

客户端渲染(CSR)​

渲染流程：浏览器请求url --> 服务器返回index.html(空body、白屏) --> 再次请求bundle.js、路由分析 --> 浏览器渲染

bundle.js体积越大，会导致浏览器白屏时间越长。

静态站点生成(SSG)​

概念

静态站点生成(SSG)全称是: Static Site Generate，是预先生成好的静态网站。

• SSG应用一般在构建阶段就确定了网站的内容。
• 如果网站的内容需要更新了，那必须得重新再次构建和部署。
• 构建SSG应用常见的库和框架有: Vue Nuxt、React Next.js 等。

优点

• 访问速度非常快，因为每个页面都是在构建阶段就已经提前生成好了。
• 直接给浏览器返回静态的HTML，也有利于SEO
• SSG应用依然保留了SPA应用的特性，比如:前端路由、响应式数据、虚拟DOM等

缺点

• 页面都是静态，不利于展示实时性的内容，实时性的更适合SSR。
• 如果站点内容更新了，那必须得重新再次构建和部署。

服务器端渲染(SSR)​

概念

服务器端渲染全称是: Server Side Render，在服务器端渲染页面，并将渲染好HTML返回给浏览器呈现。

• SSR应用的页面是在服务端渲染的，用户每请求一个SSR页面都会先在服务端进行渲染，然后将渲染好的页面，返回给浏览器呈现。
• 构建SSR应用常见的库和框架有: Vue Nuxt、React Next.js等(SSR应用也称同构应用)。

优点

• 更快的首屏渲染速度
  • 浏览器显示静态页面的内容要比JavaScript动态生成的内容快得多。
  • 当用户访问首页时可立即返回静态页面内容，而不需要等待浏览器先加载完整个应用程序。
• 更好的SEO
  • 爬虫是最擅长爬取静态的HTML页面，服务器端直接返回一个静态的HTML给浏览器。
  • 这样有利于爬虫快速抓取网页内容，并编入索引，有利于SEO。
  • SSR应用程序在Hydration 之后依然可以保留Web应用程序的交互性。比如:前端路由、响应式数据、虚拟DOM等。

缺点

• SSR通常需要对服务器进行更多API调用，以及在服务器端渲染需要消耗更多的服务器资源，成本高。
• 增加了一定的开发成本，用户需要关心哪些代码是运行在服务器端，哪些代码是运行在浏览器端。
• SSR配置站点的缓存通常会比SPA站点要复杂一点。

渲染流程

• 阶段一：浏览器请求url --> 服务器路由分析、执行渲染 --> 服务器返回index.html(实时渲染的内容，字符串) --> 浏览器渲染
• 阶段二：浏览器请求bundle.js --> 服务器返回bundle.js --> 浏览器路由分析、生成虚拟DOM --> 比较DOM变化、绑定事件 --> 二次渲染

前言​

个人平时比较喜欢捣鼓一些前端的技术，在和群友聊天的时候，了解到了微前端这个概念

然后在实习的时候公司也用到了微前端的相关概念，使用iframe将多个子应用嵌套在一起

在维护项目的时候，感觉不管是启动还是加应用的速度都是比较慢的

在后面有时间的时候我就捣鼓捣鼓了当前比较流行的微前端框架：qiankun

今天来纪录一些关于微前端的一些知识

如果你想了解我关于微前端的简单应用，直达链接：qiankun的使用 - 鲸落 (xiaojunnan.cn)

为什么要使用微前端​

当前，基于 vue、react、angular 的单页应用开发模式已经成为业界主流。受益于它们丰富的生态，我们可以使用这些技术快速构建一个新的应用，迅速响应市场。随着公司业务的不断发展，应用开始变得庞大臃肿，逐渐成为一个巨石应用，难以维护不说，每次开发、上线新需求时还需要花费不少的时间来构建项目，对开发人员的开发效率和体验都造成了不好的影响。因此将一个巨石应用拆分为多个子应用势在必行。

一般情况下，我们会基于业务来拆分应用。每个应用都有一个自己的仓库，独立开发、独立部署、独立访问、独立维护，还可以根据团队的特点自主选择适合自己的技术栈，极大的提升了开发人员的效率和体验。

应用拆分能给我们带来便利，但同时也给我们带来了新的挑战，那就是应用的聚合。对于客户来说，他们在使用我们的产品时，更希望呈现在自己面前的是一个完整的应用，而不是分散的多个子应用。因此我们需要选择一个合适的方案，能兼容不同的技术栈，将已经拆分的子应用重新聚合。

而微前端，正是这样一个合适的方案，来帮助我们面对上述挑战。

什么是微前端​

微前端，早已是一个老生常谈的概念，它于 2016 年首次出现在 ThoughtWorks Technology Radar 上，将后端微服务的概念扩展到了前端世界。

微服务，维基上对其定义为：一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，将应用程序构造为一组松散耦合的服务，并通过轻量级的通信协议组织起来。具体来讲，就是将一个单体应用，按照一定的规则拆分为一组服务。这些服务，各自拥有自己的仓库，可以独立开发、独立部署，有独立的边界，可以由不同的团队来管理，甚至可以使用不同的编程语言来编写。但对前端来说，仍然是一个完整的服务。

微服务，主要是用来解决庞大的一整块后端服务带来的变更和扩展的限制。

同样的，面对越来越重的前端应用，可将微服务的思想照搬到前端，就有了微前端的概念。像微服务一样，一个前端应用，也可以按照一定的规则，拆分为不同的子应用，独立开发，独立部署，然后聚合成一个完整的应用面对客户。

微前端能给我们带来什么​

• 独立开发、独立部署
• 技术栈无关
• 简单、分离、松耦合的代码仓库
• 遗留系统迁移
  • 对于一些使用老技术栈开发的应用，我们没有理由浪费时间和精力，可以通过微前端方案直接整合到新的应用中。
• 技术栈升级
  • 我们可以重起一个应用，循序渐进的重构应用，然后使用微前端方案将新旧应用聚合在一起。

使用微前端面临的挑战​

微前端方案给我们带来巨大便利的同时，也给我们带来了新的挑战。在实现微前端应用时，我们必须要考虑以下问题：

• 子应用切换
• 应用相互隔离，互不干扰
• 子应用之间通信
• 多个子应用并存
• 用户状态的存储 - 免登

微前端常用技术方案​

总结​

目前，业界主流的微前端实现方案主要有：

• 路由分发式微前端
• iframe
• single-spa
• qiankun
• webpack5：module federation
• Web Component

路由分发式微前端​

路由分发式微前端，即通过路由将不同的业务分发到不同的独立前端应用上。最常用的方案是通过 HTTP 服务的反向代理来实现。

在部署服务器的时候设置代理，请求不通的路径

 http {
        server {
            listen 80;
            server_name  xxx.xxx.com;
            location /api/ {
                proxy_pass http://localhost:3001/api;
            }
            location /web/admin {
                proxy_pass http://localhost:3002/api;
            }
            location / {
                proxy_pass /;
            }
        }
    }

优点：

• 实现简单
• 不需要对现有应用进行改造
• 完全技术栈无关

缺点：

• 用户体验不好，每次切换应用时，浏览器都需要重新加载页面
• 多个子应用无法并存
• 局限性比较大
• 子应用之间的通信比较困难
• 子应用切换时需要重新登录

iframe​

iframe 作为一项非常古老的技术，也可以用于实现微前端。通过 iframe，我们可以很方便的将一个应用嵌入到另一个应用中，而且两个应用之间的 css 和 javascript 是相互隔离的，不会互相干扰。

优点：

• 实现简单
• css 和 js 天然隔离，互不干扰
• 完全技术栈无关
• 多个子应用可以并存
• 不需要对现有应用进行改造

缺点：

• 用户体验不好，每次切换应用时，浏览器需要重新加载页面
• UI 不同步，DOM 结构不共享
• 全局上下文完全隔离，内存变量不共享，子应用之间通信、数据同步过程比较复杂
• 对 SEO 不友好
• 子应用切换时可能需要重新登录，体验不好

single-spa​

官网：single-spa

路由转发模式、iframe 模式尽管可以实现微前端，但是体验不好。我们每次切换回已经访问过的子应用时，都需要重新加载子应用，对性能有很大的影响。

我们知道，现在前端应用开发的主流模式为基于 vue / react/ angular 的单页应用开发模式。在这种模式下，我们需要维护一个路由注册表，每个路由对应各自的页面组件 url。切换路由时，如果是一个新的页面，需要动态获取路由对应的 js 脚本，然后执行脚本并渲染出对应的页面；如果是一个已经访问过的页面，那么直接从缓存中获取已缓存的页面方法，执行并渲染出对应的页面。

那么，微前端也有没有类似的实现方案，来获得和单页应用一样的用户体验呢？

答案是有的。 single-spa 提供了新的技术方案，可以帮忙我们实现类似单页应用的体验。

在 single-spa 方案中，应用被分为两类：基座应用和子应用。其中，子应用就是文章上面描述的需要聚合的子应用；而基座应用，是另外的一个单独的应用，用于聚合子应用。

和单页应用的实现原理类似，single-spa 会在基座应用中维护一个路由注册表，每个路由对应一个子应用。基座应用启动以后，当我们切换路由时，如果是一个新的子应用，会动态获取子应用的 js 脚本，然后执行脚本并渲染出相应的页面；如果是一个已经访问过的子应用，那么就会从缓存中获取已经缓存的子应用，激活子应用并渲染出对应的页面。

优点：

• 切换应用时，浏览器不用重载页面，提供和单页应用一样的用户体验
• 完全技术栈无关
• 多个子应用可并存
• 生态丰富

缺点：

• 需要对原有应用进行改造，应用要兼容接入 sing-spa 和独立使用
• 有额外的学习成本
• 使用复杂，关于子应用加载、应用隔离、子应用通信等问题，需要框架使用者自己实现
• 子应用间相同资源重复加载
• 启动应用时，要先启动基座应用

qiankun​

官网：qiankun

和 single-spa 一样，qiankun 也能给我们提供类似单页应用的用户体验。qiankun 是在 single-spa 的基础上做了二次开发，在框架层面解决了使用 single-spa 时需要开发人员自己编写子应用加载、通信、隔离等逻辑的问题

优点：

• 切换应用时，浏览器不用重载页面，提供和单页应用一样的用户体验
• 相比 single-spa，解决了子应用加载、应用隔离、子应用通信等问题，使用起来相对简单
• 完全和技术栈无关
• 多个子应用可并存

缺点：

• 需要对原有应用进行改造，应用要兼容接入 qiankun 和独立使用
• 有额外的学习成本
• 相同资源重复加载
• 启动应用时，要先启动基座应用

webpack5：module federation​

webpack5，提供了一个新的特性 - module federation。基于这个特性，我们可以在一个 javascript 应用中动态加载并运行另一个 javascript 应用的代码，并实现应用之间的依赖共享。

通过 module federation，我们可以在一个应用里面动态渲染另一个应用的页面，这样也就实现了多个子应用的聚合。

优点：

• 不需要对原有应用进行改造，只需改造打包脚本
• 切换应用时，浏览器不用重载页面，提供和单页应用一样的用户体验
• 多个子应用可并存
• 相同资源不需要重复加载
• 开发技术栈无关
• 应用启动后，无需加载与自己无关的资源
• 免登友好

缺点：

• 构建工具只能使用 webpack5
• 有额外的学习成本
• 对老项目不友好，需要对 webpack 进行改造

Web Component​

案例：京东的开源微前端框架 MicroApp (micro-zoe.github.io)

基于 Web Component 的 Shadow Dom 能力，我们也可以实现微前端，将多个子应用聚合起来。

优点：

• 实现简单
• css 和 js 天然隔离，互不干扰
• 完全技术栈无关
• 多个子应用可以并存
• 不需要对现有应用进行改造

缺点：

• 主要是浏览器兼容性问题
• 开发成本较高

写在最后​

还有许多优秀的微前端框架，如字节跳动的Garfish， 阿里飞冰团队的icestark 等等。有需要了解的可以深入了解一下

参考链接

微前端学习系列(一)：微前端介绍 - 掘金 (juejin.cn)