• 现实：创造一个世界
• 成长：生物具有成长特性
  • 达尔文进化论：
  • 成长速度快，但是不能丢失细节：

背景：老板让我优化一个用户搜索接口，要求是用户搜索请假交接人时优先展示同部门的用户其次是上级和下级部门的用户最后是其他部门的用户。

二、优化方案

1. 数据库查询优化。目前的公司内部的平台都是比较通用的查询，一些没有用的字段，也查询了。这里我去找前端沟通确定他们那边需要用到哪些字段，开发一个专用接口去进行操作。
2. 借鉴Elasticsearch的IndexSorting技术，优化搜索性能。
3. 并行调用与异步处理
   • 使用CompletableFuture实现并行调用，提高接口响应速度。 示例代码：

• godot docs ：godot文档
• learn-gdscript：快速入门 gdscript
• # godot 4.x 教程 100集 ：B站视频教程，本人之后打算学习
• # 2025年，独立游戏开发者必备的16款软件！：秦无邪OvO老师，本人大学期间学习过他的Unity教程，这个视频课主要介绍他使用的游戏开发工具

Godot 常用快捷键

原则

• 节点通信时的经验法则
  • 父子节点：Call down ，signal up 往下用调用，往上用信号
    • 父节点应该调用子节点的函数，反之则不然
    • 子节点应该用信号给父节点

Godot Shader

第一个GDShader-摇晃Shader

• gdshader
• 在需要让树摇晃的时候，通过脚本动态设置uniform参数 shake_intensity material.set_shader_parameter("shake_intensity", 1.0)
• 短暂等待后await get_tree().create_timer(1.0).timeout
• 让树停止摇晃，material.set_shader_parameter("shake_intensity", 0.0)

方案一：社区平台、方案四：微信公众号以及其他各类公众号这里不多介绍，上手较为简单，主要是输出好的文章和运营自己的账号；方案三只做简单介绍，因为本人也用的较少

这里主要介绍方案二：

二、方案二：Github Pages/Vercel + Hexo/Vuepress

1. 准备环境

• Nodejs（推荐一手NVM）
• Git

2. 找喜欢的主题

3. 初始化项目并上传Github

这里以vuepress-theme-hope 主题为例，也推荐大家使用。官方文档快速上手和线上Demo

一个基本的项目结构如下:

4. 部署 Deploy

官方有介绍如何部署到Github Pages- Deploy Github Pages

我这里补充如何部署到Vercel

4.1. 如何部署到Vercel

• 登录Vercelhttps://vercel.com/，Github授权
• Vercel添加项目

![[Pasted image 20250228155556.png]]

• 选择自己的博客存储库，点击import

![[Pasted image 20250228155627.png]]

• 点击部署Deploy等待即可

![[Pasted image 20250228155636.png]]

• 部署好后会有一个默认的域名，如果需要自定义域名可以去购买一个域名然后解析即可（.top的域名我之前购买是3年/27）

![[Pasted image 20250228155657.png]]

5. 成果

https://v-blog.yyshino.top/

![[Pasted image 20250228155715.png]] ![[Pasted image 20250228155722.png]] ![[Pasted image 20250228155729.png]] ![[Pasted image 20250228155737.png]]

三、方案三 云服务器 + Wordpress

我之前是通过

WordPress教程，0基础学会WordPress建站（2024/7月更新） – 奶爸建站笔记

四、参考文章

• 2021最全hexo搭建博客+matery美化+使用（保姆级教程）

• hexo（matery）背景、滚动条优化+增加点击跳评论_首页+色-CSDN博客

• GitHub Pages 文档 - GitHub 文档

Spring 使用两种代理机制来管理事务：

• JDK 动态代理：针对实现了接口的类，Spring 会创建一个实现了相同接口的代理类。事务逻辑通过代理类在方法调用时插入。
• CGLIB 代理：针对没有实现接口的类，Spring 会使用 CGLIB 生成子类代理，拦截方法调用并插入事务逻辑。

不论哪种代理方式，Spring 都是在代理类中对事务进行管理。如果调用来自外部的类，代理对象会拦截该调用并正确地管理事务逻辑。

2. Spring 事务失效场景

2.1. 同类中的方法调用导致事务失效

不生效原因：这是因为内部方法调用不会通过 Spring 生成的代理类进行调用，而是直接在当前对象中执行，因此 Spring 无法介入处理事务。

• 内部调用：当类内部的方法调用另一个带有 @Transactional 注解的方法时，这个调用不会通过 Spring 的代理对象进行，而是直接通过 this 引用，因此 Spring 无法拦截并应用事务。
• 代理对象失效：Spring AOP 代理机制只能拦截通过代理对象进行的方法调用，而不能拦截类内部的直接方法调用。

2.1.1. 解决同类中事务失效的问题

方法 1：通过Spirng容器重新获取代理对象

方法 2：将事务性方法抽离到另一个类

....

方法 3：使用 事务模版 （推荐）

1. 删除事务注解 @Transactional
2. 使用事务模版将需要事务管理的部分包裹起来

作者：lgd8981289

搬运自 https://github.com/lgd8981289/vue-next-mini

简介

那么在上一小节中我们已经知道了如何对vue的源代码进行debugger ,但是如果想要学习或者了解 vue的代码执行，那么光靠 debugger是不够的,除此之外我们还需要掌握另外一个能力,那么如何阅读源代码

阅读源代码的误区

很多同学在去阅读源代码的时候,都会面临一个误区,那就是：我需要把源代码中每一行代码都读明

这是一个非常不对的行为，很容易让我们 事倍功半

所以在这里我们需要先给大家明确一点：阅读源码绝对不是要读明白其中每一行代码的意思，而是在众多的业务代码中寻找到主线，跟随这个主线来进行阅读

阅读源码的正确姿势

想要快速、轻松的阅读源码,正确的姿势非常重要,主要有两点:

1. 摒弃边缘情况
2. 跟随一条主线

摒弃边缘情况

在大型项目的源码中，都会充斥着非常多的业务代码，这些业务代码是用来处理很多 边缘情况 的，如果我们过分深究这些业务代码则会让我们陷入到一个 代码泥潭 中，在繁琐的业务中找不到方向。

所以，我们在阅读源码之前，必须要明确好一点，那就是：仅阅读核心逻辑

跟随一条主线

对于像vue这种量级的项目来说,哪怕我们只去阅读它的核心代码,你也会发现也是非常困难的。

我们之前说过, vue的核心大致可以分为三块:

1. 响应性
2. 运行时
3. 编译器

每一大块的内部又分为了很多的业务分支。所以哪怕仅阅读核心代码已然是一个浩大的工作量。

所以说我们还需要另外一个方式，那就是：跟随一条主线

总结

总结这一小节我们讲解了如何阅读源代码，以上方式不知可以应用到 vue 中，也可以应用到其他的框架之中，所以我们把这一小节叫做 授人以渔。

当然，我们这里只是通过一个简单的方式来进行了举例，在大家实际阅读的过程之中，肯定还是会遇到很多的困难的，不过好在，在这个过程中，我们会一起来进行阅读~~

原理

Proxy与Object.defineProperty

1. Proxy
   1. Proxy 将代理一个对象（被代理对象），得到一个新的对象（代理对象），同时拥有被代理对象中所有的属性。
   2. 当想要修改对象的指定属性时,我们应该使用代理对象进行修改
   3. 代理对象 的任何一个属性都可以触发 handler 的 getter 和 setter
2. Object.defineProperty
   1. Object.defineProperty 为指定对象的指定属性设置属性描述符
   2. 当想要修改对象的指定属性时，可以使用原对象进行修改
   3. 通过属性描述符，只有 被监听 的指定属性，才可以触发 getter 和 setter

所以当 vue3 通过 Proxy 实现响应性核心 API 之后，vue 将 不会 再存在新增属性时失去响应性的问题。

Reflect

https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/Reflect

Reflect+Proxy

当我们期望监听代理对象的 getter 和 setter 时,不应该使用 target[key] ,因为它在某些时刻（比如 fullName）下是不可靠的。而 应该使用 Reflect ，借助它的 get 和 set 方法，使用receiver （proxy 实例） 作为 this，已达到期望的结果（触发三次 getter）

最后如果我们想要“安全”的使用Proxy,还需要配合Reflect一起才可以,因为一旦我们在被代理对象的内部，通过 this 触发 getter 和 setter 时，也需要被监听到。

Reactive的响应式 源码实现

核心

1. 创建 proxy
2. 收集 effect 的依赖
3. 触发收集的依赖

reactive方法

1. 触发 reactive 方法

2. 创建reactive对象: return createReactiveObject

3. 进入 new Proxy

   1. 第一个参数 target：为传入的对象
   2. 第二个参数 handler: TargetType.COLLECTION = 2， targetType = 1， 所以 handler为 baseHandlers
   3. 那这个 baseHandlers 是什么呢？

4. 在 reactive 方法中可知， baseHandlers 是触发 createReactiveObject 传递的第三个参数: mutableHandlers

5. 而 mutableHandlers 则是 packages/reactivity/src/baseHandlers.ts 中导出的对象

6. 所以我们到 packages/reactivity/src/baseHandlers.ts 中，为它的 get (createGetter)和 set (createSetter) 分别打入一个断点

7. 我们知道 get 和 set 会在 取值 和 赋值 时触发，所以此时这两个断点 不会执行

8. 最后 reactive方法内执行了 proxyMap.set(target, proxy)方法

9. 最后返回了代理对象。

10. 那么至此 reactive 方法执行完成。

由以上执行逻辑可知，对于 reactive 方法而言，其实做的事情非常简单：

1. 创建了 proxy
2. 把 proxy 加到了 proxyMap 里面
3. 最后返回了 proxy

effect

1. 在 packages/reactivity/src/effect.ts 第 170 行可以找到 effect 方法，在这里给一个断点
2. 执行 new ReactiveEffect(fn)，其中的 fn 就是我们传入的匿名函数：
   1. 这里涉及到了一个类 ReactiveEffect
   2. 查看该类可知，内部实现了两个方法：
      1. run
      2. stop
   3. 我们分别为这两个方法 增加断点
3. 代码继续进行
4. 可以发现执行了 run 方法，进入方法内部：
   1. 执行 activeEffect = this，赋值完成之后, activeEffect为传入的匿名函数fn
   2. 然后执行 return this.fn（） 触发 fn 函数
   3. 我们知道 fn 函数其实就是 传入的匿名函数，所以document.querySelector('#app').innerText = obj.name
5. 但是大家不要忘记，obj 是一个 proxy，obj.name会 触发 getter，所以接下来我们就会进入到 mutableHandlers 的 createGetter 中
   1. 在该代码中,触发了该方法 const res = Reflect.get(target, key, receiver)
   2. 此时的 res 即为 张三
   3. 注意：接下来触发了 track 函数，该函数是一个重点函数，track 在此为 跟踪 的意思，我们来看它内部都做了什么：
      1. 在 4-1 步中，为 activeEffect 进行了赋值，我们知道 activeEffect 代表的就是fn 函数
      2. 执行代码可知，rack 内部主要做了两件事情：
         1. 为 targetMap 进行赋值，targetMap 的组成比较复杂：
            1. key; target
            2. value: Map
               1. key: key
               2. value: Set
         2. 最后执行了 trackEffects(dep, eventInfo)1,其中eventInfo是一个对象,内部包含四个属性:其中 effect即为activeEffect 即 fn 函数
         3. 在 trackEffects 函数内部，核心也是做了两件事情：
            1. 为dep (targetMap[target][key]得到的Set实例) 添加了activeEffect函数
            2. 为activeEffect函数的静态属性deps，增加了一个值dep
            3. 即：建立起了dep和activeEffect的联系
   4. 那么至此，整个 track 的核心逻辑执行完成
   5. 我们可以把整个 track 的核心逻辑说成：收集了 activeEffect（即： fn)
6. 最后在 createGetter 函数中返回了 res （即：张三)
7. 至此，整个 effect 执行完成

由以上逻辑可知，整个 effect 主要做了3 件事情：

1. 生成ReactiveEffect实例
2. 触发fn方法，从而激活getter
3. 简历了targetMap和activeEffect之间的联系
   1. dep.add(activeEffect)
   2. activeEffect.deps.push(dep)

那么至此:页面中即可展示 obj.name ,但是不要忘记,等待两秒之后,我们会修改 obj.name 的值,我们知道,这样会触发 setter ,那么我们接下来来看 setter中又做了什么呢?

