MVC、MVVM、AOP 和 IOC 的原理

MVC: 将应用分为三部分：Model（数据和业务逻辑）、View（用户界面）和 Controller（处理输入和更新视图）。Controller 接收用户输入并操作 Model，Model 更新后通知 View 刷新

MVVM: 在 MVVM 模式中，ViewModel 充当 Model 和 View 之间的桥梁。它通过数据绑定实现 View 的自动更新，减少手动操作，提高开发效率。View 通过双向绑定与 ViewModel 交互

AOP: 将关注点分离，实现横切关注点的模块化, 使用装饰器或代理模式可以在不修改原有代码的情况下，增强功能或添加新行为

IOC: 将对象的创建和管理交给外部容器; 通过依赖注入，服务可以在运行时动态注入到需要的类中，使得组件之间的关系更加灵活。

脚手架

SSR权限加载流程

获取后端返回路由
根据Client的路由，即不必要在后端返回的路由，以此为基础，将后端返回的用户权限信息根据路由规则进行解析，我做的时候图省事采用了递归处理
后处理。如果需要，打平所有子路由 & 过滤空路由或是route.meta.show为false的路由
最后讲解析和过滤完毕的路由添加入当前路由表

Excel多sheet前端解析

基于npm xlsx包

传递给函数Blob raw数据
创建ArrayBuffer && 按数组读取excel && 获取workbook中的信息
循环遍历所有sheet，按sheetname定位sheet
取出要用的值，返回promise
对大数据量情况下使用虚拟列表

文件上传与下载

file-saver包 || blob手搓

breadcrumb动态去重历史记录

核心是路由守卫，在hook中每次进入路由都添加一个历史记录信息
存放到缓存中，对其进行some遍历
filter

后台侧边栏

还是路由表信息

全局错误提示

设置axios interceptor全局错误提示与重定向
apis下的api调用axios实例

性能优化

怎么从前端的角度减少首页的白屏时间？

如果减少请求的数据之后，首页渲染时间还是不达标？应该怎么办？

怎样加快网页二次渲染速度？（除了缓存、懒加载之外的方法）

页面性能指标

性能是否优化，需要有量化标准，不能是从主观出发而落点在客观的“优化”的优化

以客观的量化标准，来优化主观上的体验；以有限应对无限

核心库：web-vitals

首次内容绘制 (First Contentful Paint，FCP)
[用户主观体验] 率先出现的文本图像等视觉可见内容，直接决定了用户对页面加载速度的主观体验
```
任意部分的DOM完成渲染所需时间

优    0-1.8
中    1.8-3
差    >3
```
最大内容绘制 (Largest Contentful Paint，LCP)
[整体渲染速度] 尺寸最大的内容往往最能吸引用户的注意力，其渲染耗时，直接影响了用户对页面整体渲染速度的体验
```
从页面开始加载到可视区域内的，尺寸最大的文字或图像渲染所需时间

优    0-2.5
中    2.5-4
差    >4
```

首次输入延迟 (First Input Delay ，FID)

[流畅度的第一印象]

首次交互（点击、触摸）到浏览器开始响应之间的时间间隔

优    0-0.1
中    0.1-0.3
差    >0.3

交互到绘制延迟（Interaction to Next Paint，INP）

[新指标] 关注所有交互

所有交互（点击、键盘输入、触摸等）与浏览器渲染响应的整体延迟情况

优    0-0.2
中    0.2-0.5
差    >0.5

累积布局偏移 (Cumulative Layout Shift，CLS)

[当前代码逻辑对用户体验的影响程度]

意外布局变化的累计分值，意外布局变化是指 DOM 元素在前后绘制的2帧之间，非用户交互引起DOM元素尺寸、位置的变化；
一般情况是：本要点击取消，但是布局变化，原本是“取消”的位置变为了确认；类似诈骗手段

优    0-0.1
中    0.1-0.25
差    >0.25

第一字节时间 (Time to First Byte，TTFB)

[FCP和LCP的辅助指标] 影响初始内容渲染耗时的长短

HTTP请求发送后，到接收到第一字节数据响应的耗时；包括重定向、DNS查询、服务器响应延迟等耗时

优    0-0.8
中    0.8-1.8
差    >0.1.8

其它：接口响应时长、白屏率、prefetch

CSR与SSR

客户端渲染(Client-Side Rendering)

交互性：强（速度快）
首次加载：慢
SEO：差
服务器负载：低

服务端渲染(Server-Side Rendering)

交互性：较低（速度慢）
首次加载：快
SEO：好
服务器负载：高

为什么说SSR有助于SEO？

流程：爬虫引擎->网页内容，搜索引擎通过爬虫获取网页内容，并展示到搜索页上

原理：SSR提高了搜索引擎爬取网页的效率，具体来说，搜索引擎不需要执行JS即可获取全部内容

减少搜索引擎计算时间，
减少搜索引擎的计算成本

基于以上两个优点，使得搜索引擎能更快地获取最新的网站内容，这也是SSR重要的优势

搜索引擎在初次抓取时只能看到一个空的 `div` 元素，需要执行 JavaScript 才能获取到实际内容。
而在 SSR 中，爬虫直接看到完整的内容，并且能够立即进行索引。

客户端渲染 (CSR)
    <!DOCTYPE html>
    <html>
    <head>
      <title>Blog</title>
    </head>
    <body>
      <div id="root"></div>
      <script src="bundle.js"></script>
      <script>
        // JavaScript 代码从服务器获取内容并插入到 DOM 中
        fetch('/api/blog')
          .then(response => response.json())
          .then(data => {
            document.getElementById('root').innerHTML = `
              <h1>${data.title}</h1>
              <p>${data.content}</p>
            `;
          });
      </script>
    </body>
    </html>

服务器端渲染 (SSR)
    <!DOCTYPE html>
    <html>
    <head>
      <title>Blog</title>
    </head>
    <body>
      <div id="root">
        <h1>My Blog Title</h1>
        <p>Here is the blog content...</p>
      </div>
    </body>
    </html>

为什么SSR的交互性不如CSR？

SSR下，交互的计算委托给服务器执行，使用的是服务器的算力，使得每次交互都需要与浏览器通信，相当于一个人每次想做点什么都要和别人说一声，别人消耗精力，自己也得等着回应

CSR下，交互的计算在本地执行，使用的是本地计算机的算力

图片懒加载

图片懒加载实现原理？

将图片的地址放在data-set属性中，由于图片并没有在src中，并不会发送http请求。
比较图片到整个页面距离（Y）和  页面滑动的距离 （X） +  浏览器可视区域的大小(Z)
Y小于两者之和，则图片就显示出来，将图片的data-set属性换为src属性

MVC、MVVM、AOP 和 IOC 的原理 ​

脚手架 ​

SSR权限加载流程 ​

Excel多sheet前端解析 ​

文件上传与下载 ​

breadcrumb动态去重历史记录 ​

后台侧边栏 ​

全局错误提示 ​

性能优化 ​

页面性能指标 ​

CSR与SSR ​

图片懒加载 ​