高级web前端面试题

1.js为什么要延迟加载，有哪些方法可以实现延迟加载

原因：js 的加载、解析和执行会阻塞页面的渲染过程，因此我们希望 js 脚本能够尽可能的延迟加载，提高页面的渲染速度。

我了解到的几种方式是:

• 将 js 脚本放在文档的底部，来使 js 脚本尽可能的在最后来加载执行。
• 给 js 脚本添加 defer属性，这个属性会让脚本的加载与文档的解析同步解析，然后在文档解析完成
  后再执行这个脚本文件，这样的话就能使页面的渲染不被阻塞。多个设置了 defer 属性的脚本按规
  范来说最后是顺序执行的，但是在一些浏览器中可能不是这样。
• 给 js 脚本添加 async属性，这个属性会使脚本异步加载，不会阻塞页面的解析过程，但是当脚本
  加载完成后立即执行 js脚本，这个时候如果文档没有解析完成的话同样会阻塞。多个 async 属性
  的脚本的执行顺序是不可预测的，一般不会按照代码的顺序依次执行。
• 动态创建 DOM 标签的方式，我们可以对文档的加载事件进行监听，当文档加载完成后再动态的创
  建 script 标签来引入 js 脚本。

2.MVVM框架设计理念

Model–View–ViewModel (MVVM) 是一个软件架构设计模式，由微软 WPF 和 Silverlight 的架构师 Ken Cooper 和 Ted Peters 开发，是一种简化用户界面的事件驱动编程方式。由 John Gossman(同样 也是 WPF 和 Silverlight 的架构师)于2005年在他的博客上发表

MVVM 源自于经典的 Model–View–Controller(MVC)模式 ，MVVM 的出现促进了前端开发与后端业 务逻辑的分离，极大地提高了前端开发效率，MVVM 的核心是 ViewModel 层，它就像是一个中转站 (value converter)，负责转换 Model 中的数据对象来让数据变得更容易管理和使用，该层向上与视 图层进行双向数据绑定，向下与 Model 层通过接口请求进行数据交互，起呈上启下作用。

(1)View 层

View 是视图层，也就是用户界面。前端主要由 HTML 和 CSS 来构建 。

(2)Model 层

window.history.pushState(null, null, path); window.history.replaceState(null, null, path); 复制代码

Model 是指数据模型，泛指后端进行的各种业务逻辑处理和数据操控，对于前端来说就是后端提供的 api 接口。

(3)ViewModel 层

ViewModel 是由前端开发人员组织生成和维护的视图数据层。在这一层，前端开发者对从后端获取的 Model 数据进行转换处理，做二次封装，以生成符合 View 层使用预期的视图数据模型。需要注意的是 ViewModel 所封装出来的数据模型包括视图的状态和行为两部分，而 Model 层的数据模型是只包含状 态的，比如页面的这一块展示什么，而页面加载进来时发生什么，点击这一块发生什么，这一块滚动时 发生什么这些都属于视图行为(交互)，视图状态和行为都封装在了 ViewModel 里。这样的封装使得 ViewModel 可以完整地去描述 View 层。

MVVM 框架实现了双向绑定，这样 ViewModel 的内容会实时展现在 View 层，前端开发者再也不必低 效又麻烦地通过操纵 DOM 去更新视图，MVVM 框架已经把最脏最累的一块做好了，我们开发者只需要 处理和维护 ViewModel，更新数据视图就会自动得到相应更新。这样 View 层展现的不是 Model 层的 数据，而是 ViewModel 的数据，由 ViewModel 负责与 Model 层交互，这就完全解耦了 View 层和 Model 层，这个解耦是至关重要的，它是前后端分离方案实施的重要一环。

3.vue中使用过ssr吗？说说ssr

Vue.js 是构建客户端应用程序的框架。默认情况下，可以在浏览器中输出 Vue 组件，进行生成 DOM 和操作 DOM。然而，也可以将同一个组件渲染为服务端的 HTML 字符串，将它们直接发送 到浏览器，最后将这些静态标记"激活"为客户端上完全可交互的应用程序。

服务端渲染 SSR 的优缺点如下:

(1)服务端渲染的优点:
更好的 SEO: 因为 SPA 页面的内容是通过 Ajax 获取，而搜索引擎爬取工具并不会等待 Ajax 异步 完成后再抓取页面内容，所以在 SPA 中是抓取不到页面通过 Ajax 获取到的内容;而 SSR 是直接由 服务端返回已经渲染好的页面(数据已经包含在页面中)，所以搜索引擎爬取工具可以抓取渲染好 的页面;
更快的内容到达时间(首屏加载更快): SPA 会等待所有 Vue 编译后的 js 文件都下载完成后，才 开始进行页面的渲染，文件下载等需要一定的时间等，所以首屏渲染需要一定的时间;SSR 直接由 服务端渲染好页面直接返回显示，无需等待下载 js 文件及再去渲染等，所以 SSR 有更快的内容到 达时间;
(2) 服务端渲染的缺点:
更多的开发条件限制: 例如服务端渲染只支持 beforCreate 和 created 两个钩子函数，这会导致 一些外部扩展库需要特殊处理，才能在服务端渲染应用程序中运行;并且与可以部署在任何静态文 件服务器上的完全静态单页面应用程序 SPA 不同，服务端渲染应用程序，需要处于 Node.js server 运行环境;
更多的服务器负载:在 Node.js 中渲染完整的应用程序，显然会比仅仅提供静态文件的 server 更加大量占用CPU 资源 (CPU-intensive - CPU 密集)，因此如果你预料在高流量环境 ( high traffic ) 下使用，请准备相应的服务器负载，并明智地采用缓存策略。

