2023.04.11 更新前端面试问题总结（11道题）

目录：

一般来说，如果不清楚什么时候用interface/type，能用 interface 实现，就用 interface , 如果不能就用 type 。

在js中new关键字主要做了：首先创建一个空对象，这个对象会作为执行new构造函数之后返回的对象实例，将创建的空对象原型（__proto__）指向构造函数的prototype属性，同时将这个空对象赋值给构造函数内部的this，并执行构造函数逻辑，根据构造函数的执行逻辑，返回初始创建的对象或构造函数的显式返回值。

枚举和常量枚举（const枚举）：使用枚举可以清晰地表达意图或创建一组有区别的用例

区别：

由此可见，使用 常量枚举 会有更好的性能。

定义的枚举，在经过编译器编译后是一个对象，这个对象我们可以在程序运行时使用，前面有说到。但有时定义枚举可能只是为了让程序可读性更好，而不需要编译后的代码，即不需要编译成对象。typescript中考虑到这种情况，所以加入了 const enum (完全嵌入的枚举)。

TypeScript 中不可变量的实现方法有两种：

使用 ES6 的 const 关键字声明的值类型 被 readonly 修饰的属性 2、TypeScript 中 readonly：

TypeScript 中的只读修饰符，可以声明更加严谨的可读属性。通常在 interface 、 Class 、 type 以及 array 和 tuple 类型中使用它，也可以用来定义一个函数的参数。

3、两者区别：

（1）const 用于变量， readonly 用于属性

（2）const 在运行时检查， readonly 在编译时检查

（3）const 声明的变量不得改变值，这意味着，const 一旦声明变量，就必须立即初始化，不能留到以后赋值；readonly 修饰的属性能确保自身不能修改属性，但是当你把这个属性交给其它并没有这种保证的使用者（允许出于类型兼容性的原因），他们能改变。

（4）const 保证的不是变量的值不得改动，而是变量指向的那个内存地址不得改动，例如使用 const 变量保存的数组，可以使用 push ， pop 等方法。 但是如果使用 ReadonlyArray 声明的数组不能使用 push ， pop 等方法。

计算属性computed :

侦听属性watch：

1.watch它是一个对data的数据监听回调, 当依赖的data的数据变化时, 会执行回调。在回调中会传入newVal和oldVal两个参数。Vue实列将会在实例化时调用$watch(), 他会遍历watch对象的每一个属性。watch的使用场景是：当在data中的某个数据发生变化时, 我们需要做一些操作, 或者当需要在数据变化时执行异步或开销较大的操作时. 我们就可以使用watch来进行监听。watch普通监听和深度监听不支持缓存，数据变，直接会触发相应的操作；

2.watch里面有一个属性为deep，含义是：是否深度监听某个对象的值, 该值默认为false。watch支持异步；

3.监听的函数接收两个参数，第一个参数是最新的值；第二个参数是输入之前的值；

4.当一个属性发生变化时，需要执行对应的操作；一对多；

5.监听数据必须是data中声明过或者父组件传递过来的props中的数据，当数据变化时，触发其他操作，函数有两个参数，

watch 和 computed的区别是：

相同点：他们两者都是观察页面数据变化的。

不同点：computed只有当依赖的数据变化时才会计算, 当数据没有变化时, 它会读取缓存数据。 watch每次都需要执行函数。watch更适用于数据变化时的异步操作。

当需要在数据变化时执行异步或开销较大的操作时，这个方式是最有用的。这是和computed最大的区别，请勿滥用。

vue 并没有在源码中做代理， 至少是 2.x 是没有做事件代理的。但是理论上来说使用事件代理性能会更好一点。

阅读 vue 源码的过程中，并没有发现 vue 会自动做事件代理，但是一般给 v-for 绑定事件时，都会让节点指向同一个事件处理程序（第二种情况可以运行，但是 eslint 会警告），一定程度上比每生成一个节点都绑定一个不同的事件处理程序性能好，但是监听器的数量仍不会变，所以使用事件代理会更好一点。

react 是委托到 document 上, 然后自己生成了合成事件, 冒泡到 document 的时候进入合成事件, 然后他通过 getParent() 获取该事件源的所有合成事件, 触发完毕之后继续冒泡。但是一些特殊的比如focus这种必须放在input这些dom上。