1. 两秒之后触发 setter ,会进入到 packages/reactivity/src/baseHandlers.ts 中的的createSetter 方法中
2. 创建变量: oldValue =张三
3. 创建变量: value=李四、
4. 执行 const result = Reflect,set(target, key, value, receiver），即： 修改了 obj 的值为“李四”I
5. 触发: trigger(target, TriggerOpTypes.SET, key, value, oldvalue),此时各参数的值为：
6. trigger 在这里为 触发 的意思，那么我们来看 trigger 内部做了什么?
   1. 首先执行： const depsMap = targetMap.get(target），其中 targetMap 即我们在track 函数中，保存 activeEffect 的 targetMap
   2. 然后代码执行到: deps.push(depsMap.get(key))。 depsMap.get(key)获取到的即为之前保存的 activeEffect，即 fn 函数
   3. 然后触发 triggerEffects(deps[0]，eventInfo)，我们来看 triggerEffects 中做了什么：
      1. 声明常量： const effects = isAray(dep) ? dep : [...dep]，此时的 effects 保存的为 fn 的集合
      2. 遍历 effects，执行：triggerEffect(effect， debuggerEventExtraInfo) 方法，那么我们来看 triggerEffect 做了什么
         1. 执行 effect.run(）方法，已知： effect 是一个ReactiveEffect 类型的对象，则run 方法会触发 ReactiveEffect 的 run ,那么我们接下来来看 这一次 进入run 方法时，内部做了什么？
            1. 首先还是为activeEffect = this赋值,但是要注意:此时的this不再是一个 fn，而是一个复杂对象：
            2. 最后执行this.fn() 即：effect时传入的匿名函数
            3. 至此，fn执行，意味着：document.querySelector('#app').innerText = 李四，页面将发生变化
      3. triggerEffects 完成
   4. triggerEffects 完成
7. trigger 完成
8. setter回调完成

由以上逻辑可知，整个setter主要做了2件事情：

1. 修改obj的值
2. 触发targetMap下保存的fn函数

Ref 复杂数据类型的响应性

1. 对于ref函数,会返回RefImpl类型的实例
2. 在该实例中，会根据传入的数据类型进行分开处理
   1. 复杂数据类型:转化为reactive返回的proxy实例
   2. 简单数据类型：不做处理
3. 无论我们执行obj.value.name还是obj.value.name = xxx本质上都是触发了get value
4. 之所以会进行 响应性 是因为 obj.value 是一个 reactive 函数生成的 proxy

总结

那么到这里我们就已经完成了 ref 响应性函数的构建，那么大家还记不记得开篇时所问的三个问题：

1. ref 函数是如何进行实现的呢？
2. ref 可以构建简单数据类型的响应性吗？
3. 为什么 ref 类型的数据，必须要通过 .value 访问值呢？

大家现在再次面对这三个问题，是否能够回答出来呢？

1. 问题一: ref 函数是如何进行实现的呢？
   1. ref 函数本质上是生成了一个 RefImpl 类型的实例对象,通过 get 和 set 标记处理了value 函数
2. 问题二： ref 可以构建简单数据类型的响应性吗？
   1. 是的。 ref 可以构建简单数据类型的响应性
3. 问题三：为什么 ref 类型的数据，必须要通过 .value 访问值呢？
   1. 因为 ref 需要处理简单数据类型的响应性，但是对于简单数据类型而言，它无法通过proxy 建立代理。
   2. 所以vue通过get value() 和 set value() 定义了两个属性函数，通过主动触发这两个函数（属性调用）的形式来进行依赖收集和依赖触发

computed && watch

computed

debugged调试，具体流程

1. 整个事件有obj.name开始
2. 触发 proxy 实例的 setter
3. 执行 trigger，第一次触发依赖
4. 注意，此时 effect 包含调度器属性，所以会触发调度器
5. 调度器指向ComputedRefImpl的构造函数中传入的匿名函数
6. 在匿名函数中会：再次触发依赖
7. 即:两次触发依赖
8. 最后执行：computed中的回调函数

总结

接下来我们来总结一下计算属性实现的重点：

1. 计算属性的实例,本质上是一个ComputedRefImpl的实例
2. ComputedRefImpl 中通过 dirty 变量来控制 run 的执行和 triggerRefValue 的触发
3. 想要访问计算属性的值,必须通过 .value ,因为它内部和 ref 一样是通过get value来进
4. 每次 .value 时都会触发 trackRefValue 即：收集依赖
5. 在依赖触发时，需要谨记，先触发 computed 的 effect ，再触发非 computed 的 effect行实现的

Vue运行时核心

基础概念

虚拟DOM

虚拟 DOM (Virtual DOM，简称 VDOM) 是一种编程概念，意为将目标所需的 UI 通过数据结构“虚拟”地表示出来，保存在内存中，然后将真实的 DOM 与之保持同步。这个概念是由 React 率先开拓，随后被许多不同的框架采用，当然也包括 Vue。

渲染管线

从高层面的视角看，Vue 组件挂载时会发生如下几件事：

1. 编译：Vue 模板被编译为渲染函数：即用来返回虚拟 DOM 树的函数。这一步骤可以通过构建步骤提前完成，也可以通过使用运行时编译器即时完成。
2. 挂载：运行时渲染器调用渲染函数，遍历返回的虚拟 DOM 树，并基于它创建实际的 DOM 节点。这一步会作为响应式副作用执行，因此它会追踪其中所用到的所有响应式依赖。
3. 更新：当一个依赖发生变化后，副作用会重新运行，这时候会创建一个更新后的虚拟 DOM 树。运行时渲染器遍历这棵新树，将它与旧树进行比较，然后将必要的更新应用到真实 DOM 上去。

...

h函数

查看 packages/runtime-core/src/renderer.ts 中第 354 patch 方法的代码可知，Vue 总共处理了：

1. Text: 文本节点
2. Comment：注释节点
3. Static: 静态 DOM 节点
4. Fragment:包含多个根节点的模板被表示为一个片段(fragment)括
5. ELEMENT: DOM 节点Imooc
6. COMPONENT：组件
7. TELEPORT:新的内置组件
8. SUSPENSE：新的 内置组件
9. ...

在vue中，组件本质上是 一个对象或一个函数（Function Component）

shapeFlag

组件的设计原理与渲染

简介

组件本身是一个对象(仅考虑对象的情况,忽略函数式组件)。它必须包含一个render函数，该函数决定了它的渲染内容。

如果我们想要定义数据，那么需要通过 data 选项进行注册。 data 选项应该是一个 函数，并且renturn一个对象，对象中包含了所有的响应性数据。

除此之外，我们还可以定义例如 生命周期、计算属性、 watch 等对应内容。

无状态基础挂着逻辑组件

Vue 中通常把 状态 比作 数据 的意思。我们所谓的无状态，指的就是 无数据 的意思。

Diff算法核心实现

前置知识

那么到目前为止，我们已经完成了 4 种 diff 场景的对应处理，经过前面的学习我们可以知道，对于前四种 diff 场景而言， diff 的处理本质上是比较简单的:

1. 自前向后的 diff对比：主要处理从前到后的相同 VNode。例如： (a b) c 对应(a b) d e
2. 自后向前的 diff对比:主要处理从后到前的相同VNode。例如: a (b c)对应d e (b c)
3. 新节点多余旧节点的 diff 对比：主要处理新增节点。
4. 旧节点多余新节点的 diff 对比：主要处理删除节点。

但是仅靠前四种场景的话,那么是无法满足实际开发中的所有更新逻辑的。所以我们还需要最关键的一种场景需要处理，那就是 乱序场景。

最长递增子序列

1. 什么是最长递增子序列
2. 最长递增子序列在diff 中的作用是什么

维基百科 -最长递增子序列

在一个给定的数值序列中，找到一个子序列，使得这个子序列元素的数值依次递增，并且这个子序列的长度尽可能地大。

乱序下的diff比对

1. diff指的就是:添加、删除、打补丁、移动这四个行为

2. 最长递增子序列 是什么，如何计算的，以及在 diff 中的作用

3. 场景五的乱序，是最复杂的场景，将会涉及到 添加、删除、打补丁、移动 这些所有场景。

总结

1. 首先我们讲解了dom、节点、节点树和虚拟DOM,虚拟节点之间的概念。
2. 然后我们说明了 render 函数和 h 函数各自的作用。我们知道 h 函数可以得到一个 vnode ，而 render 函数可以渲染一个 vnode
3. 接下来我们讲解了挂载、更新、卸载,这三组概念。也知道了针对于不同的vnode节点,那么他们的挂载、更新、卸载方式也都是不同的。
4. 下面我们讲解了组件,我们知道组件本质上是一个对象(或函数) ,组件的挂载本质上是render 函数的挂载。
5. 组件内部维护了一个effect对象,以达到响应性渲染的效果。
6. 而针对于 setup 函数而言，它在实现上反而更加简单，因为我们不需要改变 this 指向了。
7. 结合所学，新旧节点的所有挂载和更新情况，可以被分为九种场景：
   1. 旧节点为纯文本时：
      1. 新节点为纯文本：执行文本替换操作
      2. 新节点为空:删除旧节点
      3. 新节点为数组：清空文本，添加多个新节点2.
   2. 旧节点为空时：
      1. 新节点为纯文本：添加新节点
      2. 新节点为空：不做任何事情
      3. 新节点为数组时：添加多个新节点
   3. 旧节点是数组时：
      1. 新节点为纯文本：删除所有旧节点，添加新节点
      2. 新节点为空：删除所有旧节点
      3. 新节点为数组时：进行 diff 操作
8. 最后的 diff 分为 5 种场景，最后一种场景还是比较复杂的。

编译时核心设计原则

前言

模版编译的核心流程

正常流程

Vue中

框架实现

接下来我们通过parseChildren方法处理所有的子节点,整个处理的过程分为两大块:

1. 构建有限自动状态机解析模板
2. 扫描 token 生成 AST 结构

总结

我们知道，整个 compiler 的过程，就是一个把：源代码（template）转化为目标代码（render函数）的过程。

在这个过程中，主要经历了三个大的步骤：

1. 解析( parse ) template模板,生成AST
2. 转化(transform) AST,得到JavaScript AST
3. 生成（generate） render 函数这

三步是非常复杂的一个过程，内部的实现涉及到了非常复杂的计算方法，并且会涉及到一些我们现在还没有了解过得概念，比如：自动状态机。

这些内容我们都会放到下一章进行讲解，本章我们只需要知道 compiler 的作用，以及三大步骤即可都在干什么即可。

构建compile编译器

总结

我们知道整个编辑器的处理过程分成了三部分：

1. 解析模板 template 为 AST1,在这一步过程中,我们使用了
   1. 有限自动状态机解析模板得到了 tokens
      1. 通过扫描 tokens 最终得到了`AST王
2. 转化 AST 为 JavaScript AST
   1. 这一步是为了最终生成 render 函数做准备
   2. 利用了深度优先的方式，进行了自下向上的逐层转化
3. 生成 render 函数
   1. 这一步是最后的解析环节,我们需要对JavaScript AST进行处理,得到最终的render函数

深入编辑器处理逻辑

参考

• https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/Proxy
• https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty
• https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/Reflect
• https://developer.mozilla.org/zh-CN/docs/Web/API/Document_Object_Model
• https://cn.vuejs.org/guide/extras/rendering-mechanism.html#virtual-dom

有限状态自动机-维基百科

有限状态机（英语：finite-state machine，缩写：FSM）又称有限状态自动机（英语：finite-state automaton，缩写：FSA），简称状态机，是表示有限个状态以及在这些状态之间的转移和动作等行为的数学计算模型。

直接看阮一峰老师的 JavaScript与有限状态机

阮一峰的网络日志- JavaScript与有限状态机

WeakMap

1. key必须是对象
2. key是弱引用

弱引用与强引用

• 弱引用：不会影响垃圾回收机制。即： WeakMap 的 key 不再存在任何引用时，会被直接回收。

• 强引用：会影响垃圾回收机制。存在强应用的对象永远不会被回收。

对比示例

https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/Array/reduce

语法

参数

• callbackFn

  为数组中每个元素执行的函数。其返回值将作为下一次调用 callbackFn 时的 accumulator 参数。对于最后一次调用，返回值将作为 reduce() 的返回值。该函数被调用时将传入以下参数：accumulator上一次调用 callbackFn 的结果。在第一次调用时，如果指定了 initialValue 则为指定的值，否则为 array[0] 的值。currentValue当前元素的值。在第一次调用时，如果指定了 initialValue，则为 array[0] 的值，否则为 array[1]。currentIndexcurrentValue 在数组中的索引位置。在第一次调用时，如果指定了 initialValue 则为 0，否则为 1。array调用了 reduce() 的数组本身。

• initialValue 可选

  第一次调用回调时初始化 accumulator 的值。如果指定了 initialValue，则 callbackFn 从数组中的第一个值作为 currentValue 开始执行。如果没有指定 initialValue，则 accumulator 初始化为数组中的第一个值，并且 callbackFn 从数组中的第二个值作为 currentValue 开始执行。在这种情况下，如果数组为空（没有第一个值可以作为 accumulator 返回），则会抛出错误。

返回值

使用“reducer”回调函数遍历整个数组后的结果。

异常

• TypeError

  如果数组为空且未提供 initialValue，则会抛出异常。

手写实现

总结

• 三者都可以改变函数的this对象指向
• 三者第一个参数都是this要指向的对象，如果如果没有这个参数或参数为undefined或null，则默认指向全局window
• 三者都可以传参，但是apply是数组，而call是参数列表，且apply和call是一次性传入参数，而bind可以分为多次传入
• bind是返回绑定this之后的函数，apply、call 则是立即执行

call

定义：call方法的第一个参数也是this的指向，后面传入的是一个参数列表

跟apply一样，改变this指向后原函数会立即执行，且此方法只是临时改变this指向一次

apply

定义： 调用一个具有给定 this 值的函数，及以一个数组的形式提供的参数。

改变this指向后原函数会立即执行，且此方法只是临时改变this指向一次

bind

定义：创建一个新的函数，在 bind 被调用时，这个新函数的 this 被指定为 bind()的第一个参数，而其余参数将作为新函数的参数，供调用时使用。

Proxy与Object.defineProperty

1. Proxy
   1. Proxy 将代理一个对象（被代理对象），得到一个新的对象（代理对象），同时拥有被代理对象中所有的属性。
   2. 当想要修改对象的指定属性时,我们应该使用代理对象进行修改
   3. 代理对象 的任何一个属性都可以触发 handler 的 getter 和 setter
2. Object.defineProperty
   1. Object.defineProperty 为指定对象的指定属性设置属性描述符
   2. 当想要修改对象的指定属性时，可以使用原对象进行修改
   3. 通过属性描述符，只有 被监听 的指定属性，才可以触发 getter 和 setter

所以当 vue3 通过 Proxy 实现响应性核心 API 之后，vue 将 不会 再存在新增属性时失去响应性的问题。

Reflect

https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/Reflect

Reflect+Proxy

当我们期望监听代理对象的 getter 和 setter 时,不应该使用 target[key] ,因为它在某些时刻（比如 fullName）下是不可靠的。而 应该使用 Reflect ，借助它的 get 和 set 方法，使用receiver （proxy 实例） 作为 this，已达到期望的结果（触发三次 getter）

最后如果我们想要“安全”的使用Proxy,还需要配合Reflect一起才可以,因为一旦我们在被代理对象的内部，通过 this 触发 getter 和 setter 时，也需要被监听到。

搬运自 MVC，MVP 和 MVVM 的图示

作者： 阮一峰

日期： 2015年2月 1日

MVC，MVP 和 MVVM 的图示

作者： 阮一峰

日期： 2015年2月 1日

复杂的软件必须有清晰合理的架构，否则无法开发和维护。

MVC（Model-View-Controller）是最常见的软件架构之一，业界有着广泛应用。它本身很容易理解，但是要讲清楚，它与衍生的 MVP 和 MVVM 架构的区别就不容易了。

昨天晚上，我读了《Scaling Isomorphic Javascript Code》，突然意识到，它们的区别非常简单。我用几段话，就可以说清。

（题图：摄于瓦伦西亚，西班牙，2014年8月）

一、MVC

MVC模式的意思是，软件可以分成三个部分。

• 视图（View）：用户界面。
• 控制器（Controller）：业务逻辑
• 模型（Model）：数据保存

各部分之间的通信方式如下。

1. View 传送指令到 Controller
2. Controller 完成业务逻辑后，要求 Model 改变状态
3. Model 将新的数据发送到 View，用户得到反馈

所有通信都是单向的。

二、互动模式

接受用户指令时，MVC 可以分成两种方式。一种是通过 View 接受指令，传递给 Controller。

另一种是直接通过controller接受指令。

三、实例：Backbone

实际项目往往采用更灵活的方式，以 Backbone.js 为例。

1. 用户可以向 View 发送指令（DOM 事件），再由 View 直接要求 Model 改变状态。
2. 用户也可以直接向 Controller 发送指令（改变 URL 触发 hashChange 事件），再由 Controller 发送给 View。
3. Controller 非常薄，只起到路由的作用，而 View 非常厚，业务逻辑都部署在 View。所以，Backbone 索性取消了 Controller，只保留一个 Router（路由器） 。

四、MVP

MVP 模式将 Controller 改名为 Presenter，同时改变了通信方向。

1. 各部分之间的通信，都是双向的。
2. View 与 Model 不发生联系，都通过 Presenter 传递。
3. View 非常薄，不部署任何业务逻辑，称为"被动视图"（Passive View），即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。

五、MVVM

MVVM 模式将 Presenter 改名为 ViewModel，基本上与 MVP 模式完全一致。

唯一的区别是，它采用双向绑定（data-binding）：View的变动，自动反映在 ViewModel，反之亦然。Angular 和 Ember 都采用这种模式。

在本章中，我们对整个 vue 框架设计中的一些基本概念都做了一个了解。明确了如下基本概念：

1. 命令式
2. 声明式
3. 心智负担
4. 框架设计与取舍之间的关系
5. 运行时
6. 编译时
7. 运行时 + 编译时
8. 副作用
9. reactivity、 runtime、compiler 三者之间的运行关系
10. 扩展：良好的 ts 支持

当我们把这些基本概念了解清楚之后，那么下一章我们就可以准备开始构建我们的 vue 3 框架了。

编程范式之命令式编程

编程范式之声明式编程

命令式 VS声明式

什么是运行时

什么是编译时

运行时+编译时

为什么Vue要设计成一个运行时+编译时的框架呢

• 针对于 纯运行时 而言：因为不存在编译器，所以我们只能够提供一个复杂的 JS 对象。
• 针对于 纯编译时 而言：因为缺少运行时，所以它只能把分析差异的操作，放到 编译时 进行，同样因为省略了运行时，所以速度可能会更快。但是这种方式这将损失灵活性（具体可查看第六章虚拟 DOM ，或可点击 这里 查看官方示例)。比如 svelte，它就是一个纯编译时的框架，但是它的实际运行速度可能达不到理论上的速度。
• 运行时 + 编译时：比如 vue 或 react 都是通过这种方式来进行构建的，使其可以在保持灵活性的基础上，尽量的进行性能的优化，从而达到一种平衡。

11：副作用

副作用指的是：当我们对数据进行setter或getter操作时，所产生的一系列后果

副作用是可以产生多个的

• setter：赋值
• getter：取值
• 副作用可以产生多个吗?
  • 可以的

12: Vue3框架设计概述

源码解析

目录结构

Debugger

1. 下载 vue 源代码，推荐通过 该仓库 下载指定版本（注意：出错)I直接下载 ZIP文件会导致 build
2. 为源代码开启 sourcemap，以方便后续进行 debugger
   • 参考minimist文档，在package.json中的script build命令后加上-s即可
3. 在 packages/vue/examples 中，创建文件，导入 ../../dist/vue.global.js ，书写测试实例
4. 通过Live Server 启动服务
5. 在浏览器控制台的Sources中查看运行代码,并进行debugger

手写mini-vue

• vue-next-mini

• 为框架进行配置-导入ts

• 引入prettier、eslint

• 模块打包器rollup

  • rollup.config.js 文档参考https://www.rollupjs.com/configuration-options/

特点：

• Promise.all() 方法接收一个promise的iterable类型（MDN）
• 只返回一个promise实例
• 当传入的参数promise全部成功时，最后的结果才会成功（成功的结果是所有的promise的成功的结果组成的数组），只要有一个promise失败，all返回的实例就是一个失败的promise（失败的结果是传入的参数中的第一个失败的promise的结果）

Promise.race（比比谁先改变状态！）

特点：

1. 传入的参数和返回的结果形式和all方法一样
2. 区别：只要传入的promise有一个状态改变了，最后的结果就会立即改变
3. 例如有一个成功，直接走race的resolve，如果有一个失败，直接走reject

Promise.any

特点： 几乎和all方法“一样” 区别：all是所有都成功最后才成功,一个失败了，最后就失败，allSettled是只要有一个成功了最后就是成功了，遇到失败的还是继续监测，直到找到成功的或者检查完。 好理解一点就是，all方法类似于Array的every方法，any类似于Array的some方法

Promise.allSettled

特点： 传参和返回值和all方法一样

返回值都是已成功状态（不论传入的是已成功还是已失败的promise）

一旦所指定的 promises 集合中每一个 promise 已经完成，无论是成功的达成或被拒绝，未决议的 Promise将被异步完成。那时，所返回的 promise 的处理器将传入一个数组作为输入，该数组包含原始 promises 集中每个 promise 的结果。 对于每个结果对象，都有一个 status 字符串。如果它的值为 fulfilled，则结果对象上存在一个 value 。如果值为 rejected，则存在一个 reason 。value（或 reason ）反映了每个 promise 决议（或拒绝）的值。

Promise.prototype.finally

特点： 在promise结束时，无论结果是fulfilled或者是rejected，都会执行指定的回调函数。这为在Promise是否成功完成后都需要执行的代码提供了一种方式。 避免了同样的语句需要在then()和catch()中各写一次的情况。

参考

• 断点续传

• 大文件分包上传

  • 遇到问题

    1. 前后端上传请求超时限制，一次性传输大小限制。

    2. 网络抖动等，失败后需要重新上传。

    3. http1.1版本， TCP连接默认是open的，所有请求都通过同一个连接进行数据传输，如果前面的请求被阻塞了，后面的请求也得不到响应，也叫HTTP/1.1 中的队头阻塞问题，除非建立多个连接，但是多个连接会浪费资源。

    4. 无进度条，用户体验极差。

分包上传

前端

获取文件的二进制内容，然后对其内容拆分成指定大小的切片文件，最后将每个切片上传到服务端即可。

流程：获取文件 ➡️ 分片 ➡️ 上传

需要优化的点

• 中断后无需重新上传（断点续传）
• 上传过的文件无需上传（秒传）
• 显示上传进度

后端

根据切片文件的唯一标识在后端将多个相同文件的切片还原成一个文件

示例代码

断点续传

以上代码还需要继续优化的点：断点续传、秒传、上传进度和暂停

1、断点续传

为什么需要断点续传？

• 即使将大文件拆分成切片上传，我们仍需等待所有切片上传完毕，在等待过程中，可能发生一系列导致部分切片上传失败的情形，如网络故障、页面关闭等。由于切片未全部上传，因此无法通知服务端合成文件。这种情况下可以通过断点续传来进行处理。断点续传指的是：可以从已经上传部分开始继续上传未完成的部分，而没有必要从头开始上传，节省上传时间。

怎么实现断点续传？

由于整个上传过程是按切片维度进行的，且mkfile接口是在所有切片上传完成后由客户端主动调用的，因此断点续传的实现也十分简单：

• 在切片上传成功后，保存已上传的切片信息
• 当下次传输相同文件时，遍历切片列表，只选择未上传的切片进行上传
• 所有切片上传完毕后，再调用mkfile接口通知服务端进行文件合并
• 因此问题就落在了如何保存已上传切片的信息了，保存一般有两种策略
  • 1.可以通过locaStorage等方式保存在前端浏览器中，这种方式不依赖于服务端，实现起来也比较方便，缺点在于如果用户清除了本地文件，会导致上传记录丢失
  • 2.服务端本身知道哪些切片已经上传，因此可以由服务端额外提供一个根据文件context查询已上传切片的接口，在上传文件前调用该文件的历史上传记录

示例代码

秒传

什么是秒传？

• 已经上传过的文件，并且在后端已经拼接完成，如果再次上传的话后端不做处理，直接返回拼接好的文件的信息即可，这里主要后端实现，由于篇幅关系，这里不做过多描述。

3、上传进度和暂停

• 通过xhr.upload中的progress方法可以实现监控每一个切片上传进度。
• 上传暂停的实现也比较简单，通过xhr.abort可以取消当前未完成上传切片的上传，实现上传暂停的效果，恢复上传就跟断点续传类似，先获取已上传的切片列表，然后重新发送未上传的切片。
• 由于篇幅关系，上传进度和暂停的功能这里就先不实现了。

参考

https://cloud.tencent.com/developer/article/2391382

原理：scoped会在DOM结构及css样式上加上唯一性的标记【data-v-something】属性，即CSS带属性选择器，以此完成类似作用域的选择方式，从而达到样式私有化，不污染全局的作用。

算法（Algorithm）是指用来操作数据、解决程序问题的一组方法。对于同一个问题，使用不同的算法，也许最终得到的结果是一样的，但在过程中消耗的资源和时间却会有很大的区别。

算法的指标

主要还是从算法所占用的「时间」和「空间」两个维度去考量。

• 时间维度：是指执行当前算法所消耗的时间，我们通常用「时间复杂度」来描述。
• 空间维度：是指执行当前算法需要占用多少内存空间，我们通常用「空间复杂度」来描述。

时间复杂度

首先要说的是，时间复杂度的计算并不是计算程序具体运行的时间，而是算法执行语句的次数。 当我们面前有多个算法时，我们可以通过计算时间复杂度，判断出哪一个算法在具体执行时花费时间最多和最少。

通常我们计算时间复杂度都是计算最坏情况

常见的时间复杂度

• 常数阶O(1),
• 对数阶O(log2 n),
• 线性阶O(n),
• 线性对数阶O(n log2 n),
• 平方阶O(n^2)，
• 立方阶O(n^3)
• k次方阶O(n^K),
• 指数阶O(2^n)。

空间复杂度

空间复杂度是对一个算法在运行过程中临时占用存储空间大小的量度。

计算方法：

1. 忽略常数，用O(1)表示
2. 递归算法的空间复杂度=递归深度N*每次递归所要的辅助空间
3. 对于单线程来说，递归有运行时堆栈，求的是递归最深的那一次压栈所耗费的空间的个数，因为递归最深的那一次所耗费的空间足以容纳它所有递归过程。

在未排序区域中，从前向后不断对比相邻数据，将较大值不断向后移动，直至移动到未排序区域的最后一位。

选择排序

遍历未排序区域，通过对比相邻数据，记录较小值的下标，每遍历一遍就能找出未排序区域中最小的数据，将记录的未排序区域的最小值与未排序区域的第一个元素交换位置，该位为有序，未排序区域长度减一，直至完成排序。

插入排序

将第一个数据视为已排序区域，取第一个未排序区域中的数据，从它前一个位置依次向前寻找，直至找到第一个小于等于它的数据，或超出数组范围（已排序区域中没有比它小的值），则将它从未排序区域移除，插入到第一个小于等于它的位置后，或第一位。直至全部排序结束。

归并排序

通过递归将数组不断一分为二，直至每个数组只有一个元素，这时数组即为有序的。在合并时因为两个数组都是有序的，只需比较两个有序数组中的第一个元素，将较小的放入合并后的数组中，即可合并出一个有序数组。

快速排序

从未排序区域中取一个值视为基准值（通常取最中间位置的值），将剩余数据中，小于该值的数据放入leftArr中，将大于等于该值的数据放入rightArr中，此时基准值即为有序。再不断对leftArr和rightArr分别重复该步骤，直至数组中只有一个元素（数组中只有一个元素时为有序数组），将leftArr、基准值、rightArr按顺序合并成一个数组，该数组即为有序。

参考

https://juejin.cn/post/7127636022996762654

https://www.cnblogs.com/pangqianjin/p/14998643.html#:~:text=JavaScript%E6%89%8B%E5%86%99%E5%87%A0%E7%A7%8D%E5%B8%B8%E8%A7%81%E7%9A%84%E6%8E%92%E5%BA%8F%E7%AE%97%E6%B3%95%EF%BC%9A%E5%86%92%E6%B3%A1%E3%80%81%E9%80%89%E6%8B%A9%E3%80%81%E6%8F%92%E5%85%A5%E3%80%81%E5%B8%8C%E5%B0%94%E3%80%81%E5%BD%92%E5%B9%B6%E3%80%81%E5%BF%AB%E6%8E%92%201%20%E5%86%92%E6%B3%A1%E6%8E%92%E5%BA%8F%202%20%E9%80%89%E6%8B%A9%E6%8E%92%E5%BA%8F%203,%E6%8F%92%E5%85%A5%E6%8E%92%E5%BA%8F%204%20%E5%B8%8C%E5%B0%94%E6%8E%92%E5%BA%8F%205%20%E5%BD%92%E5%B9%B6%E6%8E%92%E5%BA%8F%206%20%E5%BF%AB%E9%80%9F%E6%8E%92%E5%BA%8F

根左右

中序遍历

左根右

递归实现

栈实现

后续遍历

左右根

递归实现

栈实现

计算根左右的结果，再利用reverse反转得到后续遍历的结果

思路：

vue3 过渡到 Nuxt3

语法部分

常用

• vue3 setup已经默认将大部分所需要的钩子导入了，不需要额外导入也能使用
• router-link: 路由跳转，不会预加载页面 | NuxtLink: 路由跳转，是router-link的封装，会预加载页面。
• router.push 和 navigateTo, navigateTo会预加载页面，一般需要async异步，比如async navigateTo('/')

坑

• onBeforeRouteUpdate、onBeforeRouteLeave将不起作用，可能是bug (2023年12月19日22:02:13-setup环境中-可能是我使用方式不对)
• 函数/组件或，如果涉及到 只有客户端才能访问到的操作如 window对象、dom操作(document、ref)等，函数需要在onMounted/nextTick中调用 | 组件需要使用ClientOnly组件进行包裹
• 第三方库/插件，如果涉及到 只有客户端才能访问到的操作如 window对象、dom操作(document、ref)等，需要在plugin目录下添加相应的ts文件xxx.client.ts，并在nuxt.config.ts中添加相应的配置如 plugin:[{ src: '~/plugins/xxx.client', mode: 'client' }]
• 如果你需要使用@nuxt/image，请注意public目录和assets目录的区别
  • public/包含的文件在根目录中提供，并且不会被构建过程修改。如果您想从服务器上提供资产，请查看"public/"目录。
  • assets/存储在目录中的图像不会使用 Nuxt Image 进行处理，因为这些图像是由 webpack 管理的。
  • 详情请查看https://nuxt.com/docs/guide/directory-structure/public https://image.nuxt.com/get-started/providers#local-images
• 如果你有同时使用到slot和client-only组件，且slot包裹着client-only组件，需要注意slot会导致client-only组件失效（这个问题我是使用element plus时遇到的，在el-form组件中使用client-only失效，以及在el-skeleton <template #default></template>中使用client-only也是失效，因此我怀疑是slot影响的结果）解决也比较简单将client-only移动到使用slot的组件的外层即可

插件使用/模块使用

一些常用的库或组件，也许官方会或者一些社区大佬已经完成了对Nuxt3的兼容详细可查看 https://nuxt.com/modules。如果需要使用一些冷门库或者其他没有对Nuxt3兼容的库，你需要手动实现，比如我使用quill 编辑器，因为它使用到了document，但是这个对象只有在客户端才能访问，当nuxt服务端加载时就会报错：500 document is not defined；

解决方法

• 使用nuxt中的和client-only组件：我们可以在将quill封装为一个组件，在组件中初始化，在我们需要使用到的地方使用client-only组件进行包裹即可。
• 使用plugins文件夹： 可通过创建一个xxx.client.ts，这个文件的资源将在客户端中加载，你可以在这里面引入仅在客户端加载的资源。最后将这个文件添加到nuxt.config.ts中的plugin对象中。

注意

• 注意时效性，本篇于2024年3月5日完成
• 未完结待补充

github webhooks转发工具

转发github issue和comment 到企业微信机器人

准备工作

• Golang开发工具
• 阿里云云函数FC
• github webhooks链接以及秘钥（我这里只打开了Issue和comment）

主要工作（难点）

• 解析JSON，拼接字符串
• 云函数踩坑
• 本地测试比较困难（需要公网ip服务器能够被github那边ping通）
• sha256加密解密

完整代码

效果预览

参考链接以及使用工具链接

• https://webhook.site/
• 部署平台阿里云函数 https://fcnext.console.aliyun.com/overview

GLSL 使用标准的 C/C++ 语句集。它有选择语句（if-else和switch-case）、迭代语句（for、while和do-while）和跳转语句（break、continue和return）。这些语句基本上按照 C++ 定义的方式工作（例如，您可以在for语句中声明变量），但也有一些限制。例如，您可以在 C++ 中的 if条件中声明变量，但不能在 GLSL 中声明。

请注意，跳转语句列表中没有goto 。GLSL 没有goto结构。

C/C++函数模型允许函数是递归的。也就是说，函数A可以调用函数B，函数B本身又调用函数A。确实，函数A可以调用自己。显然，必须有一些条件来防止无限递归，但 C/C++ 允许这样做。

GLSL**没有。**GLSL 内存模型不允许递归函数调用。这允许 GLSL 在不允许递归的硬件上执行。它允许 GLSL 在无法任意写入内存时运行，这对大多数着色器硬件都是如此（尽管随着时间的推移它变得不那么真实了）。

所以，在 GLSL 中没有递归。任何形式的。

参考

• DNS 解析
• TCP 连接
• 发送 HTTP 请求
• 服务器处理请求并返回 HTTP 报文
• 浏览器解析渲染页面
• 连接结束

跨域

同源策略

跨域问题其实就是浏览器的同源策略所导致的。

「同源策略」是一个重要的安全策略，它用于限制一个[origin]的文档或者它加载的脚本如何能与另一个源的资源进行交互。它能帮助阻隔恶意文档，减少可能被攻击的媒介。 --来源 MDN

「protocol（协议）、domain（域名）、port（端口）三者一致。」 一致的情况下我们叫同源。

一个图片_url访问后直接下载怎样实现

请求的返回头里面，用于浏览器解析的重要参数就是 OSS 的 API 文档里面的返回 http 头，决定用户下载行为的参数。 下载的情况下：

fetch发送2次请求的原因

fetch 发送 post 请求的时候，总是发送 2 次，第一次状态码是 204，第二次才成功？

原因很简单，因为你用 fetch 的 post 请求的时候，导致 fetch 第一次发送了一个 Options 请求，询问服务器是否支持修改的请求头，如果服务器支持，则在第二次中发送真正的请求。

Cookie_sessionStorage_localStorage的区别

共同点：

都是保存在浏览器端，并且是同源的

区别：

• cookie 数据始终在同源的 http 请求中携带（即使不需要），即 cookie 在浏览器 和服务器间来回传递。
• sessionStorage 和 localStorage 不会自动把数据发给服务器，仅 在本地保存
• cookie 数据还有路径（path）的概念，可以限制 cookie 只属于某个路径下,

存储大小限制也不同

• cookie 数据不能超过 4K，同时因为每次 http 请求都会携带 cookie， 所以 cookie 只适合保存很小的数据，如回话标识。
• webStorage 虽然也有存储大小的限制，但是比 cookie 大得多，可以达到 5M 或更大 数据

有效期不同

• sessionStorage：仅在当前浏览器窗口关闭前有效，自然也就不可能持久保持，
• localStorage： 始终有效，窗口或浏览器关闭也一直保存，因此用作持久数据；
• cookie：只在设置的 cookie 过期时间之前一直有效，即使窗口或浏览器关闭。（key：本身就是一个回话过程，关 闭浏览器后消失，session 为一个回话，当页面不同即使是同一页面打开两次，也被视为 同一次回话）

作用域不同

• sessionStorage：不在不同的浏览器窗口中共享，即使是同一个页面；
• localStorage：在所有同源窗口都是共享的；
• cookie：也是在所有同源窗口中共享的

补充说明一下 cookie 的作用：

保存用户登录状态。例如将用户 id 存储于一个 cookie 内，这样当用户下次访问该页面 时就不需要重新登录了，现在很多论坛和社区都提供这样的功能。 cookie 还可以设置 过期时间，当超过时间期限后，cookie 就会自动消失。因此，系统往往可以提示用户保 持登录状态的时间：常见选项有一个月、三个 月、一年等。

跟踪用户行为。例如一个天气预报网站，能够根据用户选择的地区显示当地的天气情况。 如果每次都需要选择所在地是烦琐的，当利用了 cookie 后就会显得很人性化了，系统能 够记住上一次访问的地区，当下次再打开该页面时，它就会自动显示上次用户所在地区 的天气情况。因为一切都是在后台完成，所以这样的页面就像为某个用户所定制的一样，使用起来非常方便定制页面。如果网站提供了换肤或更换布局的功能，那么可以使 用 cookie 来记录用户的选项，例如：背景色、分辨率等。当用户下次访问时，仍然可以 保存上一次访问的界面风格。

cookie_session区别

1. cookie 数据存放在客户的浏览器上，session 数据放在服务器上。
2. cookie 不是很安全，别人可以分析存放在本地的 COOKIE 并进行 COOKIE 欺骗 考虑到安全应当使用 session。
3. session 会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能 考虑到减轻服务器性能方面，应当使用 COOKIE。
4. 单个 cookie 保存的数据不能超过 4K，很多浏览器都限制一个站点最多保存 20 个 cookie。

XSS和CRSF攻击防御

XSS, 即为（Cross Site Scripting）, 中文名为跨站脚本, 是发生在目标用户的浏览器层面 上的，当渲染 DOM 树的过程成发生了不在预期内执行的 JS 代码时，就发生了 XSS 攻击。 大多数 XSS 攻击的主要方式是嵌入一段远程或者第三方域上的 JS 代码。实际上是在目 标网站的作用域下执行了这段 JS 代码

CSRF（Cross Site Request Forgery，跨站请求伪造），字面理解意思就是在别的站点伪造 了一个请求。专业术语来说就是在受害者访问一个网站时，其 Cookie 还没有过期的情 况下，攻击者伪造一个链接地址发送受害者并欺骗让其点击，从而形成 CSRF 攻击

防御

XSS 防御的总体思路是：对输入(和 URL 参数)进行过滤，对输出进行编码。也就是对提交的所有内容进行过滤，对 url 中的参数进行过滤，过滤掉会导致脚本执行的相关内容； 然后对动态输出到页面的内容进行 html 编码，使脚本无法在浏览器中执行。虽然对输 入过滤可以被绕过，但是也还是会拦截很大一部分的 XSS 攻击。

防御 CSRF 攻击主要有三种策略：

• 验证 HTTP Referer 字段；
• 在请求地址中添加 token 并 验证；
• 在 HTTP 头中自定义属性并验证

Cookie如何防范XSS攻击

XSS攻击

XSS（跨站脚本攻击）是指攻击者在返回的 HTML 中嵌入 javascript 脚本，

Cookie如何防范XSS攻击

为了减轻这些攻击，需要在 HTTP 头部配上，set-cookie： httponly-这个属性可以防止 XSS,它会禁止 javascript 脚本来访问 cookie。 secure - 这个属性告诉浏览器仅在请求为 https 的时候发送 cookie。 结果应该是这样的：Set-Cookie=<cookie-value>....

一句话概括RESTFUL

就是用 URL 定位资源，用 HTTP 描述操作。

将你的个人介绍和档案放置在此处。

HTTPS的SSL加密是在传输层实现的。

基本概念

1. HTTP： 超文本传输协议，是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准（TCP），用于从 WWW 服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使网络传输减少。
2. HTTPS：是以安全为目标的 HTTP 通道，简单讲是 HTTP 的安全版，即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。
3. HTTPS协议的主要作用：建立一个信息安全通道，来确保数组的传输，确保网站的真实性。

区别

HTTP数据都是未加密的，也就是明文的，网景公司设置了 SSL 协议来对 HTTP协议传输的数据进行加密处理，简单来说 HTTPS 协议是由 HTTP 和 SSL 协议构建的可进行加密传输和身份认证的网络协议，比HTTP 协议安全性更高

主要区别

1. HTTPS协议需要ca证书，费用较高
2. HTTP是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 ssl 加密传输协议。
3. 使用不同的链接方式，端口也不同，一般而言，HTTP 协议的端口为 80，HTTPS 的端口为 443
4. HTTP连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP安全。

工作原理

客户端在使用 HTTPS 方式与 Web 服务器通信时有以下几个步骤

1. 客户端使用https url访问服务器，则要求 web 服务器建立 ssl 链接。
2. web 服务器接收到客户端的请求之后，会将网站的证书（证书中包含了公钥），返回或者说传输给客户端。
3. 客户端和 web 服务器端开始协商 SSL 链接的安全等级，也就是加密等级。
4. 客户端浏览器通过双方协商一致的安全等级，建立会话密钥，然后通过网站的公钥来加密会话密钥，并传送给网站。
5. web 服务器通过自己的私钥解密出会话密钥。
6. web 服务器通过会话密钥加密与客户端之间的通信。

HTTPS的优点

1. 使用 HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
2. HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比 http 协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
3. HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
4. 谷歌曾在 2014 年 8 月份调整搜索引擎算法，并称“比起同等 HTTP 网站，采用 HTTPS 加密的网站在搜索结果中的排名将会更高”。

HTTPS的缺点

1. https 握手阶段比较费时，会使页面加载时间延长 50%，增加 10%~20%的耗电。
2. https 缓存不如 http 高效，会增加数据开销。 SSL 证书也需要钱，功能越强大的证书费用越高。
3. SSL 证书需要绑定 IP，不能再同一个 ip 上绑定多个域名，ipv4 资源支持不了这种消耗。

HTTP 支持的方法

• GET
• POST
• HEAD
• OPTIONS
• PUT
• DELETE
• TRACE
• CONNECT

Get和Post的区别

• get 参数通过 url 传递，post 放在 request body 中。
• get 请求在 url 中传递的参数是有长度限制的，而 post 没有。
• get 比 post 更不安全，因为参数直接暴露在 url 中，所以不能用来传递敏感信息。
• get 请求只能进行 url 编码，而 post 支持多种编码方式
• get会将数据缓存起来，而post不会
• get 请求参数会被完整保留在浏览历史记录里，而 post 中的参数不会被保留。
• GET 和 POST 本质上就是 TCP 链接，并无差别。但是由于 HTTP 的规定和浏览器/服务器 的限制，导致他们在应用过程中体现出一些不同。 GET 产生一个 TCP 数据包；POST 产生两个 TCP 数据包。

HTTP请求的方式_HEAD方式

head：类似于 get 请求，只不过返回的响应中没有具体的内容，用户获取报头 options：允许客户端查看服务器的性能，比如说服务器支持的请求方式等等。

HTTP2.0

简要概括：http2.0 是基于 1999 年发布的 http1.0 之后的首次更新

• 提升访问速度（可以对于，请求资源所需时间更少，访问速度更快，相比 http1.0）
• 允许多路复用：多路复用允许同时通过单一的 HTTP/2 连接发送多重请求-响应信息。
• 改善了：在 http1.1 中，浏览器客户端在同一时间，针对同一域名下的请求有一定数量限制（连接数量），超过限制会被阻塞。
• 二进制分帧：HTTP2.0 会将所有的传输信息分割为更小的信息或者帧，并对他们进行二进制编码首部压缩服务器端推送

HTTP常用请求头

HTTP返回码

1XX

2XX

3XX

4XX

5XX

对比 304 和 200

状态码 304：如果客户端发送了一个带条件的 GET 请求且该请求已被允许，而文档的 内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态 码。即客户端和服务器端只需要传输很少的数据量来做文件的校验，如果文件没有修改 过，则不需要返回全量的数据。

状态码 200：请求已成功，请求所希望的响应头或数据体将随此响应返回。即返回的数 据为全量的数据，如果文件不通过 GZIP 压缩的话，文件是多大，则要有多大传输量。

301和302的区别

• 301 Moved Permanently 被请求的资源已永久移动到新位置，并且将来任何对此资源的引 用都应该使用本响应返回的若干个 URI 之一。如果可能，拥有链接编辑功能的客户端应 当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定，否则这个响应也是可缓存的。
• 302 Found 请求的资源现在临时从不同的 URI 响应请求。由于这样的重定向是临时的， 客户端应当继续向原有地址发送以后的请求。只有在 Cache-Control 或 Expires 中进行了指定的情况下，这个响应才是可缓存的

字面上的区别就是 301 是永久重定向，而 302 是临时重定向。 301 比较常用的场景是使用域名跳转。302 用来做临时跳转 比如未登陆的用户访问用户 中心重定向到登录页面。

HTTP强缓存和协商缓存

缓存分为两种：强缓存和协商缓存（弱缓存），根据响应的 header 内容来决定

• 强缓存相关字段有 expires，cache-control。如果 cache-control 与 expires 同时存在的话， cache-control 的优先级高于 expires
• 协商缓存相关字段有 Last-Modified/If-Modified-Since，Etag/If-None-Match

强缓存、协商缓存什么时候用哪个

因为服务器上的资源不是一直固定不变的，大多数情况下它会更新，这个时候如果我们 还访问本地缓存，那么对用户来说，那就相当于资源没有更新，用户看到的还是旧的资 源；所以我们希望服务器上的资源更新了浏览器就请求新的资源，没有更新就使用本地 的缓存，以最大程度的减少因网络请求而产生的资源浪费。

浏览器缓存

浏览器缓存是浏览器在本地磁盘对用户最近请求过的文档进行存储，当访问者再次访问同一页面时，浏览器就可以直接从本地磁盘加载文档。

所以根据上面的特点，浏览器缓存有下面的优点：

1. 减少冗余的数据传输
2. 减少服务器负担
3. 加快客户端加载网页的速度

浏览器缓存是Web性能优化的重要方式。那么浏览器缓存的过程究竟是怎么样的呢？

在浏览器第一次发起请求时，本地无缓存，向web服务器发送请求，服务器起端响应请求，浏览器端缓存。过程如下：

在第一次请求时，服务器会将页面最后修改时间通过Last-Modified标识由服务器发送给客户端，客户端记录修改时间；服务器还会生成一个Etag，并发送给客户端。

浏览器后续再次进行请求时：

浏览器缓存主要分为强强缓存（也称本地缓存）和协商缓存（也称弱缓存）。根据上图，浏览器在第一次请求发生后，再次发送请求时：

• 浏览器请求某一资源时，会先获取该资源缓存的header信息，然后根据header中的Cache-Control和Expires来判断是否过期。若没过期则直接从缓存中获取资源信息，包括缓存的header的信息，所以此次请求不会与服务器进行通信。这里判断是否过期，则是强缓存相关。后面会讲Cache-Control和Expires相关。
• 如果显示已过期，浏览器会向服务器端发送请求，这个请求会携带第一次请求返回的有关缓存的header字段信息，比如客户端会通过If-None-Match头将先前服务器端发送过来的Etag发送给服务器，服务会对比这个客户端发过来的Etag是否与服务器的相同，若相同，就将If-None-Match的值设为false，返回状态304，客户端继续使用本地缓存，不解析服务器端发回来的数据，若不相同就将If-None-Match的值设为true，返回状态为200，客户端重新机械服务器端返回的数据；客户端还会通过If-Modified-Since头将先前服务器端发过来的最后修改时间戳发送给服务器，服务器端通过这个时间戳判断客户端的页面是否是最新的，如果不是最新的，则返回最新的内容，如果是最新的，则返回304，客户端继续使用本地缓存。

::: Tips 以下引用自思否 作者：puhongru 文章：HTTP强缓存和协商缓存 - JavaScript学习笔记 - SegmentFault 思否 :::

强缓存

强缓存是利用http头中的Expires和Cache-Control两个字段来控制的，用来表示资源的缓存时间。强缓存中，普通刷新会忽略它，但不会清除它，需要强制刷新。浏览器强制刷新，请求会带上Cache-Control:no-cache和Pragma:no-cache

Expires

Expires是http1.0的规范，它的值是一个绝对时间的GMT格式的时间字符串。如我现在这个网页的Expires值是：expires:Fri, 14 Apr 2017 10:47:02 GMT。这个时间代表这这个资源的失效时间，只要发送请求时间是在Expires之前，那么本地缓存始终有效，则在缓存中读取数据。所以这种方式有一个明显的缺点，由于失效的时间是一个绝对时间，所以当服务器与客户端时间偏差较大时，就会导致缓存混乱。如果同时出现Cache-Control:max-age和Expires，那么max-age优先级更高。如我主页的response headers部分如下：

那么表示资源可以被缓存的最长时间为691200秒，会优先考虑max-age。

Cache-Control

Cache-Control是在http1.1中出现的，主要是利用该字段的max-age值来进行判断，它是一个相对时间，例如Cache-Control:max-age=3600，代表着资源的有效期是3600秒。cache-control除了该字段外，还有下面几个比较常用的设置值：

• no-cache：不使用本地缓存。需要使用缓存协商，先与服务器确认返回的响应是否被更改，如果之前的响应中存在ETag，那么请求的时候会与服务端验证，如果资源未被更改，则可以避免重新下载。
• no-store：直接禁止游览器缓存数据，每次用户请求该资源，都会向服务器发送一个请求，每次都会下载完整的资源。
• public：可以被所有的用户缓存，包括终端用户和CDN等中间代理服务器。
• private：只能被终端用户的浏览器缓存，不允许CDN等中继缓存服务器对其缓存。 Cache-Control与Expires可以在服务端配置同时启用，同时启用的时候Cache-Control优先级高。

协商缓存

协商缓存就是由服务器来确定缓存资源是否可用，所以客户端与服务器端要通过某种标识来进行通信，从而让服务器判断请求资源是否可以缓存访问。

普通刷新会启用弱缓存，忽略强缓存。只有在地址栏或收藏夹输入网址、通过链接引用资源等情况下，浏览器才会启用强缓存，这也是为什么有时候我们更新一张图片、一个js文件，页面内容依然是旧的，但是直接浏览器访问那个图片或文件，看到的内容却是新的。

这个主要涉及到两组header字段：Etag和If-None-Match、Last-Modified和If-Modified-Since。上面以及说得很清楚这两组怎么使用啦~复习一下：

Etag和If-None-Match

Etag/If-None-Match返回的是一个校验码。ETag可以保证每一个资源是唯一的，资源变化都会导致ETag变化。服务器根据浏览器上送的If-None-Match值来判断是否命中缓存。

与Last-Modified不一样的是，当服务器返回304 Not Modified的响应时，由于ETag重新生成过，response header中还会把这个ETag返回，即使这个ETag跟之前的没有变化。

Last-Modify/If-Modify-Since

浏览器第一次请求一个资源的时候，服务器返回的header中会加上Last-Modify，Last-modify是一个时间标识该资源的最后修改时间，例如Last-Modify: Thu,31 Dec 2037 23:59:59 GMT。

当浏览器再次请求该资源时，request的请求头中会包含If-Modify-Since，该值为缓存之前返回的Last-Modify。服务器收到If-Modify-Since后，根据资源的最后修改时间判断是否命中缓存。

如果命中缓存，则返回304，并且不会返回资源内容，并且不会返回Last-Modify。

为什么要有Etag

你可能会觉得使用Last-Modified已经足以让浏览器知道本地的缓存副本是否足够新，为什么还需要Etag呢？HTTP1.1中Etag的出现主要是为了解决几个Last-Modified比较难解决的问题：

• 一些文件也许会周期性的更改，但是他的内容并不改变(仅仅改变的修改时间)，这个时候我们并不希望客户端认为这个文件被修改了，而重新GET；
• 某些文件修改非常频繁，比如在秒以下的时间内进行修改，(比方说1s内修改了N次)，If-Modified-Since能检查到的粒度是s级的，这种修改无法判断(或者说UNIX记录MTIME只能精确到秒)；
• 某些服务器不能精确的得到文件的最后修改时间。

Last-Modified与ETag是可以一起使用的，服务器会优先验证ETag，一致的情况下，才会继续比对Last-Modified，最后才决定是否返回304。

另外觉得一篇很好的文章，从缓存策略来学习HTTP缓存：HTTP基于缓存策略三要素分解法

TCP三次握手

TCP三次握手

客户端和服务端都需要直到各自可收发，因此需要三次握手。

从图片可以得到三次握手可以简化为：C 发起请求连接 | S 确认，发起连接 | C 确认

三次握手的作用

过程

1. 第一次握手：客户端主动链接服务器，发送初始序列号seq=x与SYN=1同步请求标志，并进入同步已发送SYN_SENT状态，等待服务器确认。
2. 第二次握手：服务端收到消息后发送确认标志ACK=1与同步请求标志SYN=1，发送自己的序列号seq=y以及客户端确认序号ack=x+1，此时服务器进入同步收到SYN_RECV状态。
3. 第三次握手：客户端收到消息后发送确认标志ACK=1，发送自己的序列号seq=x+1与服务器确认号ack=y+1，发送过后即确认链接已建立状态ESTABLISHED，服务端接收确认信息后进入链接已建立状态ESTABLISHED

解释

1. 第一次握手：客户端：“兄弟，待会咱们出去玩吧，能看到我的消息吗，能就吱一声，让我知道我有发消息的能力”
2. 第二次握手：服务端：“吱，走走走咱们去哪玩？我收到你的消息了，你有发消息的能力，要不你再给我回个消息，让我也确定我有发消息的能力”
3. 第三次握手：客户端：“咱们先去河里摸鱼玩，然后上山摘点果子。我也收到你的消息了，你这发消息的能力也没问题，咱俩的发消息的能力都没问题，可以愉快的玩耍了”

四次挥手

1. 第一次挥手：客户端发出释放标识FIN=1，自己的序列号seq=u，进入终止等待FIN-WAIT-1状态
2. 第二次挥手：服务端收到消息后发出ACK=1确认标志和客户端的确认号ack=u+1，自己的序列号seq=v，进入关闭等待CLOSE-WAIT状态，客户端收到消息后进入终止等待FIN-WAIT-2状态
3. 第三次挥手：服务器发送释放标识FIN=1信号，确认标志ACK=1，确认序号ack=u+1，自己的序列号seq=w，服务器进入最后确认LAST-ACK状态
4. 第四次挥手：客户端收到回复后，发送确认标志ACK=1，确认序号ack=w+1，自己的序列号seq=u+1，客户端进入时间等待TIME-WAIT状态，经过2个最长报文段寿命后，客户端CLOSE。服务器收到确认后，立刻进入CLOSE状态。

参考

TCP三次握手 (touchczy.top)

TCP和UDP的区别

1. TCP 是面向连接的，udp 是无连接的即发送数据前不需要先建立链接。
2. TCP 提供可靠的服务。也就是说，通过 TCP 连接传送的数据，无差错，不丢失， 不重复，且按序到达;UDP 尽最大努力交付，即不保证可靠交付。 并且因为 tcp 可靠， 面向连接，不会丢失数据因此适合大数据量的交换。
3. TCP 是面向字节流，UDP 面向报文，并且网络出现拥塞不会使得发送速率降低（因此会出现丢包，对实时的应用比如 IP 电话和视频会议等）。
4. TCP 只能是 1 对 1 的，UDP 支持 1 对 1,1 对多。
5. TCP 的首部较大为 20 字节，而 UDP 只有 8 字节。
6. TCP 是面向连接的可靠性传输，而 UDP 是不可靠的。

WebSocket的实现和应用

什么是WebSocket

WebSocket 是HTML5的协议，支持持久性连接，http 协议不支持持久性连接。Http1.0 和 HTTP1.1 都不支持持久性的链接，HTTP1.1 中的 keep-alive，将多个 http 请求合并为 1 个

WebSocket 是什么样的协议，具体有什么优点？

HTTP 的生命周期通过 Request 来界定，也就是 Request 一个 Response，那么在 Http1.0 协议中，这次 Http 请求就结束了。在 Http1.1 中进行了改进，是的有一个 connection： Keep-alive，也就是说，在一个 Http 连接中，可以发送多个 Request，接收多个 Response。 但是必须记住，在 Http 中一个 Request 只能对应有一个 Response，而且这个 Response 是被动的，不能主动发起。

WebSocket 是基于 Http 协议的，或者说借用了 Http 协议来完成一部分握手，在握手阶段 与 Http 是相同的。我们来看一个 websocket 握手协议的实现，基本是 2 个属性，upgrade， connection。

meta元信息处理

html头部中

Vue-Router中

• UI： User Interface 用户界面

• UID： User Interface Design 用户界面设计

• ID：Interaction design 交互设计

• UE or UX： User Experience 用户体验

• UED： User Experience Design 用户体验设计

UED优化

• 优化首屏加载
  • 骨架屏
  • SSR服务端渲染

1. 栈（操作系统）：由操作系统自动分配释放存放函数的参数值、局部变量的值等。其操作方式类似于数据结构中的栈（ 简单数据类型存放到栈里面 ）
2. 堆（操作系统）：存储复杂类型(对象)，一般由程序员分配释放，若程序员不释放，由垃圾回收机制回收（ 复杂数据类型存放到堆里面）

• 当异步函数获取 state 时，可能不是当前最新的 state
• 可使用 useRef 来解决
• （要提前了解JS 闭包）

深入原理

1. useState 产生的数据也是 Immutable 的，通过数组第二个参数 Set 一个新值后，原来的值会形成一个新的引用在下次渲染时。
2. 但由于对 state 的读取没有通过 this. 的方式，使得 每次 setTimeout 都读取了当时渲染闭包环境的数据，虽然最新的值跟着最新的渲染变了，但旧的渲染里，状态依然是旧值。

对比Class Component

首先对 Class Component 进行解释：

1. 首先 state 是 Immutable 的，setState 后一定会生成一个全新的 state 引用。
2. 但 Class Component 通过 this.state 方式读取 state，这导致了每次代码执行都会拿到最新的 state 引用，所以快速点击三次的结果是 3 3 3。

什么是构造函数

constructor 返回创建实例对象时构造函数的引用。此属性的值是对函数本身的引用，而不是一个包含函数名称的字符串。

原型

prototype

JavaScript 是一种基于原型的语言 (prototype-based language)，这个和 Java 等基于类的语言不一样。

每个对象拥有一个原型对象，对象以其原型为模板，从原型继承方法和属性，这些属性和方法定义在对象的构造器函数的 prototype 属性上，而非对象实例本身。

原型链

每个对象拥有一个原型对象，通过 __proto__ 指针指向上一个原型，并从中继承方法和属性，同时原型对象也可能拥有原型，这样一层一层，最终指向 null。这种关系被称为原型链 (prototype chain)，通过原型链一个对象会拥有定义在其他对象中的属性和方法。

场景：现在有一个Parent函数，它拥有prototype属性指向它的原型也就是Parent.prototype，Parent.prototype拥有constructor属性指向函数本身。我们通过new创建它的实例对象p，实例对象p拥有_proto_属性也就是对象的原型链，指向Parent的原型Parent.prototype。

JavaScript 有一个基于事件循环的并发模型，事件循环负责执行代码、收集和处理事件以及执行队列中的子任务。这个模型与其他语言中的模型截然不同，比如 C 和 Java。

运行时概念

接下来的内容解释了这个理论模型。现代 JavaScript 引擎实现并着重优化了以下描述的这些语义。

可视化描述

栈

函数调用形成了一个由若干帧组成的栈。

JSCopy to Clipboard

当调用 bar 时，第一个帧被创建并压入栈中，帧中包含了 bar 的参数和局部变量。当 bar 调用 foo 时，第二个帧被创建并被压入栈中，放在第一个帧之上，帧中包含 foo 的参数和局部变量。当 foo 执行完毕然后返回时，第二个帧就被弹出栈（剩下 bar 函数的调用帧）。当 bar 也执行完毕然后返回时，第一个帧也被弹出，栈就被清空了。

堆

对象被分配在堆中，堆是一个用来表示一大块（通常是非结构化的）内存区域的计算机术语。

队列

一个 JavaScript 运行时包含了一个待处理消息的消息队列。每一个消息都关联着一个用以处理这个消息的回调函数。

在 事件循环 期间的某个时刻，运行时会从最先进入队列的消息开始处理队列中的消息。被处理的消息会被移出队列，并作为输入参数来调用与之关联的函数。正如前面所提到的，调用一个函数总是会为其创造一个新的栈帧。

函数的处理会一直进行到执行栈再次为空为止；然后事件循环将会处理队列中的下一个消息（如果还有的话）。

事件循环

之所以称之为 事件循环，是因为它经常按照类似如下的方式来被实现：

JSCopy to Clipboard

queue.waitForMessage() 会同步地等待消息到达 (如果当前没有任何消息等待被处理)。

"执行至完成"

每一个消息完整地执行后，其他消息才会被执行。这为程序的分析提供了一些优秀的特性，包括：当一个函数执行时，它不会被抢占，只有在它运行完毕之后才会去运行任何其他的代码，才能修改这个函数操作的数据。这与 C 语言不同，例如，如果函数在线程中运行，它可能在任何位置被终止，然后在另一个线程中运行其他代码。

这个模型的一个缺点在于当一个消息需要太长时间才能处理完毕时，Web 应用程序就无法处理与用户的交互，例如点击或滚动。为了缓解这个问题，浏览器一般会弹出一个“这个脚本运行时间过长”的对话框。一个良好的习惯是缩短单个消息处理时间，并在可能的情况下将一个消息裁剪成多个消息。

添加消息

在浏览器里，每当一个事件发生并且有一个事件监听器绑定在该事件上时，一个消息就会被添加进消息队列。如果没有事件监听器，这个事件将会丢失。所以当一个带有点击事件处理器的元素被点击时，就会像其他事件一样产生一个类似的消息。

函数 setTimeout 接受两个参数：待加入队列的消息和一个时间值（可选，默认为 0）。这个时间值代表了消息被实际加入到队列的最小延迟时间。如果队列中没有其他消息并且栈为空，在这段延迟时间过去之后，消息会被马上处理。但是，如果有其他消息，setTimeout 消息必须等待其他消息处理完。因此第二个参数仅仅表示最少延迟时间，而非确切的等待时间。

下面的例子演示了这个概念（setTimeout 并不会在计时器到期之后直接执行）：

JSCopy to Clipboard

零延迟

零延迟并不意味着回调会立即执行。以 0 为第二参数调用 setTimeout 并不表示在 0 毫秒后就立即调用回调函数。

其等待的时间取决于队列里待处理的消息数量。在下面的例子中，"这是一条消息" 将会在回调获得处理之前输出到控制台，这是因为延迟参数是运行时处理请求所需的最小等待时间，但并不保证是准确的等待时间。

基本上，setTimeout 需要等待当前队列中所有的消息都处理完毕之后才能执行，即使已经超出了由第二参数所指定的时间。

JSCopy to Clipboard

多个运行时互相通信

一个 web worker 或者一个跨域的 iframe 都有自己的栈、堆和消息队列。两个不同的运行时只能通过 postMessage 方法进行通信。如果另一个运行时侦听 message 事件，则此方法会向该运行时添加消息。

永不阻塞

JavaScript 的事件循环模型与许多其他语言不同的一个非常有趣的特性是，它永不阻塞。处理 I/O 通常通过事件和回调来执行，所以当一个应用正等待一个 IndexedDB 查询返回或者一个 XHR 请求返回时，它仍然可以处理其他事情，比如用户输入。

由于历史原因有一些例外，如 alert 或者同步 XHR，但应该尽量避免使用它们。注意，例外的例外也是存在的（但通常是实现错误而非其他原因）。

【数据类型】

基本类型：String、Number、Boolean、Null、Undefined、Symbol、BigInt

引用类型：Object、Array

【区别】

①基本类型存储在栈中，空间小，操作频繁。

②引用类型存储在堆中，空间大，在栈中存储了指针，指向在堆中的起始地址

③Symbol唯一性，不可枚举，使用getOwnPropertySymbols获取==

④BigInt也是ES6新出的一种数据类型，这种数据类型的特点就是数据涵盖的范围大，能够解决超出普通数据类型范围报错的问题。（注意：BigInt和Number之间不能进行混合操作）

1. src 这个属性定义引用外部脚本的 URI，这可以用来代替直接在文档中嵌入脚本。指定了 src 属性的 script 元素标签内不应该再有嵌入的脚本。
2. type 该属性定义 script 元素包含或src引用的脚本语言。
3. text 和 textContent 属性类似，本属性用于设置元素的文本内容。
4. defer 这个布尔属性被设定用来通知浏览器该脚本将在文档完成解析后，触发 DOMContentLoaded事件前执行。
   1. 警告： 如果缺少 src 属性（即内嵌脚本），该属性不应被使用，因为这种情况下它不起作用。defer 属性对模块脚本没有作用 —— 他们默认 defer。
5. async
   1. 对于普通脚本，如果存在 async 属性，那么普通脚本会被并行请求，并尽快解析和执行。
   2. 对于模块脚本，如果存在 async 属性，那么脚本及其所有依赖都会在延缓队列中执行，因此它们会被并行请求，并尽快解析和执行。
   3. 该属性能够消除解析阻塞的 Javascript。解析阻塞的 Javascript 会导致浏览器必须加载并且执行脚本，之后才能继续解析。defer 在这一点上也有类似的作用。
6. crossorigin 那些没有通过标准CORS (en-US)检查的正常script 元素传递最少的信息到 window.onerror。可以使用本属性来使那些将静态资源放在另外一个域名的站点打印错误信息。

原生方法实现深拷贝，主要是使用JSON.parse()与JSON.stringify()，首先将对象序列化为JSON字符串，再将JSON字符串反序列化为对象，使用这种方式效率比较高，但是会有一些问题，对于循环引用的对象无法实现深拷贝，对于被拷贝的对象，如果对象中有属性为Date对象，此种方式深拷贝会将时间对象转化为字符串；如果对象中有属性为RegExp对象、Error对象，此种方式深拷贝会得到一个空对象；如果对象中有属性为function对象、undefined、Symbol值，此种方式深拷贝会忽略这些值；如果对象中有属性为NaN、Infinity、-Infinity，此种方式深拷贝会将结果转为null。

interface和type的区别

大家使用 typescript 总会使用到 interface 和 type，官方规范 稍微说了下两者的区别

• An interface can be named in an extends or implements clause, but a type alias for an object type literal cannot.
• An interface can have multiple merged declarations, but a type alias for an object type literal cannot. 但是没有太具体的例子。

明人不说暗话，直接上区别。

相同点

都可以描述一个对象或者函数

interface

type

拓展（extends）与 交叉类型（Intersection Types）

interface 可以 extends， 但 type 是不允许 extends 和 implement 的，但是 type 缺可以通过交叉类型 实现 interface 的 extend 行为，并且两者并不是相互独立的，也就是说 interface 可以 extends type, type 也可以 与 interface 类型 交叉 。

虽然效果差不多，但是两者语法不同。

interface extends interface

type 与 type 交叉

interface extends type

type 与 interface 交叉

不同点

type 可以而 interface 不行

• type 可以声明基本类型别名，联合类型，元组等类型

• type 语句中还可以使用 typeof 获取实例的 类型进行赋值

• 其他骚操作

interface 可以而 type 不行

interface 能够声明合并

总结

一般来说，如果不清楚什么时候用interface/type，能用 interface 实现，就用 interface , 如果不能就用 type 。其他更多详情参看 官方规范文档

特点

• 会触发页面更新，重新渲染，触发state更新

• state是异步更新，state更新可能会被合并，使用函数state更新不会被合并

• 不可变数据（重要！！！）- 不去修改 state的值，而是传入一个新的值

如果说 一个变量 不用于 JSX 中显示，那就不要用 setState 来管理它，用useRef

state增删查改

数组

增

• concat

删

• filter

查

• filter

改

• map

状态提升：数据源在父组件中，子组件只需要负责展示。操作、数据由父组件实现、传递，子组件调用、渲染

immer

Immer 简化了不可变数据结构的处理。特别是对于 JS 语法没那么熟悉的人。

useEffect

useEffect执行两次

• React 18开始, useEffect在==开发环境==下会执行两次

• 模拟组件创建、销毁、再创建的完整流程,及早暴露问题

• 生产环境下会执行一次

• 当组件渲染完成时,加载一个Ajax网络请求

• 当某个state更新时,加载一个Ajax网络请求使用

• useEffect 实现

其他内置Hooks

useRef

• 一般用于操作DOM
• 也可传入普通JS变量,但更新不会触发 rerender
• 要和Vue3 ref区分开(如果你用过Vue3)

useMemo

• 函数组件，每次state更新都会重新执行函数
• useMemo 可以缓存数据，不用每次执行函数都重新生成
• 可用于计算量较大的场景，缓存提高性能

useCallback

• 和 useMemo 作用一样
• 专门用于缓存函数

【diff算法的理解】

diff算法用来计算出Virtual DOM中改变的部分，然后针对该部分进行DOM操作，而不用重新渲染整个页面，渲染整个DOM结构的过程中开销是很大的，需要浏览器对DOM结构进行重绘与回流，而diff算法能够使得操作过程中只更新修改的那部分DOM结构而不更新整个DOM，这样能够最小化操作DOM结构，能够最大程度上减少浏览器重绘与回流的规模。

【原理】

diff算法：当数据发生改变时，set方法让调用Dep.notify通知所有订阅者Watcher数据发生更新，订阅者就会调用patch进行比较，然后将相应的部分渲染到真实DOM结构。

虚拟DOM：diff算法的基础是Virtual DOM，Virtual DOM是一棵以JavaScript对象作为基础的树，每一个节点称为VNode，用对象属性来描述节点，实际上它是一层对真实DOM的抽象，最终可以通过渲染操作使这棵树映射到真实环境上，简单来说Virtual DOM就是一个Js对象，用以描述整个文档。 在浏览器中构建页面时需要使用DOM节点描述整个文档。

【修改原则】

vue优化优化时间复杂度O(n)是通过一定策略进行的，React中提到了两个假设，在Vue中同样适用：

• 两个不同类型的元素将产生不同的树。
• 通过渲染器附带key属性，开发者可以示意哪些子元素可能是稳定的。

通俗点说就是：

• 只进行统一层级的比较，如果跨层级的移动则视为创建和删除操作。
• 如果是不同类型的元素，则认为是创建了新的元素，而不会递归比较他们的孩子。
• 如果是列表元素等比较相似的内容，可以通过key来唯一确定是移动还是创建或删除操作。

比较后会出现几种情况，然后进行相应的操作：

• 此节点被添加或移除->添加或移除新的节点。
• 属性被改变->旧属性改为新属性。
• 文本内容被改变->旧内容改为新内容。
• 节点tag或key是否改变->改变则移除后创建新元素。

文章转自 https://github.com/ascoders/weekly/blob/master/%E5%89%8D%E6%B2%BF%E6%8A%80%E6%9C%AF/109.%E7%B2%BE%E8%AF%BB%E3%80%8AVue3.0%20Function%20API%E3%80%8B.md

1. 引言

Vue 3.0 的发布引起了轩然大波，让我们解读下它的 function api RFC 详细了解一下 Vue 团队是怎么想的吧！

首先官方回答了几个最受关注的问题：

Vue 3.0 是否有 break change，就像 Python 3 / Angular 2 一样？

不，100% 兼容 Vue 2.0，且暂未打算废弃任何 API（未来也不）。之前有草案试图这么做，但由于用户反馈太猛，被撤回了。

Vue 3.0 的设计盖棺定论了吗？

没有呀，这次精读的稿子就是 RFC（Request For Comments），翻译成中文就是 “意见征求稿”，还在征求大家意见中哦。

这 RFC 咋这么复杂？

RFC 是写给贡献者/维护者的，要考虑许多边界情况与细节，所以当然会复杂很多喽！当然 Vue 本身使用起来还是很简单的。

Vue 本身 Mutable + Template 就注定了是个用起来简单（约定 + 自然），实现起来复杂（解析 + 双绑）的框架。

这次改动很像在模仿 React，为啥不直接用 React？

首先 Template 机制还是没变，其次模仿的是 Hooks 而不是 React 全部，如果你不喜欢这个改动，那你更不会喜欢用 React。

PS: 问这个问题的人，一定没有同时理解 React 与 Vue，其实这两个框架到现在差别蛮大的，后面精读会详细说明。

下面正式进入 Vue 3.0 Function API 的介绍。

2. 概述

Vue 函数式基本 Demo：

函数式风格的入口是 setup 函数，采用了函数式风格后可以享受如下好处：类型自动推导、减少打包体积。

setup 函数返回值就是注入到页面模版的变量。我们也可以返回一个函数，通过使用 value 这个 API 产生属性并修改：

要注意的是，value() 返回的是一个对象，通过 .value 才能访问到其真实值。

为何 value() 返回的是 Wrappers 而非具体值呢？原因是 Vue 采用双向绑定，只有对象形式访问值才能保证访问到的是最终值，这一点类似 React 的 useRef() API 的 .current 规则。

那既然所有 value() 返回的值都是 Wrapper，那直接给模版使用时要不要调用 .value 呢？答案是否定的，直接使用即可，模版会自动 Unwrapping:

接下来是 Hooks，下面是一个使用 Hooks 实现获得鼠标实时位置的例子：

可以看到，useMouse 将所有与 “处理鼠标位置” 相关的逻辑都封装了进去，乍一看与 React Hooks 很像，但是有两个区别：

1. useMouse 函数内改变 x、y 后，不会重新触发 setup 执行。
2. x y 拿到的都是 Wrapper 而不是原始值，且这个值会动态变化。

另一个重要 API 就是 watch，它的作用类似 React Hooks 的 useEffect，但实现原理和调用时机其实完全不一样。

watch 的目的是监听某些变量变化后执行逻辑，比如当 id 变化后重新取数：

之所以要 watch，因为在 Vue 中，setup 函数仅执行一次，所以不像 React Function Component，每次组件 props 变化都会重新执行，因此无论是在变量、props 变化时如果想做一些事情，都需要包裹在 watch 中。

后面还有 unwatching、生命周期函数、依赖注入，都是一些语法定义，感兴趣可以继续阅读原文，笔者就不赘述了。

3. 精读

对于 Vue 3.0 的 Function API + Hooks 与 React Function Component + Hooks，笔者做一些对比。

Vue 与 React 逻辑结构

React Function Component 与 Hooks，虽然在实现原理上，与 Vue3.0 存在 Immutable 与 Mutable、JSX 与 Template 的区别，但逻辑理解上有着相通之处。

虽然在 Vue 中，setup 函数仅执行一次，看上去与 React 函数完全不一样（React 函数每次都执行），但其实 Vue 将渲染层（Template）与数据层（setup）分开了，而 React 合在了一起。

我们可以利用 React Hooks 将数据层与渲染层完全隔离：

这源于 JSX 与 Template 的根本区别。JSX 使模版与 JS 可以写在一起，因此数据层与渲染层可以耦合在一起写（也可以拆分），但 Vue 采取的 Template 思路使数据层强制分离了，这也使代码分层更清晰了。

而实际上 Vue3.0 的 setup 函数也是可选的，再配合其支持的 TSX 功能，与 React 真的只有 Mutable 的区别了：

我们很难评价 Template 与 JSX 的好坏，但为了更透彻的理解 Vue 与 React，需要抛开 JSX&Template，Mutable&Immutable 去看，其实去掉这两个框架无关的技术选型，React@16 与 Vue@3 已经非常像了。

Vue3.0 的精髓是学习了 React Hooks 概念，因此正好可以用 Hooks 在 React 中模拟 Vue 的 setup 函数。

关于这两套技术选型，已经是相对完美的组合，不建议在 JSX 中再实现类似 Mutable + JSX 的花样来（因为喜欢 Mutable 可以用 Vue 呀）：

• Vue：Mutable + Template
• React：Immutable + JSX

真正影响编码习惯的就是 Mutable 与 Immutable，使用 Vue 就坚定使用 Mutable，使用 React 就坚定使用 Immutable，这样能最大程度发挥两套框架的价值。

Vue Hooks 与 React Hooks 的差异

先看 React Hooks 的简单语法：

Vue Hooks 的简单语法：

之所以 React 返回的 count 是一个数字，是因为 Immutable 规则，而 Vue 返回的 count 是个对象，拥有 count.value 属性，也是因为 Vue Mutable 规则导致，这使得 Vue 定义的所有变量都类似 React 中 useRef 定义变量，因此不存 React capture value 的特性。

关于 capture value 更多信息，可以阅读 精读《Function VS Class 组件》 Capute Value 介绍

另外，对于 Hooks 的值变更机制也不同，我们看 Vue 的代码：

由于 setup 函数仅执行一次，怎么做到当 useMouse 导致 x、y 值变化时，可以在 setup 中拿到最新的值？

在 React 中，useMouse 如果修改了 x 的值，那么使用 useMouse 的函数就会被重新执行，以此拿到最新的 x，而在 Vue 中，将 Hooks 与 Mutable 深度结合，通过包装 x.value，使得当 x 变更时，引用保持不变，仅值发生了变化。所以 Vue 利用 Proxy 监听机制，可以做到 setup 函数不重新执行，但 Template 重新渲染的效果。

这就是 Mutable 的好处，Vue Hooks 中，不需要 useMemo useCallback useRef 等机制，仅需一个 value 函数，直观的 Mutable 修改，就可以实现 React 中一套 Immutable 性能优化后的效果，这个是 Mutable 的魅力所在。

Vue Hooks 的优势

笔者对 RFC 中对 Vue、React Hooks 的对比做一个延展解释：

首先最大的不同：setup 仅执行一遍，而 React Function Component 每次渲染都会执行。

Vue 的代码使用更符合 JS 直觉。

这句话直截了当戳中了 JS 软肋，JS 并非是针对 Immutable 设计的语言，所以 Mutable 写法非常自然，而 Immutable 的写法就比较别扭。

当 Hooks 要更新值时，Vue 只要用等于号赋值即可，而 React Hooks 需要调用赋值函数，当对象类型复杂时，还需借助第三方库才能保证进行了正确的 Immutable 更新。

对 Hooks 使用顺序无要求，而且可以放在条件语句里。

对 React Hooks 而言，调用必须放在最前面，而且不能被包含在条件语句里，这是因为 React Hooks 采用下标方式寻找状态，一旦位置不对或者 Hooks 放在了条件中，就无法正确找到对应位置的值。

而 Vue Function API 中的 Hooks 可以放在任意位置、任意命名、被条件语句任意包裹的，因为其并不会触发 setup 的更新，只在需要的时候更新自己的引用值即可，而 Template 的重渲染则完全继承 Vue 2.0 的依赖收集机制，它不管值来自哪里，只要用到的值变了，就可以重新渲染了。

不会再每次渲染重复调用，减少 GC 压力。

这确实是 React Hooks 的一个问题，所有 Hooks 都在渲染闭包中执行，每次重渲染都有一定性能压力，而且频繁的渲染会带来许多闭包，虽然可以依赖 GC 机制回收，但会给 GC 带来不小的压力。

而 Vue Hooks 只有一个引用，所以存储的内容就非常精简，也就是占用内存小，而且当值变化时，也不会重新触发 setup 的执行，所以确实不会造成 GC 压力。

必须要总包裹 useCallback 函数确保不让子元素频繁重渲染。

React Hooks 有一个问题，就是完全依赖 Immutable 属性。而在 Function Component 内部创建函数时，每次都会创建一个全新的对象，这个对象如果传给子组件，必然导致子组件无法做性能优化。 因此 React 采取了 useCallback 作为优化方案：

只有当第二个依赖参数变化时才返回新引用。但第二个依赖参数需要 lint 工具确保依赖总是正确的（关于为何要对依赖诚实，感兴趣可以移步 精读《Function Component 入门》 - 永远对依赖诚实）。

回到 Vue 3.0，由于 setup 仅执行一次，因此函数本身只会创建一次，不存在多实例问题，不需要 useCallback 的概念，更不需要使用 lint 插件 保证依赖书写正确，这对开发者是实实在在的友好。

不需要使用 useEffect useMemo 等进行性能优化，所有性能优化都是自动的。

这也是实在话，毕竟 Mutable + 依赖自动收集就可以做到最小粒度的精确更新，根本不会触发不必要的 Rerender，因此 useMemo 这个概念也不需要了。

而 useEffect 也需要传递第二个参数 “依赖项”，在 Vue 中根本不需要传递 “依赖项”，所以也不会存在用户不小心传错的问题，更不需要像 React 写一个 lint 插件保证依赖的正确性。（这也是笔者想对 React Hooks 吐槽的点，React 团队如何保障每个人都安装了 lint？就算装了 lint，如果 IDE 有 BUG，导致没有生效，随时可能写出依赖不正确的 “危险代码”，造成比如死循环等严重后果）

4. 总结

通过对比 Vue Hooks 与 React Hooks 可以发现，Vue 3.0 将 Mutable 特性完美与 Hooks 结合，规避了一些 React Hooks 的硬伤。所以我们可以说 Vue 借鉴了 React Hooks 的思想，但创造出来的确实一个更精美的艺术品。

但 React Hooks 遵循的 Immutable 也有好的一面，就是每次渲染中状态被稳定的固化下来了，不用担心状态突然变更带来的影响（其实反而要注意状态用不变更带来的影响），对于数据记录、程序运行的稳定性都有较高的可预期性。

最后，对于喜欢 Mutable 的开发者，Vue 3.0 是你的最佳选择，基于 React + Mutable 搞的一些小轮子做到顶级可能还不如 Vue 3.0。对于 React 开发者来说，坚持你们的 Immutable 信仰吧，Vue 3.0 已经将 Mutable 发挥到极致，只有将 React Immutable 特性发挥到极致才能发挥 React 的最大价值。

讨论地址是：精读《Vue3.0 Function API》 · Issue #173 · dt-fe/weekly

如果你想参与讨论，请 点击这里，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。

关注 前端精读微信公众号

版权声明：自由转载-非商用-非衍生-保持署名（创意共享 3.0 许可证）

1. 事件循环
   1. 宏任务微任务
   2. 等待虚拟dom渲染完成

本文引自https://github.com/ascoders/weekly/blob/master/%E5%89%8D%E6%B2%BF%E6%8A%80%E6%9C%AF/104.%E7%B2%BE%E8%AF%BB%E3%80%8AFunction%20Component%20%E5%85%A5%E9%97%A8%E3%80%8B.md

1. 引言

如果你在使用 React 16，可以尝试 Function Component 风格，享受更大的灵活性。但在尝试之前，最好先阅读本文，对 Function Component 的思维模式有一个初步认识，防止因思维模式不同步造成的困扰。

2. 精读

什么是 Function Component？

Function Component 就是以 Function 的形式创建的 React 组件：

也就是，一个返回了 JSX 或 createElement 的 Function 就可以当作 React 组件，这种形式的组件就是 Function Component。

所以我已经学会 Function Component 了吗？

别急，故事才刚刚开始。

什么是 Hooks？

Hooks 是辅助 Function Component 的工具。比如 useState 就是一种 Hook，它可以用来管理状态：

useState 返回的结果是数组，数组的第一项是 值，第二项是 赋值函数，useState 函数的第一个参数就是 默认值，也支持回调函数。更详细的介绍可以参考 Hooks 规则解读。

先赋值再 setTimeout 打印

我们再将 useState 与 setTimeout 结合使用，看看有什么发现。

创建一个按钮，点击后让计数器自增，但是延时 3 秒后再打印出来：

如果我们 在三秒内连续点击三次，那么 count 的值最终会变成 3，而随之而来的输出结果是。。？

嗯，好像对，但总觉得有点怪？

使用 Class Component 方式实现一遍呢？

敲黑板了，回到我们熟悉的 Class Component 模式，实现一遍上面的功能：

嗯，结果应该等价吧？3 秒内快速点击三次按钮，这次的结果是：

怎么和 Function Component 结果不一样？

这是用好 Function Component 必须迈过的第一道坎，请确认完全理解下面这段话：

首先对 Class Component 进行解释：

1. 首先 state 是 Immutable 的，setState 后一定会生成一个全新的 state 引用。
2. 但 Class Component 通过 this.state 方式读取 state，这导致了每次代码执行都会拿到最新的 state 引用，所以快速点击三次的结果是 3 3 3。

那么对 Function Component 而言：

1. useState 产生的数据也是 Immutable 的，通过数组第二个参数 Set 一个新值后，原来的值会形成一个新的引用在下次渲染时。
2. 但由于对 state 的读取没有通过 this. 的方式，使得 每次 setTimeout 都读取了当时渲染闭包环境的数据，虽然最新的值跟着最新的渲染变了，但旧的渲染里，状态依然是旧值。

为了更容易理解，我们来模拟三次 Function Component 模式下点击按钮时的状态：

第一次点击，共渲染了 2 次，setTimeout 生效在第 1 次渲染，此时状态为：

第二次点击，共渲染了 3 次，setTimeout 生效在第 2 次渲染，此时状态为：

第三次点击，共渲染了 4 次，setTimeout 生效在第 3 次渲染，此时状态为：

可以看到，每一个渲染都是一个独立的闭包，在独立的三次渲染中，count 在每次渲染中的值分别是 0 1 2，所以无论 setTimeout 延时多久，打印出来的结果永远是 0 1 2。

理解了这一点，我们就能继续了。

如何让 Function Component 也打印 3 3 3？

所以这是不是代表 Function Component 无法覆盖 Class Component 的功能呢？完全不是，我希望你读完本文后，不仅能解决这个问题，更能理解为什么用 Function Component 实现的代码更佳合理、优雅。

第一种方案是借助一个新 Hook - useRef 的能力：

这种方案的打印结果就是 3 3 3。

想要理解为什么，首先要理解 useRef 的功能：通过 useRef 创建的对象，其值只有一份，而且在所有 Rerender 之间共享。

所以我们对 count.current 赋值或读取，读到的永远是其最新值，而与渲染闭包无关，因此如果快速点击三下，必定会返回 3 3 3 的结果。

但这种方案有个问题，就是使用 useRef 替代了 useState 创建值，那么很自然的问题就是，如何不改变原始值的写法，达到同样的效果呢？

如何不改造原始值也打印 3 3 3？

一种最简单的做法，就是新建一个 useRef 的值给 setTimeout 使用，而程序其余部分还是用原始的 count:

通过这个例子，我们引出了一个新的，也是 最重要的 Hook - useEffect，请务必深入理解这个函数。

useEffect 是处理副作用的，其执行时机在 每次 Render 渲染完毕后，换句话说就是每次渲染都会执行，只是实际在真实 DOM 操作完毕后。

我们可以利用这个特性，在每次渲染完毕后，将 count 此时最新的值赋给 currentCount.current，这样就使 currentCount 的值自动同步了 count 的最新值。

为了确保大家准确理解 useEffect，笔者再啰嗦一下，将其执行周期拆解到每次渲染中。假设你在三秒内快速点击了三次按钮，那么你需要在大脑中模拟出下面这三次渲染都发生了什么：

第一次点击，共渲染了 2 次，useEffect 生效在第 2 次渲染：

第二次点击，共渲染了 3 次，useEffect 生效在第 3 次渲染：

第三次点击，共渲染了 4 次，useEffect 生效在第 4 次渲染：

注意对比与上面章节展开的 setTimeout 渲染时有什么不同。

要注意的是，useEffect 也随着每次渲染而不同的，同一个组件不同渲染之间，useEffect 内闭包环境完全独立。对于本次的例子，useEffect 共执行了 四次，经历了如下四次赋值最终变成 3:

请确保理解了这句话再继续往下阅读：

• setTimeout 的例子，三次点击触发了四次渲染，但 setTimeout 分别生效在第 1、2、3 次渲染中，因此值是 0 1 2。
• useEffect 的例子中，三次点击也触发了四次渲染，但 useEffect 分别生效在第 1、2、3、4 次渲染中，最终使 currentCount 的值变成 3。

用自定义 Hook 包装 useRef

是不是觉得每次都写一堆 useEffect 同步数据到 useRef 很烦？是的，想要简化，就需要引出一个新的概念：自定义 Hooks。

首先介绍一下，自定义 Hooks 允许创建自定义 Hook，只要函数名遵循以 use 开头，且返回非 JSX 元素，就是 Hooks 啦！自定义 Hooks 内还可以调用包括内置 Hooks 在内的所有自定义 Hooks。

也就是我们可以将 useEffect 写到自定义 Hook 里：

这里又引出一个新的概念，就是 useEffect 的第二个参数，dependences。dependences 这个参数定义了 useEffect 的依赖，在新的渲染中，只要所有依赖项的引用都不发生变化，useEffect 就不会被执行，且当依赖项为 [] 时，useEffect 仅在初始化执行一次，后续的 Rerender 永远也不会被执行。

这个例子中，我们告诉 React：仅当 value 的值变化了，再将其最新值同步给 ref.current。

那么这个自定义 Hook 就可以在任何 Function Component 调用了：

封装以后代码清爽了很多，而且最重要的是将逻辑封装起来，我们只要理解 useCurrentValue 这个 Hook 可以产生一个值，其最新值永远与入参同步。

看到这里，也许有的小伙伴已经按捺不住迸发的灵感了：将 useEffect 第二个参数设置为空数组，这个自定义 Hook 就代表了 didMount 生命周期！

是的，但笔者建议大家 不要再想生命周期的事情，这样会阻碍你更好的理解 Function Component。因为下一个话题，就是要告诉你：永远要对 useEffect 的依赖诚实，被依赖的参数一定要填上去，否则会产生非常难以察觉与修复的 BUG。

将 setTimeout 换成 setInterval 会怎样

我们回到起点，将第一个 setTimeout Demo 中换成 setInterval，看看会如何：

这个例子将引发学习 Function Component 的第二个拦路虎，理解了它，才深入理解了 Function Component 的渲染原理。

首先介绍一下引入的新概念，useEffect 函数的返回值。它的返回值是一个函数，这个函数在 useEffect 即将重新执行时，会先执行上一次 Rerender useEffect 第一个回调的返回函数，再执行下一次渲染的 useEffect 第一个回调。

以两次连续渲染为例介绍，展开后的效果是这样的：

第一次渲染：

第二次渲染：

然而本 Demo 将 useEffect 的第二个参数设置为了 []，那么其返回函数只会在这个组件被销毁时执行。

读懂了前面的例子，应该能想到，这个 Demo 希望利用 [] 依赖，将 useEffect 当作 didMount 使用，再结合 setInterval 每次时 count 自增，这样期望将 count 的值每秒自增 1。

然而结果是：

理解了 setTimeout 例子的读者应该可以自行推导出原因：setInterval 永远在第一次 Render 的闭包中，count 的值永远是 0，也就是等价于：

然而罪魁祸首就是 没有对依赖诚实 导致的。例子中 useEffect 明明依赖了 count，依赖项却非要写 []，所以产生了很难理解的错误。

所以改正的办法就是 对依赖诚实。

永远对依赖项诚实

一旦我们对依赖诚实了，就可以得到正确的效果：

我们将 count 作为了 useEffect 的依赖项，就得到了正确的结果：

既然漏写依赖的风险这么大，自然也有保护措施，那就是 eslint-plugin-react-hooks 这个插件，会自动订正你的代码中的依赖，想不对依赖诚实都不行！

然而对这个例子而言，代码依然存在 BUG：每次计数器都会重新实例化，如果换成其他费事操作，性能成本将不可接受。

如何不在每次渲染时重新实例化 setInterval?

最简单的办法，就是利用 useState 的第二种赋值用法，不直接依赖 count，而是以函数回调方式进行赋值：

这这写法真正做到了：

1. 不依赖 count，所以对依赖诚实。
2. 依赖项为 []，只有初始化会对 setInterval 进行实例化。

而之所以输出还是正确的 1 2 3 ...，原因是 setCount 的回调函数中，c 值永远指向最新的 count 值，因此没有逻辑漏洞。

但是聪明的同学仔细一想，就会发现一个新问题：如果存在两个以上变量需要使用时，这招就没有用武之地了。

同时使用两个以上变量时？

如果同时需要对 count 与 step 两个变量做累加，那 useEffect 的依赖必然要写上一种某一个值，频繁实例化的问题就又出现了：

这个例子中，由于 setCount 只能拿到最新的 count 值，而为了每次都拿到最新的 step 值，就必须将 step 申明到 useEffect 依赖中，导致 setInterval 被频繁实例化。

这个问题自然也困扰了 React 团队，所以他们拿出了一个新的 Hook 解决问题：useReducer。

什么是 useReducer

先别联想到 Redux。只考虑上面的场景，看看为什么 React 团队要将 useReducer 列为内置 Hooks 之一。

先介绍一下 useReducer 的用法:

useReducer 返回的结构与 useState 很像，只是数组第二项是 dispatch，而接收的参数也有两个，初始值放在第二位，第一位就是 reducer。

reducer 定义了如何对数据进行变换，比如一个简单的 reducer 如下：

这样就可以通过调用 dispatch({ type: 'increment' }) 的方式实现 count 自增了。

那么回到这个例子，我们只需要稍微改写一下用法即可：

可以看到，我们通过 reducer 的 tick 类型完成了对 count 的累加，而在 useEffect 的函数中，竟然完全绕过了 count、step 这两个变量。所以 useReducer 也被称为解决此类问题的 “黑魔法”。

其实不管被怎么称呼也好，其本质是让函数与数据解耦，函数只管发出指令，而不需要关心使用的数据被更新时，需要重新初始化自身。

仔细的读者会发现这个例子还是有一个依赖的，那就是 dispatch，然而 dispatch 引用永远也不会变，因此可以忽略它的影响。这也体现了无论如何都要对依赖保持诚实。

这也引发了另一个注意项：尽量将函数写在 useEffect 内部。

将函数写在 useEffect 内部

为了避免遗漏依赖，必须将函数写在 useEffect 内部，这样 eslint-plugin-react-hooks 才能通过静态分析补齐依赖项：

getFetchUrl 这个函数依赖了 count，而如果将这个函数定义在 useEffect 外部，无论是机器还是人眼都难以看出 useEffect 的依赖项包含 count。

然而这就引发了一个新问题：将所有函数都写在 useEffect 内部岂不是非常难以维护？

如何将函数抽到 useEffect 外部？

为了解决这个问题，我们要引入一个新的 Hook：useCallback，它就是解决将函数抽到 useEffect 外部的问题。

我们先看 useCallback 的用法：

可以看到，useCallback 也有第二个参数 - 依赖项，我们将 getFetchUrl 函数的依赖项通过 useCallback 打包到新的 getFetchUrl 函数中，那么 useEffect 就只需要依赖 getFetchUrl 这个函数，就实现了对 count 的间接依赖。

换句话说，我们利用了 useCallback 将 getFetchUrl 函数抽到了 useEffect 外部。

为什么 useCallback 比 componentDidUpdate 更好用

回忆一下 Class Component 的模式，我们是如何在函数参数变化时进行重新取数的：

上面的代码经常用 Class Component 的人应该很熟悉，然而暴露的问题可不小。

我们需要理解 props.count props.step 被 props.fetchData 函数使用了，因此在 componentDidUpdate 时，判断这两个参数发生了变化就触发重新取数。

然而问题是，这种理解成本是不是过高了？如果父级函数 fetchData 不是我写的，在不读源码的情况下，我怎么知道它依赖了 props.count 与 props.step 呢？更严重的是，如果某一天 fetchData 多依赖了 params 这个参数，下游函数将需要全部在 componentDidUpdate 覆盖到这个逻辑，否则 params 变化时将不会重新取数。可以想象，这种方式维护成本巨大，甚至可以说几乎无法维护。

换成 Function Component 的思维吧！试着用上刚才提到的 useCallback 解决问题：

可以看出来，当 fetchData 的依赖变化后，按下保存键，eslint-plugin-react-hooks 会自动补上更新后的依赖，而下游的代码不需要做任何改变，下游只需要关心依赖了 fetchData 这个函数即可，至于这个函数依赖了什么，已经封装在 useCallback 后打包透传下来了。

不仅解决了维护性问题，而且对于 只要参数变化，就重新执行某逻辑，是特别适合用 useEffect 做的，使用这种思维思考问题会让你的代码更 “智能”，而使用分裂的生命周期进行思考，会让你的代码四分五裂，而且容易漏掉各种时机。

useEffect 对业务的抽象非常方便，笔者举几个例子：

1. 依赖项是查询参数，那么 useEffect 内可以进行取数请求，那么只要查询参数变化了，列表就会自动取数刷新。注意我们将取数时机从触发端改成了接收端。
2. 当列表更新后，重新注册一遍拖拽响应事件。也是同理，依赖参数是列表，只要列表变化，拖拽响应就会重新初始化，这样我们可以放心的修改列表，而不用担心拖拽事件失效。
3. 只要数据流某个数据变化，页面标题就同步修改。同理，也不需要在每次数据变化时修改标题，而是通过 useEffect “监听” 数据的变化，这是一种 “控制反转” 的思维。

说了这么多，其本质还是利用了 useCallback 将函数独立抽离到 useEffect 外部。

那么进一步思考，可以将函数抽离到整个组件的外部吗？

这也是可以的，需要灵活运用自定义 Hooks 实现。

将函数抽到组件外部

以上面的 fetchData 函数为例，如果要抽到整个组件的外部，就不是利用 useCallback 做到了，而是利用自定义 Hooks 来做：

可以看到，我们将 useCallback 打包搬到了自定义 Hook useFetch 中，那么函数中只需要一行代码就能实现一样的效果了：

随着使用越来越方便，我们可以将精力放到性能上。观察可以发现，count 与 step 都会频繁变化，每次变化就会导致 useFetch 中 useCallback 依赖的变化，进而导致重新生成函数。然而实际上这种函数是没必要每次都重新生成的，反复生成函数会造成大量性能损耗。

换一个例子就可以看得更清楚：

假设我们使用 Sortablejs 对某个区域进行拖拽监听，这个函数每次都重复执行的性能损耗非常大，然而这个函数内部可能因为仅仅要上报一些日志，所以依赖了没有实际被使用的 count step 变量：

这种情况，函数的依赖就特别不合理。虽然依赖变化应该触发函数重新执行，但如果函数重新执行的成本非常高，而依赖只是可有可无的点缀，得不偿失。

利用 Ref 保证耗时函数依赖不变

一种办法是通过将依赖转化为 Ref：

这种方式比较取巧，**将需要更新的区域与耗时区域分离，**再将需更新的内容通过 Ref 提供给耗时的区域，实现性能优化。

然而这样做对函数的改动成本比较高，有一种更通用的做法解决此类问题。

通用的自定义 Hooks 解决函数重新实例化问题

我们可以利用 useRef 创造一个自定义 Hook 代替 useCallback，使其依赖的值变化时，回调不会重新执行，却能拿到最新的值！

这个神奇的 Hook 写法如下：

再次体会到自定义 Hook 的无所不能。

首先看这一段：

当 fn 回调函数变化时， ref.current 重新指向最新的 fn 这个逻辑中规中矩。重点是，当依赖 dependencies 变化时，也重新为 ref.current 赋值，此时 fn 内部的 dependencies 值是最新的，而下一段代码：

又仅执行一次（ref 引用不会改变），所以每次都可以返回 dependencies 是最新的 fn，并且 fn 还不会重新执行。

假设我们对 useEventCallback 传入的回调函数称为 X，则这段代码的含义，就是使每次渲染的闭包中，回调函数 X 总是拿到的总是最新 Rerender 闭包中的那个，所以依赖的值永远是最新的，而且函数不会重新初始化。

React 官方不推荐使用此范式，因此对于这种场景，利用 useReducer，将函数通过 dispatch 中调用。 还记得吗？dispatch 是一种可以绕过依赖的黑魔法，我们在 “什么是 useReducer” 小节提到过。

随着对 Function Component 的使用，你也渐渐关心到函数的性能了，这很棒。那么下一个重点自然是关注 Render 的性能。

用 memo 做 PureRender

在 Fucntion Component 中，Class Component 的 PureComponent 等价的概念是 React.memo，我们介绍一下 memo 的用法：

使用 memo 包裹的组件，会在自身重渲染时，对每一个 props 项进行浅对比，如果引用没有变化，就不会触发重渲染。所以 memo 是一种很棒的性能优化工具。

下面就介绍一个看似比 memo 难用，但真正理解后会发现，其实比 memo 更好用的渲染优化函数：useMemo。

用 useMemo 做局部 PureRender

相比 React.memo 这个异类，React.useMemo 可是正经的官方 Hook：

可以看到，我们利用 useMemo 包裹渲染代码，这样即便函数 Child 因为 props 的变化重新执行了，只要渲染函数用到的 props.fetchData 没有变，就不会重新渲染。

这里发现了 useMemo 的第一个好处：更细粒度的优化渲染。

所谓更细粒度的优化渲染，是指函数 Child 整体可能用到了 A、B 两个 props，而渲染仅用到了 B，那么使用 memo 方案时，A 的变化会导致重渲染，而使用 useMemo 的方案则不会。

而 useMemo 的好处还不止这些，这里先留下伏笔。我们先看一个新问题：当参数越来越多时，使用 props 将函数、值在组件间传递非常冗长：

虽然 Child 可以通过 memo 或 useMemo 进行优化，但当程序复杂时，可能存在多个函数在所有 Function Component 间共享的情况，此时就需要新 Hook: useContext 来拯救了。

使用 Context 做批量透传

在 Function Component 中，可以使用 React.createContext 创建一个 Context:

其中 null 是初始值，一般置为 null 也没关系。接下来还有两步，分别是在根节点使用 Store.Provider 注入，与在子节点使用官方 Hook useContext 拿到注入的数据：

在根节点使用 Store.Provider 注入：

在子节点使用 useContext 拿到注入的数据（也就是拿到 Store.Provider 的 value）：

这样就不需要在每个函数间进行参数透传了，公共函数可以都放在 Context 里。

但是当函数多了，Provider 的 value 会变得很臃肿，我们可以结合之前讲到的 useReducer 解决这个问题。

使用 useReducer 为 Context 传递内容瘦身

使用 useReducer，所有回调函数都通过调用 dispatch 完成，那么 Context 只要传递 dispatch 一个函数就好了：

这下无论是根节点的 Provider，还是子元素调用都清爽很多：

你也许很快就想到，将 state 也通过 Provider 注入进去岂不更妙？是的，但此处请务必注意潜在性能问题。

将 state 也放到 Context 中

稍稍改造下，将 state 也放到 Context 中，这下赋值与取值都非常方便了！

对 Count Step 这两个子元素而言，可需要谨慎一些，假如我们这么实现这两个子元素：

其结果是：无论点击 incCount 还是 incStep，都会同时触发这两个组件的 Rerender。

其问题在于：memo 只能挡在最外层的，而通过 useContext 的数据注入发生在函数内部，会 绕过 memo。

当触发 dispatch 导致 state 变化时，所有使用了 state 的组件内部都会强制重新刷新，此时想要对渲染次数做优化，只有拿出 useMemo 了！

useMemo 配合 useContext

使用 useContext 的组件，如果自身不使用 props，就可以完全使用 useMemo 代替 memo 做性能优化：

对这个例子来说，点击对应的按钮，只有使用到的组件才会重渲染，效果符合预期。 结合 eslint-plugin-react-hooks 插件使用，连 useMemo 的第二个参数依赖都是自动补全的。

读到这里，不知道你是否联想到了 Redux 的 Connect?

我们来对比一下 Connect 与 useMemo，会发现惊人的相似之处。

一个普通的 Redux 组件：

一个普通的 Function Component 组件：

这两段代码的效果完全一样，Function Component 除了更简洁之外，还有一个更大的优势：全自动的依赖推导。

Hooks 诞生的一个原因，就是为了便于静态分析依赖，简化 Immutable 数据流的使用成本。

我们看 Connect 的场景：

由于不知道子组件使用了哪些数据，因此需要在 mapStateToProps 提前写好，而当需要使用数据流内新变量时，组件里是无法访问的，我们要回到 mapStateToProps 加上这个依赖，再回到组件中使用它。

而 useContext + useMemo 的场景：

由于注入的 state 是全量的，Render 函数中想用什么都可直接用，在按保存键时，eslint-plugin-react-hooks 会通过静态分析，在 useMemo 第二个参数自动补上代码里使用到的外部变量，比如 state.count、dispatch。

另外可以发现，Context 很像 Redux，那么 Class Component 模式下的异步中间件实现的异步取数怎么利用 useReducer 做呢？答案是：做不到。

当然不是说 Function Component 无法实现异步取数，而是用的工具错了。

使用自定义 Hook 处理副作用

比如上面抛出的异步取数场景，在 Function Component 的最佳做法是封装成一个自定义 Hook：

可以看到，自定义 Hook 拥有完整生命周期，我们可以将取数过程封装起来，只暴露状态 - 是否在加载中：isLoading 是否取数失败：isError 数据：data。

在组件中使用起来非常方便：

如果这个值需要存储到数据流，在所有组件之间共享，我们可以结合 useEffect 与 useReducer：

到此，Function Component 的入门概念就讲完了，最后附带一个彩蛋：Function Component 的 DefaultProps 怎么处理？

Function Component 的 DefaultProps 怎么处理？

这个问题看似简单，实则不然。我们至少有两种方式对 Function Component 的 DefaultProps 进行赋值，下面一一说明。

首先对于 Class Component，DefaultProps 基本上只有一种大家都认可的写法：

然而在 Function Component 就五花八门了。

利用 ES6 特性在参数定义阶段赋值

这种方法看似很优雅，其实有一个重大隐患：没有命中的 props 在每次渲染引用都不同。

看这种场景：

只要 type 的引用不变，useEffect 就不会频繁的执行。现在通过父元素刷新导致 Child 跟着刷新，我们发现，每次渲染都会打印出日志，也就意味着每次渲染时，type 的引用是不同的。

有一种不太优雅的方式可以解决：

此时不断刷新父元素，只会打印出一次日志，因为 type 的引用是相同的。

我们使用 DefaultProps 的本意必然是希望默认值的引用相同， 如果不想单独维护变量的引用，还可以借用 React 内置的 defaultProps 方法解决。

利用 React 内置方案

React 内置方案能较好的解决引用频繁变动的问题：

上面的例子中，不断刷新父元素，只会打印出一次日志。

因此建议对于 Function Component 的参数默认值，建议使用 React 内置方案解决，因为纯函数的方案不利于保持引用不变。

最后补充一个父组件 “坑” 子组件的经典案例。

不要坑了子组件

我们做一个点击累加的按钮作为父组件，那么父组件每次点击后都会刷新：

另外我们将 schema = { b: 1 } 传递给子组件，这个就是埋的一个大坑。

子组件的代码如下：

只要父级 props.schema 变化就会打印日志。结果自然是，父组件每次刷新，子组件都会打印日志，也就是 子组件 [props.schema] 完全失效了，因为引用一直在变化。

其实 子组件关心的是值，而不是引用，所以一种解法是改写子组件的依赖：

这样可以保证子组件只渲染一次。

可是真正罪魁祸首是父组件，我们需要利用 Ref 优化一下父组件：

这样 schema 的引用能一直保持不变。如果你完整读完了本文，应该可以充分理解第一个例子的 schema 在每个渲染快照中都是一个新的引用，而 Ref 的例子中，schema 在每个渲染快照中都只有一个唯一的引用。

3. 总结

所以使用 Function Component 你入门了吗？

本次精读留下的思考题是：Function Component 开发过程中还有哪些容易犯错误的细节？

讨论地址是：精读《Function Component 入门》 · Issue #157 · dt-fe/weekly

如果你想参与讨论，请 点击这里，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。

关注 前端精读微信公众号

special Sponsors

• DevOps 全流程平台

版权声明：自由转载-非商用-非衍生-保持署名（创意共享 3.0 许可证）

我使用的是腾讯云服务器

1. 云服务创建密匙对：在管理云服务器界面，创建SSH密钥（公匙和私匙），并绑定在该云服务器

2. 上传Github：将项目上传Github，并在项目中创建.github文件，在.github文件下创建workflows文件，在workflows下添加push.yaml，添加以代码

3. 创建Github密匙：

   • 新建两个密匙REMOTE_HOST PRIVATE_KEY
   • REMOTE_HOST 为云服务器ip地址
   • PRIVATE_KEY 为私钥（.pem文件内容）

   

转自https://github.com/ascoders/weekly/tree/master/%E5%89%8D%E6%B2%BF%E6%8A%80%E6%9C%AF

一、摘要

相信大家以前应该接触过持续集成（Continuous integration）持续交付（continuous delivery）持续发布（continuous deployment）的概念，下面我们来说说三者的差异以及团队如何入手 CI/CD。

作者：猫神。

二、差异

2.1 CI 持续集成

开发者尽量时时刻刻合并开发分支至主干分支。避免直到发布日才开始合并，掉入集成地狱。无论何时新分支集成至项目，持续集成可以自动化测试持续验证应用是否正常。

2.2 CD 持续交付

持续交付是持续集成的扩展，可以保证稳定的发布产品新特性。这意味着基于自动化测试，你可以也可以一键自动化发布。理论上，持续交付可以决定是按天，按周，按双周发布产品。如果确实希望能够享受持续交付的好处，那么应该尽快发布到新产品中。一旦出现问题时能尽早排除。

2.3 CD 持续部署

持续部署是持续交付的下一步。通过这一步，每个新特性都自动的部署到产品中。但是如果出现未通过的测试用例将会终止自动部署。持续部署可以加速用户反馈新特性，避免发布日带来的压力。开发可以着力于开发系统，开发结束后几分钟就可以触达到用户。

三、协作

CI/CD 具体是个什么样的流程呢，如下图所示，差异仅在于是否自动部署。

现在开发都讲究投入产出比，那么 CI/CD 具体需要做些什么呢？

Continuous Intergretion 持续集成

投入：

• 需要为每个新特性编写测试用例

• 需要搭建持续集成服务器，监控主干仓库，并自动运行测试用例

• 开发需要尽量频繁的合并分支，至少一天一次

产出：

• 更少的 bug，因为自动化测试可以回归测试产品
• 编译部署产品更简化，因为集成的问题都尽早的解决了
• 开发者可以尽量减少上下文切换，因为构建的时候就暴露问题，尽早解决了
• 测试成本降低，因为 CI 服务器可以一秒运行几百个测试用例
• 测试团队花更少的时间测试，可以重点关注测试上的改进。

Continuous delivery 持续交付

投入：

• 需要有持续集成的基础，测试用例需要覆盖足够的代码
• 部署需要自动化，用户只需要手动触发，剩余的部署应该自动化
• 团队需要增加新特性标志，避免未完成的新特性进入待发布的产品

产出：

• 部署软件变得非常简单。团队不需要花费 n 天准备发布。
• 可以提高发布频率，加速新特性触达用户进程。
• 小的更改，对决策的压力要小得多，可以更快地迭代。

Continuous deployment 持续部署

投入：

• 测试必须要做到足够。测试的质量将决定发布的质量。
• 文档建设需要和产品部署保持同步。
• 新特性的发布需要协调其他部门，包括售后支持&市场&推广等。

产出：

• 快速的发布节奏，因为每个新特性一旦完成都会自动的发布给用户。
• 发布风险降低，修复问题更容易，因为每次变更都是小步迭代发布。
• 用户可以看到持续性的优化和质量提升，而不是非要等到按月，按季度，甚至按年

如果开发的是一个新项目，暂时还没有任何用户，那么每次提交代码后发布将会特别简单，可以随时随地发布。一旦产品开始开发后，就需要提高测试文化，并确保在构建应用程序时增加代码覆盖率。当您准备好面向用户发布时，您将有一个非常好的连续部署过程，在该过程中，所有新的更改都将在自动发布到生产环境之前进行测试。

如果正在开发的是一个老系统，就需要放慢节奏，开始打造持续集成&持续交付。首先可以完成一些简单可自动化执行的单元测试，不需要考虑复杂的端到端的测试。另外，应该尽快尝试自动化部署，搭建可以自动化部署的临时环境。因为自动化部署，可以让开发者去优化测试用例，而不是停下来联调发布。 一旦开始按日发布产品，我们可以考虑持续部署，但一定要保证团队已经准备好这种方式，文档 & 售后支持 & 市场。这些步骤都需要加入到新产品发布节奏中，因为和用户直接打交道的是他们。

四、如何开始持续集成

4.1 了解测试类型

为了获得 CI 的所有好处，每次代码变更后，我们需要自动运行测试用例。我们需要在每个分支运行测试用例，而不是仅仅在主干分支。这样可以最快速的找到问题，最小化问题影响面。 在初始阶段并不需要实现所有的测试类型。一开始可以以单元测试入手，随着时间扩展覆盖面。

• 单元测试：范围非常小，验证每个独立方法级别的操作。
• 集成测试：保证模块间运行正常，包括多个模块、多个服务。
• 验收测试：与集成测试类似，但是仅关注业务 case，而不是模块内部本身。
• UI 测试：从用户的角度保证呈现正确运行。

并不是所有的测试都是对等的，实际运行中可以做些取舍。

单元测试实现起来既快成本又低，因为它们主要是对小代码块进行检查。另一方面，UI 测试实施起来很复杂，运行起来很慢，因为它们通常需要启动一个完整的环境以及多个服务来模拟浏览器或移动行为。因此，实际情况可能希望限制复杂的 UI 测试的数量，并依赖基础上良好的单元测试来快速构建，并尽快获得开发人员的反馈。

4.2 自动运行测试

要采用持续集成，您需要对推回到主分支的每个变更运行测试。要做到这一点，您需要有一个服务来监视您的存储库，并听取对代码库的新推送。您可以从企业预置型解决方案和云端解决方案中进行选择。您需要考虑以下因素来选择服务器：

• 代码托管在哪里？CI 服务可以访问您的代码库吗？您对代码的生存位置有特殊的限制吗？
• 应用程序需要哪些操作系统和资源？应用程序环境是否受支持？能安装正确的依赖项来构建和测试软件吗？
• 测试需要多少资源？一些云应用程序可能对您可以使用的资源有限制。如果软件消耗大量资源，可能希望将 CI 服务器宿主在防火墙后面。
• 团队中有多少开发人员？当团队实践 CI 时，每天都会将许多更改推回到主存储库中。对于开发人员来说，要获得快速的反馈，您需要减少构建的队列时间，并且您需要使用能够提供正确并发性的服务或服务器。 在过去，通常需要安装一个独立的 CI 服务器，如 Bamboo 或 Jenkins，但现在您可以在云端找到更简单的解决方案。例如，如果您的代码托管在 BitBucket 云上，那么您可以使用存储库中的 Pipelines 功能在每次推送时运行测试，而无需配置单独的服务器或构建代理，也无需限制并发性。
• 使用代码覆盖率查找未测试的代码。一旦您采用了自动化测试，最好将它与一个测试覆盖工具结合起来，帮助了解测试套件覆盖了多少代码库。代码覆盖率定在 80%以上是很好的，但要注意不要将高覆盖率与良好的测试套件混淆。代码覆盖工具将帮助您找到未经测试的代码，但在一天结束的时候，测试的质量会产生影响。如果刚开始，不要急于获得代码库的 100%覆盖率，而是使用测试覆盖率工具来找出应用程序的关键部分，这些部分还没有测试并从那里开始。
• 重构是一个添加测试的机会。如果您将要对应用程序进行重大更改，那么应该首先围绕可能受到影响的特性编写验收测试。这将为您提供一个安全网，以确保在重构代码或添加新功能后，原始行为不会受到影响。

五、接受 CI 文化

自动化测试是 CI 的关键，但同时也需要团队成员接受 CI 文化，并不是心血来潮晒两天鱼，并且需要保证编译畅通无阻。QA 可以帮助团队建设测试文化。他们不再需要手动测试应用程序的琐碎功能，现在他们可以投入更多的时间来提供支持开发人员的工具，并帮助他们采用正确的测试策略。一旦开始采用持续集成，QA 工程师将能够专注于使用更好的工具和数据集促进测试，并帮助开发人员提高编写更好代码的能力。

• 尽早集成。如果很长时间不合并代码，代码冲突的风险就越高，代码冲突的范围就越广。如果发现某些分支会影响已经存在的分支，需要增加发布关闭标签，避免发布时两个分支冲突。
• 保证编译时时刻刻畅通。一旦发现任何编译问题，立刻修复，否则可能会带来更多的错误。测试套件需要尽快反馈测试结果，或者优先返回短时间测试（单元测试）的结果，否则开发者可能就切换回开发了。一旦编译出错，需要通知给开发者，或者更进一步给出一个 dashboard，每个人都可以在这里查看编译结果。
• 把测试用例纳入流程的一部分。确保每个分支都有自动化测试用例。似乎编写测试用例拖慢了项目节奏，但是它可以减少回归时间，减少每次迭代带来的 bug。而且每次测试通过后，将会非常有信息合并到主干分支，因为新增的内容不影响以前的功能。
• 修 bug 的时候编写测试用例。把 bug 的每个场景都编写成测试用例，避免再次出现。

六、集成测试 5 个步骤

1. 从最严格的代码部分入手测试
2. 搭建一个自动构建的服务自动运行测试用例，在每次提交代码后。
3. 确保团队成员每天合并变更
4. 代码出现问题及时修复
5. 为每个新实现的操作编写测试用例。 可能看着很简单，但是要求团队能够真正落地。一开始你需要放慢发布的脚步，需要和 pd、用户沟通确保不上线没有测试用例的新功能。我们的建议是从小处入手，通过简单的测试来适应新的例程，然后再着手实现更复杂更难管理的测试套件。

七、说说笔者的团队

以上文章主要是说明团队实现 CI/CD 的取舍和可行性步骤。下面来说说希望 CI/CD 给笔者团队带来什么样的变化。目前笔者团队已经实现前端项目发布编译工程化，采用的是基于 webpack 的自建工具云构建模式。但现在面临的问题是 1. 交互的系统比较多，交互系统提供的接入源变更后，需要人工通知其他系统手动触发编译，而且每次手动编译都需要在本地切换到指定分支，然后手动触发云构建，2. 多人协作，分支拆分较细，需要手动合并分支，触发编译。整个流程冗长，而且中间存在人力沟通成本，容易产生沟通误差。所以首先希望解决的是 CI 自动化，当依赖变更后或者分支合并后，自动集成，自动编译。当然生产环境暂时还不敢瞎搞，但大部分重复编译的工作量主要集中在预发环境，所以手动部署生产环境的成本还是可以接受的。CI 自动化之前，需要提供系统之间交互的单元测试用例，每次 CI 后自动运行单元测试用例，最好能打通 QA 的测试用例，进行回归测试。流程对比如下：

讨论地址是：精读《持续集成 vs 持续交付 vs 持续部署》 · Issue #147 · dt-fe/weekly

如果你想参与讨论，请 点击这里，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。

关注 前端精读微信公众号

special Sponsors

• DevOps 全流程平台

版权声明：自由转载-非商用-非衍生-保持署名（创意共享 3.0 许可证）

首页我们是使用PS进行绘制，通过img标签展示，CSS配置自适应。

词云页

3D词云实现

πr平方

1. 首先是将词云数据进行存储并渲染在页面上，设置圆心坐标，以及最大圆半径，通过Math对象上的三角函方法计算词云运动轨迹。
2. 创建Tag类，标识x,y,z三维坐标，其中z用于计算为缩放比例和透明度，x，y为横纵坐标，设计move()标签旋转方法传入最大圆半径，标签数量、球心横坐标、球心纵坐标，动态修改标签横坐标、纵坐标实现旋转
3. 监听鼠标移动事件mousemove，设置旋转角度。

普通词云

通过echarts-wordCloud 插件,传入配置、遮罩图片（maskImage）以及数据，由ECharts生成

四个现代化

基本图表实现（折线、柱形、饼图）

传入配置、以及数据、由ECharts生成。

象形柱图

利用svg图标替换象形图默认展示的形状，具体操作是在symbol属性下设置svg数据。

立体柱形图

由三部分组成，上下深浅菱形象形图以及中间的柱形图构成。

时间轴

时间轴的配置项由基础配置BaseOption和变量配置options,基础配置用于配置时间轴样式以及不同时间线下的图表默认样式

人口规模

共同富裕

地图

通过ECharts注册高德地图GeoJSON数据，并配置地图别名，可在type属性下填写该别名由ECharts生成地图

物资精神文明

和平发展

水球图

音标ˈlɪkwɪd fɪlm*/*

利用ECharts插件echarts-liquidfill 插件传入样式以及数据，由ECharts生成

前端架构

我们的采用Vue3+TypeScript+ECharts进行前端架构，Vue3用于搭建页面实现可视化图表的布局、二次封装ECharts图表组件便于代码复用,TypeScript保证代码的可读性和维护性，ECharts个性化订制图表主题，实现20多种图表。我们是项目数据利用python爬虫爬取数据存储在Excel表格中。地图数据通过Axios发起请求获取高德地图GeoJSON 地图数据动态展示地图。

ECharts技术

二次封装ECharts，通过将图表封装成一个组件，接收父组件传递的长、宽、图表数据来控制，这一图表的

地图

GeoJSON 是一种对各种地理数据结构进行编码的格式。GeoJSON 对象可以表示几何、特征或者特征集合。GeoJSON 支持下面几何类型：点、线、面、多点、多线、多面和几何集合。GeoJSON 里的特征包含一个几何对象和其他属性，特征集合表示一系列特征。

一个完整的 GeoJSON 数据结构总是一个（JSON 术语里的）对象。在 GeoJSON 里，对象由 名/值对（name/value pair）——也称作成员的集合组成。对每个成员来说，名称总是字符串。成员的值要么是字符串、数字、对象、数组，要么是下面文本常量中的一个：true, false 和 null。数组由元素（element）组成，其中每个元素都是如上所述的值。

Vue3

页面搭建、可视化图表布局

TypeScript

类型系统和错误捕获、代码和补全、更好的工程化支持，在此基础上为项目提供更好的可维护性。

回答问题先说结论

http://101.35.227.27/

跨域问题：

由于我们项目擦用前后端分离，前端和后端的服务不在同一个源（两个 URL 的协议、端口 (en-US)（如果有指定的话）和主机都相同）下，当前端访问后端接口时会产生跨域问题。

前端解决方案：

1. 本地开发时，利用Vite/Webpack 配置代理DevServer，将/api下的接口请求，重写并代理转发到后端接口所在端口

   1. 原理： webpack中的proxy只是一层代理，用于把指定的path，代理去后端提供的地址，背后使用node来做server。可能有人疑惑，为什么只适用本地开发？因为该技术只是在webpack打包阶段在本地临时生成了node server，来实现类似nginx 的proxy_pass的反向代理效果

      proxy工作原理实质上是利用http-proxy-middleware 这个http代理中间件，实现请求转发给其他服务器。例如：本地主机A为http://localhost:3000，该主机浏览器发送一个请求，接口为/api，这个请求的数据（响应）在另外一台服务器Bhttp://10.231.133.22:80上，这时，就可以通过A主机设置webpack proxy，直接将请求发送给B主机。

2. 部署到云服务器上时，利用Nginx反向代理，重写/api路径下的请求，代理转发到相应后端接口地址

   • 原理：反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。

     举个例子，比如我想访问 http://www.test.com/readme，但www.test.com上并不存在readme页面，于是他是偷偷从另外一台服务器上取回来，然后作为自己的内容返回用户，但用户并不知情。这里所提到的 www.test.com 这个域名对应的服务器就设置了反向代理功能。

     结论就是，反向代理服务器对于客户端而言它就像是原始服务器，并且客户端不需要进行任何特别的设置。客户端向反向代理的命名空间(name-space)中的内容发送普通请求，接着反向代理服务器将判断向何处(原始服务器)转交请求，并将获得的内容返回给客户端，就像这些内容原本就是它自己的一样。

     正向代理，既然有反向代理，就肯定有正向代理。什么叫正向代理呢？

     正向代理（Forward Proxy）通常都被简称为代理，就是在用户无法正常访问外部资源，比方说受到GFW的影响无法访问twitter的时候，我们可以通过代理的方式，让用户绕过防火墙，从而连接到目标网络或者服务。

     正向代理的工作原理就像一个跳板，比如：我访问不了google.com，但是我能访问一个代理服务器A，A能访问google.com，于是我先连上代理服务器A，告诉他我需要google.com的内容，A就去取回来，然后返回给我。从网站的角度，只在代理服务器来取内容的时候有一次记录，有时候并不知道是用户的请求，也隐藏了用户的资料，这取决于代理告不告诉网站。

     结论就是，正向代理是一个位于客户端和原始服务器(origin server)之间的服务器。为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。

   • [通俗易懂的Nginx工作原理 - 腾讯云开发者社区-腾讯云 (tencent.com)](https://cloud.tencent.com/developer/article/1427219#:~:text=通俗易懂的Nginx工作原理 1 1.1 概念 反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。 ... 2,... 7 3.2 一个简单的HTTP请求 ... 8 3.3 请求完整处理过程)

选择node-sass的版本

node版本与node-sass的版本需要对应。这一点非常重要，版本不对应会出现各种各样的问题，导致node-sass下载失败。由于我使用的node版本是14.16.0，所以选择node-sass 4.14.1。

动画图片来源

图标字体：阿里巴巴矢量图标

svg可伸缩矢量图形：使用的是unDraw免费开源图形库

动态图片来源lottiefiles，轻量级的，可扩展的动画，为您的广告和社交媒体lottiefiles带走了复杂的运动设计。它可以让你以最简单的方式创建、编辑、测试、协作和发布Lottie。

持久化存储用户信息

页面跳转时，你的用户的导航栏的用户信息如何获取？

通过登录时获取的用户信息，然后存储在localStorage之中，页面跳转时在Mounted中调用localStorage.get()传入key进行获取。

1. 增/改。登录后获取用户信息，通过调用localStorage.setItem()传入key和用户信息对象进行存储。除非手动删除或者设置过期时间，否则不会因浏览器的关闭而清空。
2. 查。需要获取时调用localStorage.getItem()传入key，获取相应对象。
3. 删。localStorage.removeItem()

ElementUI

无限滚动（Infinite Scroll）

1. 触底触发load()方法
2. load()方法中添加新的数据
3. 当没有数据可以添加时，显示触底动画

骨架屏的实现

1. 预先编译好一段相同结构的纯HTMLCSS代码
2. 通过v-if这个Vue指令，在数据还获取的这段时间展示预先编译好的这段代码，获取到之后取反标识，展示我们的帖子数据。

浏览器在获取和渲染大量的数据时，是需要时间的，而这段时间页面通常会显示白屏。为了解决这个问题，我们通过预先编译好一段相同结构的纯HTMLCSS代码，然后定义一个标识（标识数据是否获取到了），通过v-if这个Vue指令，在数据还获取的这段时间展示预先编译好的这段代码，获取到之后取反标识，展示我们的帖子数据。

文件的上传功能模块

短篇不支持富文本，而长篇支持富文本。逻辑这部分基本相同。

文件上传逻辑

1. 添加请求头 'Conten-Type': "multipart/form-data"，由于上传文件需要一定时间设置timeout超时时间为180秒，保证文件上传的成功性。
2. 文件数据转换为FormData格式
3. 调用后端接口上传文件

文件上传时的异常处理：

1. 文件上传成功，但发布失败，此时调用oss文件删除接口

2. 文件上传失败

帖子详情查看

逻辑：通过获取文件后缀，进行判断，动态渲染目标文件。

文件预览

• 图片

  • 通过嵌入img标签

• 视频

  • 通过第三方库Video库

• 文档类

  • 通过嵌入IFrame标签，提供文档链接，使用微软提供的Office Online进行预览

  • 使用微软提供的Office Online平台只需要一个网址即可在线查看Xls,doc,PPT等文档

搜索功能

调用后台接口获取数据

输入搜索信息，通过JavaScript 中的include查找搜索信息、filter方法过滤数组。动态搜索帖子

后台

地图显示

通过百度地图开放平台获取的API key，结合Bmap插件，由ECharts生成。

百度地图审图号：

ECharts图表展示

通过传入ECharts配置文件，调用后端接口获取数据，由ECharts初始化并渲染图表。

地图是通过百度开放平台获取API key，结合Bmap插件和ECharts渲染地图。

导出Excel

• 调用接口设置 请求头 responseType:'blob'接收后台传递过来的文件数据，存入blob对象中
• 通过window.URL.createObjectURL(blob)传入blob对象生成url
• 动态创建a标签接收接收blob url，设置download属性，模拟a标签点击事件，下载Excel文件
• 最后删除a标签

解决问题

联盟链特点：

既可以

成本可控

Virtual DOM是一棵以JavaScript对象作为基础的树，每一个节点称为VNode，用对象属性来描述节点，实际上它是一层对真实DOM的抽象，最终可以通过渲染操作使这棵树映射到真实环境上，简单来说Virtual DOM就是一个Js对象，用以描述整个文档。

虚拟DOM优缺点

优点

• Virtual DOM在牺牲(牺牲很关键)部分性能的前提下，增加了可维护性，这也是很多框架的通性。
• 实现了对DOM的集中化操作，在数据改变时先对虚拟DOM进行修改，再反映到真实的DOM，用最小的代价来更新DOM，提高效率。
• 打开了函数式UI编程的大门。
• 可以渲染到DOM以外的端，使得框架跨平台，比如ReactNative，React VR等。
• 可以更好的实现SSR，同构渲染等。
• 组件的高度抽象化。

缺点

• 首次渲染大量DOM时，由于多了一层虚拟DOM的计算，会比innerHTML插入慢。
• 虚拟DOM需要在内存中的维护一份DOM的副本，多占用了部分内存。
• 如果虚拟DOM大量更改，这是合适的。但是单一的、频繁的更新的话，虚拟DOM将会花费更多的时间处理计算的工作。所以如果你有一个DOM节点相对较少页面，用虚拟DOM，它实际上有可能会更慢，但对于大多数单页面应用，这应该都会更快。

自定义 tab 选项卡 2

图表

uCharts

更新数据-加载动画踩坑

加载动画说明

官方组件共提供了5种加载动画样式（详见页面底部），加载动画展示的逻辑如下：

1. 如果是 uniCloud 数据，从发送网络请求到返回数据期间展示
2. 如果是自行传入的 chartData 数据，当 chartData.series == [] 的时候展示 loading，也就是说初始化图表的时候，如果您没有数据，可以通过先传个空数组来展示 loading 效果，当 chartData.series 有数据后会自动隐藏 loading 图标。

如果您由始至终不想展示加载动画，可以赋值 loadingType = 0 来关闭动画效果。

App打包

• 'test'导出失败，失败原因：App打包时，项目中文件名不能含有中文或全角字符，请确认。

Android平台签名证书(.keystore)生成指南

https://ask.dcloud.net.cn/article/id-35777

新版jdk的keytool没有md5

vscode打开setting.json

Ctrl Shift P

输入settings.json

vscode配置 eslint+prettierrc自动格式化vue3、ts、tsx文件

https://blog.csdn.net/m0_45236510/article/details/114704838

域名系统 (DNS - Domain Name System) 是 Internet 电话簿。人们通过例如 baidu.com 或 qq.com 等域名在线访问信息。Web 浏览器通过 Internet 协议 (IP) 地址进行交互。DNS 将域名转换为 IP 地址，以便浏览器能够加载 Internet 资源。

连接到 Internet 的每个设备都有一个唯一 IP 地址，其他计算机可使用该 IP 地址查找此设备。DNS 服务器使人们无需存储例如 192.168.1.1（IPv4 中）等 IP 地址或更复杂的较新字母数字 IP 地址，例如 2400:cb00:2048:1::c629:d7a2（IPv6 中）。

DNS如何工作

DNS 解析过程涉及将主机名（例如 www.example.com）转换为计算机友好的 IP 地址（例如 192.168.1.1）。Internet 上的每个设备都被分配了一个 IP 地址，必须有该地址才能找到相应的 Internet 设备 - 就像使用街道地址来查找特定住所一样。当用户想要加载网页时，用户在 Web 浏览器中键入的内容（example.com）与查找 example.com 网页所需的机器友好地址之间必须进行转换。

DNS服务器类别

::: Tip

所有 DNS 服务器都属于以下四个类别之一：递归解析器、根域名服务器、TLD 域名服务器和权威性域名服务器。在典型 DNS 查找中（当没有正在进行的高速缓存时），这四个 DNS 服务器协同工作来完成将指定域的 IP 地址提供给客户端的任务（客户端通常是一个存根解析器 - 内置于操作系统的简单解析器）。

:::

• DNS 解析器（DNS recursor） - 该解析器可被视为被要求去图书馆的某个地方查找特定图书的图书馆员。DNS 解析器是一种服务器，旨在通过 Web 浏览器等应用程序接收客户端计算机的查询。然后，解析器一般负责发出其他请求，以便满足客户端的 DNS 查询。
• 根域名服务器（Root nameserver） - 根域名服务器是将人类可读的主机名转换（解析）为 IP 地址的第一步。可将其视为指向不同书架的图书馆中的索引 - 一般其作为对其他更具体位置的引用。
• TLD 域名服务器（TLD nameserver） - 顶级域服务器（TLD）可被视为图书馆中的特定书架。此域名服务器是搜索特定 IP 地址的下一步，其托管主机名的最后一部分（在 example.com 中，TLD 服务器为 「com」）。
• 权威性域名服务器（Authoritative nameserver ） - 可将这个最终域名服务器视为书架上的字典，其中特定名称可被转换成其定义。权威性域名服务器是域名服务器查询中的最后一站。如果权威性域名服务器能够访问请求的记录，则其会将已请求主机名的 IP 地址返回到发出初始请求的 DNS 解析器（图书管理员）。

DNS查找IP地址步骤

::: Tip 注意

通常，DNS 查找信息将本地缓存在查询计算机内，或者远程缓存在 DNS 基础设施内。DNS 查找通常有 8 个步骤。缓存 DNS 信息时，将从 DNS 查找过程中跳过一些步骤，从而使该过程更快。以下示例概述了不缓存任何内容时的所有 8 个步骤。

:::

DNS服务器根据域名的层级，进行分级查询。

需要明确的是，每一级域名都有自己的NS（Name Server的缩写）记录，NS记录指向该级域名的域名服务器。

1. 用户在 Web 浏览器中键入 example.com，查询传输到 Internet 中，并被 DNS 递归解析器接收。
2. 接着，解析器向 DNS 根域名服务器（.）发起查询请求。
3. 然后，根服务器返回其域信息的顶级域（TLD）DNS 服务器（例如 .com 或 .net）的 NS 记录和 A 记录给该解析器。例如：在访问 example.com 时，我们的请求指向 .com TLD 服务器。
4. 然后，解析器向 .com TLD 服务器发出请求。
5. TLD 服务器随后返回域名 example.com 的权威性域名服务器 NS 记录和 A 记录。
6. 最后，递归解析器将查询发送到域的域名服务器。
7. example.com 的 IP 地址从权威性域名服务器返回到解析器。
8. 然后 DNS 解析器使用最初请求的域的 IP 地址响应 Web 浏览器。

DNS 查找经过这 8 个步骤返回 example.com 的 IP 地址后，浏览器便能发出对该网页的请求。

9. 浏览器向该 IP 地址发出 HTTP 请求。
10. 位于该 IP 的服务器返回将在浏览器中呈现的网页（第 10 步）。

DNS查询的类型

典型 DNS 查找中会出现三种类型的查询。通过组合使用这些查询，优化的 DNS 解析过程可缩短传输距离。在理想情况下，可以使用缓存的记录数据，从而使 DNS 域名服务器能够返回非递归查询。

1. 递归查询 - 在递归查询中，DNS 客户端要求 DNS 服务器（一般为 DNS 递归解析器）将使用所请求的资源记录响应客户端，或者如果解析器无法找到该记录，则返回错误消息。
2. 迭代查询 - 在这种情况下，DNS 客户端将允许 DNS 服务器返回其能够给出的最佳应答。如果所查询的 DNS 服务器与查询名称不匹配，则其将返回对较低级别域名空间具有权威性的 DNS 服务器的引用。然后，DNS 客户端将对引用地址进行查询。此过程继续使用查询链中的其他 DNS 服务器，直至发生错误或超时为止。
3. 非递归查询 - 当 DNS 解析器客户端查询 DNS 服务器以获取其有权访问的记录时通常会进行此查询，因为其对该记录具有权威性，或者该记录存在于其缓存内。DNS 服务器通常会缓存 DNS 记录，以防止更多带宽消耗和上游服务器上的负载。

DNS缓存方式

DNS高速缓存

缓存的目的是将数据临时存储在某个位置，从而提高数据请求的性能和可靠性。DNS 高速缓存涉及将数据存储在更靠近请求客户端的位置，以便能够更早地解析 DNS 查询，并且能够避免在 DNS 查找链中进一步向下的额外查询，从而缩短加载时间并减少带宽 CPU 消耗。DNS 数据可缓存到各种不同的位置上，每个位置均将存储 DNS 记录并保存由生存时间（TTL）决定的一段时间。

浏览器DNS缓存

现代 Web 浏览器设计为默认将 DNS 记录缓存一段时间。目的很明显；越靠近 Web 浏览器进行 DNS 缓存，为检查缓存并向 IP 地址发出正确请求而必须采取的处理步骤就越少。发出对 DNS 记录的请求时，浏览器缓存是针对所请求的记录而检查的第一个位置。

在 Chrome 浏览器中，您可以转到 chrome://net-internals/#dns 查看 DNS 缓存的状态。

操作系统（OS）级DNS缓存

操作系统级 DNS 解析器是 DNS 查询离开您计算机前的第二站，也是本地最后一站。操作系统内旨在处理此查询的过程通常称为「存根解析器」或 「DNS 客户端」。当存根解析器获取来自某个应用程序的请求时，其首先检查自己的缓存，以便查看是否有此记录。如果没有，则将本地网络外部的 DNS 查询（设置了递归标记）发送到 Internet 服务提供商（ISP）内部的 DNS 递归解析器。

总结

参考

三次握手与四次挥手，虽然我工作中目前还没有涉及网络编程这一方面的东西，但是难免面试老是要被问到，算是个高频的必备知识点了。

三次握手，目的有3个。

**第一个目的是为了防止在网络阻塞时，历史连接乱入，导致造成混乱。**如果是两次握手，则在第二次握手时不加以校验，服务端与一个旧的连接建立通信。有了三次握手，能够在第二次握手时校验，校验成功则正常进行第三次握手，否则发送RST信号。

**第二个目的是为了同步双方的初始化序列号。**从这个层面上来说，可以把3次握手看作是4次握手的精简版，即两轮SYN-ACK，各自发送SYN并接收应答信号。只不过中间第二次握手的应答和第三次握手的SYN可以合二为一。（相较于4次挥手，由于被动方可能还有数据要发送，所以FIN和ACK必须分离，所以是4次）

**第三个目的是为了避免资源的浪费。**在网络阻塞情况下，客户端可能多次发送SYN请求，如果只有两次握手，由于服务端无法得知客户端是否接受到ACK信号并建立起连接，只能在每次接受到SYN信号时都主动建立一个连接。故在SYN冗余情况下，重复分配资源，造成浪费。而三次握手的机制得以在第二次握手时进行校验，校验成功通过第三次握手应答后才建立起连接，避免了资源浪费。

四次挥手，原因是上面目的二提到的，通信双方其中一方主动请求断开连接时，另一方可能还有数据要发送，故需要把被动方的ACK和FIN分开成两次挥手。

主动发起断连的一方会有TIME_WAIT的状态，需要等待2MSL，原因是：一方面，等待足够长的时间，能够让滞留在网络中的历史数据消失，以至于下一次在相同端口建立TCP连接时，旧数据不至于在握手时造成数据混乱。另一方面，2MSL确保被动关闭连接的一方能够被正确关闭。因为第四次挥手的ACK信号可能由于网络阻塞或数据丢失而没到达被动方，被动方将一直处于LAST_ACK的状态。本来会有个超时重发机智，重新进行第三次挥手发送FIN信号，重新等待接收四次挥手的ACK，但如果主动关闭方老早就断连了，则永远没人处理重发的信号，被动方永远等在LAST_ACK。

而2MSL正好是第三次挥手和第四次挥手的往返时间之和

转自https://t.me/https1024/11474

https://juejin.cn/post/7234687030017376312

React其实很简单

• 任何领域,强大的、高效的东西,一定是简单的·
• React就是JS ,外加一点模板语言JSX (像HTML)说
• React 难的人，可能JS 语法都不熟练

React核心价值

React核心价值:

1-组件化

2-数据驱动视图

• $ UI = f(state) $
• 理解：函数接收一个参数（数据），返回视图（UI、HTML）
• 好处
  • 定义好数据和 UI 的显示规则，即 UI = f(state)
  • 只关注业务数据的修改，不用再操作 DOM，增加开发效率
  • 尤其对于DOM 结构复杂的大型项目

创建项目

创建项目

使用Create-React-App 创建 React 项目

npx create-react-app react-ts-demo --template typescript

使用 Vite 创建 React 项目

npm create vite my-react --template react-ts

使用 eslint prettier husty 等，制定编码规则

制定编码规则

• 安装相关插件

• 项目根目录添加并配置.eslintrc.js 安装prettier插件、eslint插件

• 配置package.json脚本

  • 正常情况下

  • 如果上面的不行，可以试一试下面的

• 配置vscode，保存自动触发eslint

  • 项目根目录新建.vscode文件

  • 新建setting.json

• 自定义prettier

  • 项目根目录新建.prettierrc.js

  • 或者新增.prettierrc

husky

简介

• 一个 git hook 工具.在
• git commit 之前执行自定义的命令
• 如执行代码风格的检查，避免提交非规范代码

使用

git-hook

安装依赖

参考文档 https://github.com/typicode/husky 增加三个 pre-commit 命令

可以故意制造一个错误：定义一个未使用变量（eslint 配置文件 rules 增加 'no-unused-vars': 'error',）
然后执行 git commit 试试

commit-lint

参考文档 https://github.com/conventional-changelog/commitlint#getting-started 安装设置即可

commit 规则查看 node_modules/@commitlint/config-conventional （在 commitlint.config.js 中有配置）

尝试 git commit -m "test" 会失败，再尝试 git commit -m "chore: commit lint" 会成功

常见类型 commitlint-config-conventional (based on the Angular convention) 可以有以下:

These can be modified by your own configuration.

条件循环

条件

• &&
• 三元表达式
• 函数

循环

• 定义数组+map遍历

React Hooks

内置Hooks

useState

特点

• 会触发页面更新，重新渲染，触发state更新

• state是异步更新，state更新可能会被合并，使用函数state更新不会被合并

• 不可变数据（重要！！！）- 不去修改 state的值，而是传入一个新的值

如果说 一个变量 不用于 JSX 中显示，那就不要用 setState 来管理它，用useRef

state增删查改

数组

增

• concat

删

• filter

查

• filter

改

• map

状态提升：数据源在父组件中，子组件只需要负责展示。操作、数据由父组件实现、传递，子组件调用、渲染

immer

Immer 简化了不可变数据结构的处理。特别是对于 JS 语法没那么熟悉的人。

useEffect

useEffect执行两次

• React 18开始, useEffect在==开发环境==下会执行两次

• 模拟组件创建、销毁、再创建的完整流程,及早暴露问题

• 生产环境下会执行一次

• 当组件渲染完成时,加载一个Ajax网络请求

• 当某个state更新时,加载一个Ajax网络请求使用

• useEffect 实现

示例

其他内置Hooks

useRef

• 一般用于操作DOM
• 也可传入普通JS变量,但更新不会触发 rerender
• 要和Vue3 ref区分开(如果你用过Vue3)

useMemo

• 函数组件，每次state更新都会重新执行函数
• useMemo 可以缓存数据，不用每次执行函数都重新生成
• 可用于计算量较大的场景，缓存提高性能

useCallback

• 和 useMemo 作用一样
• 专门用于缓存函数

自定义Hooks（复用代码）

封装常用Hooks，比如工具库

第三方Hooks（提高效率）

• ahooks （国内）
• React use （国外）

Hooks使用规则

• 必须用useXxx格式来命名
• 只能在两个地方调用Hook（组件内Hooks内）
• 必须保证每次的调用顺序一致（不能放在 if for 内部）

闭包陷阱

• 当异步函数获取 state 时，可能不是当前最新的 state
• 可使用 useRef 来解决
• （要提前了解JS 闭包）

React中使用CSS

• 内联 style 的方式
• 引入 CSS 文件，使用 className
• 尽量不要用内联 style

className条件判断-第三方包

• classnames
• clax

尽量不要使用内联style

• 内联 style 代码多，性能差，扩展性不好
• 外链 CSS 文件可复用代码，可单独缓存文件
• PS :这和React无关,学HTML CSS时就应该知道

普通CSS的问题

• React 使用组件化开发
• 多个组件，就需要多个 CSS 文件
• 多个CSS文件很容易造成 className 重复,不好管理

解决方案

• 普通CSS的问题-className会重复.
• 解决方案 CSS Module
• 增加Sass支持

CSS Module

• 每个CSS文件都当做单独的模块,命令xxx.module.css
• 为每个 className 增加后缀名，不让它们重复
• Create-React-App原生支持CSS Module

CSS-in-JS

• 一种解决方案（而非工具名称），有好几个工具.
• 在JS 中写 CSS ,带来极大的灵活性
• 它和内联style完全不一样,也不会有内联style的问题

优缺点

• 优点:用JS写,有逻辑有变量,非常灵活,
• 缺点：JSX 和样式代码混在一块，代码较多；增加了编译成本；
• 适用场景：需要灵活变换样式

工具

• styled-component
• styled-jsx
• emotion

React-Router

目标：为系统增加路由，支持多页面定义和切换

内容：

• 路由设计，网址和页面的关系

• 增加页面和 Layout 模板使用

• React-router 增加路由配置

Hooks

• useNavigate——跳转页面
• useParams——获取params参数
• useSearchParams——获取query参数

React表单组件、受控组件

受控组件

表单值与state状态联动

表单组件

input-textarea

• value 绑定 useState
• 监听onChange()事件，传入event事件对象，setState传入event.target.value新数据，更新数据

radio

checkbox

select

form

状态管理

• React内置功能Context和useReducer
• 第三方工具Redux和 MobX
• 使用 Redux 管理用户状态

解决问题：

• 页面足够复杂：组件很多，嵌套层级很深
• 通过 props 层层传递不合适
• 需要状态管理,即集中、统一管理页面数据

Context

• 可跨层级传递，而不像 props 层层传递
• 类似于Vue 的 provide/inject
• 例如:切换主题、切换语言

useReducer

• useState的代替方案
• 数据结构简单时用useState ,复杂时用useReducer
• 简化版的 redux

useReducer概念

• state或store
• action
• reducer
• dispatch

使用总结

• 类似于redux的流程和API
• 结合Context 解决跨组件问题
• state dispatch 默认没有模块化,数据混在一起

Redux

Redux和useReducer概念一致

• state或store
• action
• reducer
• dispatch

Context + useReducer 代替 Redux ?

• 社区热议的话题
• 简单场景可以,节省代码体积,更简单
• 复杂场景仍然建议用 Redux

Mobx

声明式的修改数据，像Vue | 有一定学习成本

概念

• state 数据
• action 动作
• derivation 派生: computed observer

项目实战

imooc——React 仿问卷星 电子书

路由设计

页面对应的路由

• 首页 /
• 登录 /login
• 注册 /register
• 问卷管理
  • 我的问卷 /manage/list
  • 星标问卷 /manage/star
  • 回收站 /manage/trash
• 问卷详情
  • 编辑问卷 /question/edit/:id （动态路由）
  • 问卷统计 /question/stat/:id
• 404

Layout 模板

• MainLayout
• ManageLayout
• QuestionLayout

搜索、分页、下滑加载

改变浏览器url，而不是直接操作列表中的数据

好处：

• 降低不同组件之间的耦合
• 刷新时，防止数据丢失（从url中获取）

示例

搜索

• 从url获取params参数
• 搜索时再url添加params参数

分页

前提：使用antd组件库的pagination

• 从url获取params参数
• 监听onChange事件（Pagination封装的方法，当pageSize、page改变时执行）。在url中添加params参数

LoadMore

• 每次请求累加列表

AJAX

Mock

• 搭建mock服务（作为临时的服务端）
  • 重要性
    • 工作中,场景前后端并行开发,而非串行
    • 前后端商议好API格式,双方各自开发。前端使用mock服务
    • 待前后端都开发完,再对接联调功能
  • 技术选型
    • 使用mock.js
      • 只能劫持 XMLHttpRequest ,不能劫持 fetch ,有局限性
      • 要在生产环境（上线时）注释掉，否则线上请求也被劫持
      • 结论:不建议在项目中直接使用mock.js
    • 使用nodejs服务+ mock.js
      • 使用mock.js的Random能力
      • 定义 nodejs代码结构,考虑多模块的扩展性
      • 刻意延迟1s ,模拟loading效果
    • 使用在线 mock 平台
      • 如Fast-mock Y-API Swagger (国外)
      • 可能不稳定、不维护，或者网络不稳定
      • 可能存在敏感数据泄漏的风险
    • 总结
      • 直接在前端使用 mock.js - 不推荐
      • 使用 nodejs + mock.js - 推荐
      • 使用在线mock平台-不推荐(除非公司内部的)
• 使用Ajax和服务端通讯，并应用于现有功能
• API设计（使用Restful API设计）
• 实战：为列表页、登录页、注册页，增加Ajax请求

基础知识和工具

• HTTP 协议，前后端通讯的桥梁

• API : XMLHttpRequest和fetch

• 常用工具 axios

API设计

用户

JWT

• JSON Web Token
• 登录成功后，服务端返回一个 token（令牌，一段字符串）
• 以后每次请求带着这个token,以表明自己的身份

最近一直在找前端方向的工作，奈何一直找不到[哭]。现实的重压到了我的头上，焦虑焦虑焦虑。有时候想想又还好，有时候又很焦虑。大一的时候学习的CSharp+Unity本来想一直坚持下去，但是之后被ShaderLab以及美术、建模啥的啥的劝退，然后学习了前端，学了一年自信了不少，结果找不到工作又给我打回去了[哭]。目前想的是把这两结合起来吧。

:::为什么不学Java？

​ 太卷了，太卷了。Java比前端还卷我不想去蹭

:::

类型和变量

类型定义 C# 中的任何数据的结构和行为。 类型的声明可以包含其成员、基类型、它实现的接口和该类型允许的操作。 变量是用于引用特定类型的实例的标签。

C# 有两种类型：值类型和引用类型。 值类型的变量直接包含它们的数据。 引用类型的变量存储对数据（称为“对象”）的引用。 对于引用类型，两个变量可以引用同一个对象；对一个变量执行的运算可能会影响另一个变量引用的对象。 借助值类型，每个变量都有自己的数据副本；因此，对一个变量执行的运算不会影响另一个变量（ref 和 out 参数变量除外）。

标识符是变量名称。 标识符是不包含任何空格的 unicode 字符序列。 如果标识符的前缀为 @，则该标识符可以是 C# 保留字。 在与其他语言交互时，使用保留字作为标识符很有用。

C# 的值类型进一步分为：简单类型、枚举类型、结构类型、可以为 null 的值类型和元组值类型。 C# 引用类型又细分为类类型、接口类型、数组类型和委托类型。

以下大纲概述了 C# 的类型系统。

• 值类型
  • 简单类型
    • 有符号整型：sbyte、short、int、long
    • 无符号整型：byte、ushort、uint、ulong
    • Unicode 字符：char，表示 UTF-16 代码单元
    • IEEE 二进制浮点：float、double
    • 高精度十进制浮点数：decimal
    • 布尔值：bool，表示布尔值（true 或 false）
  • 枚举类型
    • enum E {...} 格式的用户定义类型。 enum 类型是一种包含已命名常量的独特类型。 每个 enum 类型都有一个基础类型（必须是八种整型类型之一）。 enum 类型的值集与基础类型的值集相同。
  • 结构类型
    • 格式为 struct S {...} 的用户定义类型
  • 可以为 null 的值类型
    • 值为 null 的其他所有值类型的扩展
  • 元组值类型
    • 格式为 (T1, T2, ...) 的用户定义类型
• 引用类型
  • 类类型
    • 其他所有类型的最终基类：object
    • Unicode 字符串：string，表示 UTF-16 代码单元序列
    • 格式为 class C {...} 的用户定义类型
  • 接口类型
    • 格式为 interface I {...} 的用户定义类型
  • 数组类型
    • 一维、多维和交错。 例如：int[]、int[,] 和 int[][]
  • 委托类型
    • 格式为 delegate int D(...) 的用户定义类型

概念

基础知识

场景：

相机：

物体|材质|纹理：

渲染器：

辅助工具：GUI（第三方）、坐标轴辅助器

dat.gui

灯光阴影

需满足以下条件：

粒子效果

将粒子绑定在普通几何体上

将粒子绑定在BufferGeometry上

BufferAttribute( array : TypedArray, itemSize : Integer, normalized : Boolean )

array -- 必须是 TypedArray. 类型，用于实例化缓存。 该队列应该包含：itemSize * numVertices个元素，numVertices 是 BufferGeometry中的顶点数目

itemSize -- 队列中与顶点相关的数据值的大小。举例，如果 attribute 存储的是三元组（例如顶点空间坐标、法向量或颜色值）则itemSize的值应该是3。

normalized -- (可选) 指明缓存中的数据如何与GLSL代码中的数据对应。例如，如果array是 UInt16Array类型，且normalized的值是 true，则队列中的值将会从 0 - +65535 映射为 GLSL 中的 0.0f - +1.0f。 如果array是 Int16Array (有符号)，则值将会从 -32768 - +32767 映射为 -1.0f - +1.0f。若 normalized 的值为 false，则数据映射不会归一化，而会直接映射为 float 值，例如，32767 将会映射为 32767.0f.

光线投射Raycaster