4.对于即将到来的vue3.0特性你有什么了解的吗

Vue 3.0 正走在发布的路上，Vue 3.0 的目标是让 Vue 核心变得更小、更快、更强大，因此 Vue 3.0 增加以下这些新特性:

(1)监测机制的改变
3.0 将带来基于代理 Proxy 的 observer 实现，提供全语言覆盖的反应性跟踪。这消除了 Vue 2 当中基 于 Object.defineProperty 的实现所存在的很多限制:

function createKeyToOldIdx (children, beginIdx, endIdx) {
  let i, key
  const map = {}
  for (i = beginIdx; i <= endIdx; ++i) {
key = children[i].key
    if (isDef(key)) map[key] = i
  }
return map }

• 只能监测属性，不能监测对象
• 检测属性的添加和删除;
• 检测数组索引和长度的变更;
• 支持 Map、Set、WeakMap 和 WeakSet。

新的 observer 还提供了以下特性:

• 用于创建 observable 的公开 API。这为中小规模场景提供了简单轻量级的跨组件状态管理解决方 案。
• 默认采用惰性观察。在 2.x 中，不管反应式数据有多大，都会在启动时被观察到。如果你的数据集 很大，这可能会在应用启动时带来明显的开销。在 3.x 中，只观察用于渲染应用程序最初可见部分 的数据。
• 更精确的变更通知。在 2.x 中，通过 Vue.set 强制添加新属性将导致依赖于该对象的 watcher 收 到变更通知。在 3.x 中，只有依赖于特定属性的 watcher 才会收到通知。
• 不可变的 observable:我们可以创建值的“不可变”版本(即使是嵌套属性)，除非系统在内部暂 时将其“解禁”。这个机制可用于冻结 prop 传递或 Vuex 状态树以外的变化。
• 更好的调试功能:我们可以使用新的 renderTracked 和 renderTriggered 钩子精确地跟踪组件在 什么时候以及为什么重新渲染。

(2)模板
模板方面没有大的变更，只改了作用域插槽，2.x 的机制导致作用域插槽变了，父组件会重新渲染，而
3.0 把作用域插槽改成了函数的方式，这样只会影响子组件的重新渲染，提升了渲染的性能。 同时，对于 render 函数的方面，vue3.0 也会进行一系列更改来方便习惯直接使用 api 来生成 vdom 。
(3)对象式的组件声明方式
vue2.x 中的组件是通过声明的方式传入一系列 option，和 TypeScript 的结合需要通过一些装饰器的方 式来做，虽然能实现功能，但是比较麻烦。3.0 修改了组件的声明方式，改成了类式的写法，这样使得 和 TypeScript 的结合变得很容易。
此外，vue 的源码也改用了 TypeScript 来写。其实当代码的功能复杂之后，必须有一个静态类型系统 来做一些辅助管理。现在 vue3.0 也全面改用 TypeScript 来重写了，更是使得对外暴露的 api 更容易结 合 TypeScript。静态类型系统对于复杂代码的维护确实很有必要。
(4)其它方面的更改
vue3.0 的改变是全面的，上面只涉及到主要的 3 个方面，还有一些其他的更改:

• 支持自定义渲染器，从而使得 weex 可以通过自定义渲染器的方式来扩展，而不是直接 fork 源码 来改的方式。
• 支持 Fragment(多个根节点)和 Protal(在 dom 其他部分渲染组建内容)组件，针对一些特殊 的场景做了处理。
• 基于 treeshaking 优化，提供了更多的内置功能。

5.redux遵循的三个原则是什么

1. 单一事实来源

整个应用的状态存储在单个 store 中的对象/状态树里。单一状态树可以更容易地 跟踪随时间的变化，并调试或检查应用程序。

2. 状态是只读的

改变状态的唯一方法是去触发一个动作。动作是描述变化的普通 JS 对象。就像 state 是数据的最小表示一样，该操作是对数据更改的最小表示。

3. 使用纯函数进行改变

为了指定状态树如何通过操作进行转换，你需要纯函数。纯函数是那些返回 值仅取决于其参数值的函数。

6.如果线上出现bug git怎么操作

方法1:在当前主分支修改bug，暂存当前的改动的代码，目的是让工作空间和远程代码一致：

• Git stash

修改完bug后提交修改：

• git add.
• git commit --m “fix bug 1”
• git push

从暂存区把之前的修改恢复，这样就和之前改动一样了

• git stash pop

这时可能会出现冲突，因为你之前修改的文件，可能和bug是同一个文件，如果有冲突会提示：

Auto–merging xxx.Java
conflice（content):Merge conflict in xxx.java
前往xxx.java解决冲突
注意stash pop意思是从暂存区恢复到工作空间，同时删除此条暂存记录

方法2:拉一个新分支，老司机都推荐这样做，充分利用了git特性，先暂存一下工作空间改动：

git stash
新建一个分支，并切换到这个新分支
git branch fix-bug//新建分支
git checkbox fix-bug//切换分支
这时候就可以安心在这个分之下修改bug了，改完之后：
git add.
git commit --m “fix a bug”
切换到master主分支
git checkout master
从fix-bug合并到master分支
git merge fix-bug
提交代码
git push
然后从暂存区恢复代码
git stash pop
此时有冲突需要解决冲突