说一下我个人理解，先说结论，可以使用

事件代理作用主要是 2 个

这里我生成了十万个 span 节点，通过 performance monitor 来监控内存占用率和事件监听器的数量，对比以下 3 种情况

可以通过 chrome devtools performance monitor 查看内存使用情况

可以看到使用事件代理无论是监听器数量和内存占用率都比前两者要少

首先我们需要知道事件代理主要有什么作用？

从vue的角度上来看上面两点

在使用Vue、React等前端框架时，我们都会发现项目中只有一个HTML文件，并且在该HTML中都存在一个根标签，起到了类似于容器的作用。容器内部的内容就由我们后续编写的每个视图决定，页面的切换就是容器中视图的切换。

前端路由的实现原理简单来说，就是在不跳转或者刷新页面的前提下，为SPA应用中的每个视图匹配一个特殊的URL，之后的刷新、前进、后退等操作均通过这个特殊的URL实现。为实现上述要求，需要满足：

改变URL且不会向服务器发起请求；

可以监听到URL的变化，并渲染与之匹配的视图。

主要有Hash路由和History路由两种实现方式。下文对两者的基本原理进行简单介绍，并分别实现了一个简易的路由Demo。

原理就是通过键值对的形式保存路由及对应要执行的回调函数，当监听到页面hash发生改变时，根据最新的hash值调用注册好的回调函数，即改变页面。

使用route方法添加对应的路由及其回调函数即可。以下代码实现了一个根据不同hash改变页面颜色的路由，模拟了页面的切换，在实际的SPA应用中，对应的就是页面内容的变化了。

在H5之前，浏览器的history仅支持页面之前的跳转，包括前进和后退等功能。

在HTML5中，新增以下API：

history.pushState()和history.replaceState()均接收三个参数：

由于history.pushState()和 history.replaceState()都具有在改变页面URL的同时，不刷新页面的能力，因此也可以用来实现前端路由。

在使用hash实现的路由中，我们通过hashchange事件来监听hash的变化，但是上述代码中history的改变本身不会触发任何事件，因此无法直接监听history的改变来改变页面。因此，对于不同的情况，我们选择不同的解决方案：

基于hash的路由：

缺点：

优点：

推荐阅读文档： https://juejin.cn/post/6844904122479542285

Vue3 不同于 Vue2 也体现在源码结构上，Vue3 把耦合性比较低的包分散在 packages 目录下单独发布成 npm 包。 这也是目前很流行的一种大型项目管理方式 Monorepo。

其中负责响应式部分的仓库就是 @vue/reactivity，它不涉及 Vue 的其他的任何部分，是非常非常 「正交」 的一种实现方式。

甚至可以轻松的集成进 React https://juejin.cn/post/6844904095594381325

Proxy 和 Object.defineProperty 的使用方法看似很相似，其实 Proxy 是在 「更高维度」 上去拦截属性的修改的，怎么理解呢？

Vue2 中，对于给定的 data，如 { count: 1 }，是需要根据具体的 key 也就是 count，去对「修改 data.count 」 和 「读取 data.count」进行拦截，也就是

必须预先知道要拦截的 key 是什么，这也就是为什么 Vue2 里对于对象上的新增属性无能为力。

而 Vue3 所使用的 Proxy，则是这样拦截的：

可以看到，根本不需要关心具体的 key，它去拦截的是 「修改 data 上的任意 key」 和 「读取 data 上的任意 key」。

所以，不管是已有的 key 还是新增的 key，都逃不过它的魔爪。

但是 Proxy 更加强大的地方还在于 Proxy 除了 get 和 set，还可以拦截更多的操作符。

先写一个 Vue3 响应式的最小案例，本文的相关案例都只会用 reactive 和 effect 这两个 api。如果你了解过 React 中的 useEffect，相信你会对这个概念秒懂，Vue3 的 effect 不过就是去掉了手动声明依赖的「进化版」的 useEffect。

React 中手动声明 [data.count] 这个依赖的步骤被 Vue3 内部直接做掉了，在 effect 函数内部读取到 data.count 的时候，它就已经被收集作为依赖了。

Vue3：

React：

也可以把 effect 中的回调函数联想到视图的重新渲染、 watch 的回调函数等等…… 它们是同样基于这套响应式机制的。

而本文的核心目的，就是探究这个基于 Proxy 的 reactive api，到底能强大到什么程度，能监听到用户对于什么程度的修改。

先最小化的讲解一下响应式的原理，其实就是在 Proxy 第二个参数 handler 也就是陷阱操作符中，拦截各种取值、赋值操作，依托 track 和 trigger 两个函数进行依赖收集和派发更新。

track 用来在读取时收集依赖。

trigger 用来在更新时触发依赖。

target 是原对象。

type 是本次收集的类型，也就是收集依赖的时候用来标识是什么类型的操作，比如上文依赖中的类型就是 get，这个后续会详细讲解。

key 是指本次访问的是数据中的哪个 key，比如上文例子中收集依赖的 key 就是 count

首先全局会存在一个 targetMap，它用来建立 数据 -> 依赖 的映射，它是一个 WeakMap 数据结构。

而 targetMap 通过数据 target，可以获取到 depsMap，它用来存放这个数据对应的所有响应式依赖。

depsMap 的每一项则是一个 Set 数据结构，而这个 Set 就存放着对应 key 的更新函数。

是不是有点绕？我们用一个具体的例子来举例吧。

对于这个例子的依赖关系，

这样一层层的下去，就可以通过 target 找到 count 对应的更新函数 effection 了。

这里是最小化的实现，仅仅为了便于理解原理，实际上要复杂很多，

其实 type 的作用很关键，先记住，后面会详细讲。

如果太大的文件，比如一个视频1g 2g那么大，直接采用上面的栗子中的方法上传可能会出链接现超时的情况，而且也会超过服务端允许上传文件的大小限制，所以解决这个问题我们可以将文件进行分片上传，每次只上传很小的一部分 比如2M。

Blob 它表示原始数据, 也就是二进制数据，同时提供了对数据截取的方法 slice,而 File 继承了 Blob 的功能，所以可以直接使用此方法对数据进行分段截图。

过程如下：

客户端 JS 代码实现如下

服务端 node 实现代码如下： 合并文件这里使用 stream pipe 实现，这样更节省内存，边读边写入，占用内存更小，效率更高，代码见fnMergeFile方法。

在上面我们实现了文件分片上传和最终的合并，现在要做的就是如何检测这些分片，不再重新上传即可。 这里我们可以在本地进行保存已上传成功的分片，重新上传的时候使用spark-md5来生成文件 hash，区分此文件是否已上传。

方案一： 保存在本地 indexDB/localStorage 等地方， 推荐使用 localForage 这个库npm install localforage

客户端 JS 代码：

方案2：服务端用于保存分片坐标信息， 返回给前端

需要服务端添加一个接口只是服务端需要增加一个接口。 基于上面一个栗子进行改进，服务端已保存了部分片段，客户端上传前需要从服务端获取已上传的分片信息（上面是保存在了本地浏览器），本地对比每个分片的 hash 值，跳过已上传的部分，只传未上传的分片。

方法1是从本地获取分片信息,这里只需要将此方法的能力改为从服务端获取分片信息就行了。

具体流程可以看下面这个图：

要了解小程序架构原理， 要从以下几个方面入手探索

具体内容可以参考文档:

vue3 的响应式库是独立出来的，它可以很方便的集成进 React， 作为 React 的状态管理库使用！

定义 store

消费使用

可以看出，store的定义只用到了@vue/reactivity，而rxv只是在组件中做了一层桥接，连通了Vue3和React，正如它名字的含义：React x Vue。

只要effect能接入到React系统中，那么其他的api都没什么问题，因为它们只是去收集effect的依赖，去通知effect触发更新。

effect接受的是一个函数，而且effect还支持通过传入schedule参数来自定义依赖更新的时候需要触发什么函数，

而rxv的核心api: useStore接受的也是一个函数selector，它会让用户自己选择在组件中需要访问的数据。

把selector包装在effect中执行，去收集依赖。

指定依赖发生更新时，需要调用的函数是当前正在使用useStore的这个组件的forceUpdate强制渲染函数。

简单的看一下核心实现

share.ts

核心逻辑在此

参考文档：