1、安装docker
2、docker创建mysql镜像
数据文件映射到本地

```
docker run -d --network bridge --restart=always --privileged=true -v /app/data/mysql/data/:/var/lib/mysql -v /app/data/mysql/conf.d:/etc/mysql/conf.d --name blog -p 3306:3306 -e MYSQL_ROOT_PASSWORD=root mysql:5.7
```
不需要映射文件
```
docker run -d --network bridge --restart=always --privileged=true --name blog -p 3306:3306 -e MYSQL_ROOT_PASSWORD=root mysql:5.7
```
3、登录并创建数据库
```
docker container exec -it blog bash;
mysql -u root -p;
CREATE DATABASE  `blog` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
```
4、设置时区
```
timedatectl
docker container exec -it blog bash;
mysql -u root -p;
SHOW VARIABLES LIKE '%time_zone%';
SET GLOBAL time_zone = '+08:00';
SET time_zone = '+08:00';
```

Docker 快速创建 Mysql 

## 工具类型的分类
内置的工具类型按照类型操作的不同，可以大致划分为这么几类：
* **属性修饰工具类型**：对属性的修饰，包括对象属性和数组元素的可选/必选、只读/可写。
* **结构工具类型**：对既有类型的裁剪、拼接、转换等
* **集合工具类型**：对集合（即联合类型）的处理，即交集、并集、差集、补集。
* **模式匹配工具类型**：基于 infer 的模式匹配，即对一个既有类型特定位置类型的提取，比如提取函数类型签名中的返回值类型。
* **模板字符串工具类型**：模板字符串专属的工具类型，比如神奇地将一个对象类型中的所有属性名转换为大驼峰的形式。

## 属性修饰工具类型

在内置工具类型中，访问性修饰工具类型有：
```
// 将类型 T 的所有属性变为可选属性。这对于创建部分更新或配置对象特别有用。
type Partial<T> = {
    [p in keyof T]?: T[p]
}

// 将类型 T 的所有可选属性变为必填属性。这在确保对象的所有属性都被填充时很有帮助。
type Required<T> = {
    [p in keyof T]-?: T[p]
}

// 创建一个类型，其所有属性都是只读的，这有助于防止意外修改。
type Readonly<T> = {
    readonly [p in keyof T]: T[p]
}
```

其中需要注意的是，Partial 是 ?，即标记属性为可选，而 Required 则是 -?，相当于在原本属性上如果有 ? 这个标记，则移除它。 Partial 也可以使用 +? 来显式的表示添加可选标记。

## 结构工具类型

```
// 创建一个类型，其键是类型 K 的联合，值是类型 T
type Record<K extends keyof any, T> = {
    [P in K]: T;
}

```
如 Record<string, unknown> 和 Record<string, any> 是日常使用较多的形式，通常我们使用这两者来代替 object。

一些其他的结构申明工具类型：
```
// 字符串字典
type Dictionary<T> = {
  [index: string]: T;
};

// 数字字典
type NumericDictionary<T> = {
  [index: number]: T;
};
```
以及最主要的结构处理工具类型

```
// 从类型 T 中选择一组属性 K 来创建一个新的类型。
type Pick<T, K extends keyof T> = {
    [P in K]: T[P]
}

// 从类型 T 中删除一组属性 K 来创建一个新的类型。
type Omit<T, K extends keyof any> = Pick<T,  Exclude<keyof T, K>> 

```

## 集合工具类型

内置工具类型中提供了交集与差集的实现：

```
// 交集
type Extract<T, U> = T extends U ? T : never;

// 差集
type Exclude<T, U> = T extends U ? never : T;

// 集合 T 相对于 null | undefined 的差集
type NonNullable<T> = T extends null | undefined ? never : T;
```

## 模式匹配工具类型

这一部分的工具类型主要使用条件类型与 infer 关键字。

infer 其实代表了一种 模式匹配（pattern matching） 的思路，如正则表达式、Glob 中等都体现了这一概念。


首先是对函数类型签名的模式匹配：

```
type FunctionType = (...args: any) => any;

// 获取函数参数类型
type Parameters<T extends FunctionType> = T extends (...args: infer P) => any ? P : never;

// 获取函数返回类型
type ReturnType<T extends FunctionType> = T extends (...args: any) => infer R ? R : any;

```


除了对函数类型进行模式匹配，内置工具类型中还有一组对 Class 进行模式匹配的工具类型：

```
type ClassType = abstract new (...args: any) => any;

// 获取构造函数类型 T 的参数类型。
type ConstructorParameters<T extends ClassType> = T extends abstract new (
  ...args: infer P
) => any
  ? P
  : never;

// 获取构造函数类型 T 的实例类型。
type InstanceType<T extends ClassType> = T extends abstract new (
  ...args: any
) => infer R
  ? R
  : any;

```

## 模板字符串类型

模板字符串类型的主要目的即是增强字符串字面量类型的灵活性，进一步增强类型和逻辑代码的关联。

例如通过模板字符串类型你可以这样声明你的版本号：

```
type Version = `${number}.${number}.${number}`;

const v1: Version = '1.1.0';

// X 类型 "1.0" 不能赋值给类型 `${number}.${number}.${number}`
const v2: Version = '1.0';

```

基于 keyof + 模板字符串类型，我们可以基于已有的对象类型来实现精确到字面量的类型推导：

```
interface Foo {
  name: string;
  age: number;
  job: Job;
}

type ChangeListener = {
  on: (change: `${keyof Foo}Changed`) => void;
};

declare let listener: ChangeListener;

// 提示并约束为 "nameChanged" | "ageChanged" | "jobChanged"
listener.on('');

```

以下是几种与模板字符串紧密相关的内置工具类型：
```
// 将类型 S 表示的字符串中的所有字符转换为大写形式。
type Uppercase<S extends string> = intrinsic;

// 将类型 S 表示的字符串中的所有字符转换为小写形式。
type Lowercase<S extends string> = intrinsic;

// 将类型 S 表示的字符串中的第一个字符转换为大写，其余字符不变。
type Capitalize<S extends string> = intrinsic;

// 类型 S 表示的字符串中的第一个字符转换为小写，其余字符不变。
type Uncapitalize<S extends string> = intrinsic;

```






























内置的工具类型按照类型操作的不同，可以大致划分为这么几类：属性修饰工具类型、结构工具类型、集合工具类型、模式匹配工具类型、模板字符串工具类型



TypeScript 内置工具类型

## Fiber 出现的背景
首先要知道的是，JavaScript 引擎和页面渲染引擎两个线程是互斥的，当其中一个线程执行时，另一个线程只能挂起等待。
在这样的机制下，如果 JavaScript 线程长时间地占用了主线程，那么渲染层面的更新就不得不长时间地等待，界面长时间不更新，会导致页面响应度变差，用户可能会感觉到卡顿。

而这正是 React 15 的 Stack Reconciler 所面临的问题，即是 JavaScript 对主线程的超时占用问题。Stack Reconciler 是一个同步的递归过程，使用的是 JavaScript 引擎自身的函数调用栈，它会一直执行到栈空为止，所以当 React 在渲染组件时，从开始到渲染完成整个过程是一气呵成的。如果渲染的组件比较庞大，js 执行会占据主线程较长时间，会导致页面响应度变差。

而且所有的任务都是按照先后顺序，没有区分优先级，这样就会导致优先级比较高的任务无法被优先执行。

## Fiber 是什么
Fiber 的中文翻译叫纤程，与进程、线程同为程序执行过程，Fiber 就是比线程还要纤细的一个过程。纤程意在对渲染过程实现进行更加精细的控制。

从架构角度来看，Fiber 是对 React 核心算法（即调和过程）的重写。

从编码角度来看，Fiber 是 React 内部所定义的一种数据结构，它是 Fiber 树结构的节点单位，也就是 React 16 新架构下的"虚拟 DOM"。

一个 fiber 就是一个 JavaScript 对象，Fiber 的数据结构如下：

```js
type Fiber = {
  // 用于标记fiber的WorkTag类型，主要表示当前fiber代表的组件类型如FunctionComponent、ClassComponent等
  tag: WorkTag,
  // ReactElement里面的key
  key: null | string,
  // ReactElement.type，调用`createElement`的第一个参数
  elementType: any,
  // The resolved function/class/ associated with this fiber.
  // 表示当前代表的节点类型
  type: any,
  // 表示当前FiberNode对应的element组件实例
  stateNode: any,

  // 指向他在Fiber节点树中的`parent`，用来在处理完这个节点之后向上返回
  return: Fiber | null,
  // 指向自己的第一个子节点
  child: Fiber | null,
  // 指向自己的兄弟结构，兄弟节点的return指向同一个父节点
  sibling: Fiber | null,
  index: number,

  ref: null | (((handle: mixed) => void) & { _stringRef: ?string }) | RefObject,

  // 当前处理过程中的组件props对象
  pendingProps: any,
  // 上一次渲染完成之后的props
  memoizedProps: any,

  // 该Fiber对应的组件产生的Update会存放在这个队列里面
  updateQueue: UpdateQueue<any> | null,

  // 上一次渲染的时候的state
  memoizedState: any,

  // 一个列表，存放这个Fiber依赖的context
  firstContextDependency: ContextDependency<mixed> | null,

  mode: TypeOfMode,

  // Effect
  // 用来记录Side Effect
  effectTag: SideEffectTag,

  // 单链表用来快速查找下一个side effect
  nextEffect: Fiber | null,

  // 子树中第一个side effect
  firstEffect: Fiber | null,
  // 子树中最后一个side effect
  lastEffect: Fiber | null,

  // 代表任务在未来的哪个时间点应该被完成，之后版本改名为 lanes
  expirationTime: ExpirationTime,

  // 快速确定子树中是否有不在等待的变化
  childExpirationTime: ExpirationTime,

  // fiber的版本池，即记录fiber更新过程，便于恢复
  alternate: Fiber | null,
}
```

## Fiber 如何解决问题的
Fiber 把一个渲染任务分解为多个渲染任务，而不是一次性完成，把每一个分割得很细的任务视作一个"执行单元"，React 就会检查现在还剩多少时间，如果没有时间就将控制权让出去，故任务会被分散到多个帧里面，中间可以返回至主进程控制执行其他任务，最终实现更流畅的用户体验。

即是实现了"增量渲染"，实现了可中断与恢复，恢复后也可以复用之前的中间状态，并给不同的任务赋予不同的优先级，其中每个任务更新单元为 React Element 对应的 Fiber 节点。

## Fiber 实现原理

实现的方式是requestIdleCallback这一 API，但 React 团队 polyfill 了这个 API，使其对比原生的浏览器兼容性更好且拓展了特性。
> window.requestIdleCallback()方法将在浏览器的空闲时段内调用的函数排队。这使开发者能够在主事件循环上执行后台和低优先级工作，而不会影响延迟关键事件，如动画和输入响应。函数一般会按先进先调用的顺序执行，然而，如果回调函数指定了执行超时时间 timeout，则有可能为了在超时前执行函数而打乱执行顺序。

requestIdleCallback回调的执行的前提条件是当前浏览器处于空闲状态。

即requestIdleCallback的作用是在浏览器一帧的剩余空闲时间内执行优先度相对较低的任务。首先 React 中任务切割为多个步骤，分批完成。在完成一部分任务之后，将控制权交回给浏览器，让浏览器有时间再进行页面的渲染。等浏览器忙完之后有剩余时间，再继续之前 React 未完成的任务，是一种合作式调度。

简而言之，由浏览器给我们分配执行时间片，我们要按照约定在这个时间内执行完毕，并将控制权还给浏览器。

React 16 的Reconciler基于 Fiber 节点实现，被称为 Fiber Reconciler。

作为静态的数据结构来说，每个 Fiber 节点对应一个 React element，保存了该组件的类型（函数组件/类组件/原生组件等等）、对应的 DOM 节点等信息。

作为动态的工作单元来说，每个 Fiber 节点保存了本次更新中该组件改变的状态、要执行的工作。

每个 Fiber 节点有个对应的 React element，多个 Fiber 节点是如何连接形成树呢？靠如下三个属性：


```js
// 指向父级Fiber节点
this.return = null
// 指向子Fiber节点
this.child = null
// 指向右边第一个兄弟Fiber节点
this.sibling = null
```










首先要知道的是，JavaScript 引擎和页面渲染引擎两个线程是互斥的，当其中一个线程执行时，另一个线程只能挂起等待。
在这样的机制下，如果 JavaScript 线程长时间地占用了主线程，那么渲染层面的更新就不得不长时间地等待，界面长时间不更新，会导致页面响应度变差，用户可能会感觉到卡顿。

React Fiber是什么？

## 极简个人搜索页
### 在线访问
https://explore.yohn-z.cn/my-search/

### 仓库地址
https://github.com/Yohn-z/my-search

### 技术栈
使用原生三剑客（html+css+js）开发 , 无需编译部署, 响应式适配
### 目录结构说明
* /css  - css样式
* /icon  - 图标
* /img  - 图片
* /js  - js脚本
* /favicon.svg  - 网站图标、页签图标
* /index.html  主页
### 页面效果
搜索框底部可以放一些个人常用的链接
![20240428202132](http://oss.yohn-z.cn/img/20240428202132.png)

目前支持三种搜索引擎，分别是百度、必应、谷歌，点击切换
![20240428202329](http://oss.yohn-z.cn/img/20240428202329.png)

移动端访问效果
<img src="http://oss.yohn-z.cn/img/20240428202557.png" width="320" />

### 快速部署
#### 1、Fork 本项目到自己的仓库
![20240428203251](http://oss.yohn-z.cn/img/20240428203251.png)
#### 2、更改相关代码
![20240428203416](http://oss.yohn-z.cn/img/20240428203416.png)
#### 3、直接更新仓库代码
git ...

#### 4、使用 github page

找到配置项 my-search > Settings > Pages
![20240428203818](http://oss.yohn-z.cn/img/20240428203818.png)
选择仓库分支和目录 主分支 > /（root）
![20240428203931](http://oss.yohn-z.cn/img/20240428203931.png)
点击保存（save）后，等待一会，GitHub 就会构建你的页面并设置访问链接，一般是 `http://<用户名>.github.io/<仓库名>/`

#### 5、自定义github page域名
如果你有自己的域名，可以自定义搜索页的访问链接（域名）

![20240428204410](http://oss.yohn-z.cn/img/20240428204410.png)
一般是在项目根目录下创建文件 `CNAME`，并写入你的访问域名或者子域名，如：`explore.yohn-z.cn`

然后在你的域名解析管理处，添加一条记录，类型是 `cname`, 指向 `<用户名>.github.io/<仓库名>`

![20240428204802](http://oss.yohn-z.cn/img/20240428204802.png)

可参考项目：`https://github.com/Yohn-z/Yohn-z.github.io`







极简个人搜索页，使用原生三剑客（html+css+js）开发 , 无需编译部署, 响应式适配

极简个人搜索页

### 什么是OpenApi
1、OpenAPI规范，也称作OAS，是一种API文档标准
2、OpenAPI以前被称为Swagger
3、Swagger 规范已于2015 年捐赠给 Linux 基金会后改名为 OpenAPI，并定义最新的规范为 OpenAPI 3.0
### OpenAPI相关资料
1、OpenAPI规范信息如下：
![20240422014105](http://oss.yohn-z.cn/img/20240422014105.png)
2、OpenAPI文章可查看 [OpenAPI官网](https://www.openapis.org/) 或  [OpenAPI 规范（中文）](https://openapi.apifox.cn/)
3、实时预览OpenAPI在线编辑的效果，可以尝试使用  [Swagger Editor](https://editor.swagger.io/)
![20240422014130](http://oss.yohn-z.cn/img/20240422014130.png)
4、[Swagger Editor](https://editor.swagger.io/) 生成代码
![20240422014146](http://oss.yohn-z.cn/img/20240422014146.png)
### 如何解析 Swagger / OpenAPI
##### 1、umijs/plugin-openapi 插件
umijs封装了一个openapi插件，通过输入一个 openapi 的规范文件，就可以完成自动化创建 service（API接口代码）以及Mock模拟请求和数据。相关文档可查看 [OpenAPI - Ant Design Pro](https://pro.ant.design/zh-CN/docs/openapi/)，简单使用流程如下：
引入一个 openAPI 的插件，在Ant Design Pro V5中自带了该插件，其他版本请使用如下方式引入
```
yarn add @umijs/plugin-openapi
 
// npm
npm i @umijs/plugin-openapi --save
```
然后在 config/config.ts 中配置 openAPI 的相关配置。
```
openAPI: {
   requestLibPath: "import { request } from 'umi'",
   // 或者使用在线的版本
   // schemaPath: "https://gw.alipayobjects.com/os/antfincdn/M%24jrzTTYJN/oneapi.json",
   schemaPath: join(__dirname, 'oneapi.json'),
   mock: true,
}
```
注：mock配置为 true 之后会自动生成一些 mock 的文件。
还需要在 package.json 的 scripts 中增加一个命令。
```
"openapi": "umi openapi",
```
执行 npm run openapi 来生成相关的接口和文档。
生成的API接口代码存放在services目录下，接口请求代码相关说明请参考 [UMI MAX Request](https://umijs.org/docs/max/request)。
TS类型文件（typings.d.ts）：
![20240422014304](http://oss.yohn-z.cn/img/20240422014304.png)
接口请求代码（xxxControll.ts）：
![20240422014332](http://oss.yohn-z.cn/img/20240422014332.png)
mock配置为 true 后，执行 npm run openapi  会生成mock文件，mock文件规范可参考 [UMI MOCK](https://umijs.org/docs/guides/mock)。
![20240422014410](http://oss.yohn-z.cn/img/20240422014410.png)
可以访问 /umi/plugin/openapi 来查看文档：
![20240422014544](http://oss.yohn-z.cn/img/20240422014544.png)

另外，openapi文档可通过 [Swagger Editor](https://editor.swagger.io/) 编写，或通过[Apifox](https://link.juejin.cn/?target=https%3A%2F%2Fwww.apifox.cn%2F) 进行可视化编辑。
##### 2、本地化工具生成
OpenApi社区开源了OpenApi Generator，我们可以通过 OpenAPI Generator，通过提供OpenAPI 规范(上文提到的OAS2和OAS3)来自动生成 API 客户端库、文档及配置。
比如我们前端依赖axios作为请求库，那么我们可以通过指定类型来生成ts+axios的请求相关的代码，具体可查阅[openapi-generator](https://github.com/openapitools/openapi-generator)。
如果不熟悉前端，但又有生成其他代码的需求如Go、Java，则可推荐使用 [Apifox](https://link.juejin.cn/?target=https%3A%2F%2Fwww.apifox.cn%2F) 。
> Apifox 不仅支持mock功能和接口调试，还支持代码生成，代码生成引擎使用的也就是我们提到的openapi-generator，可以根据接口/模型定义，自动生成各种语言/框架（如 TypeScript、Java、Go、Swift 等130 种语言及框架）的业务代码，比如接口请求代码

Apifox界面如下
![20240422014559](http://oss.yohn-z.cn/img/20240422014559.png)

可以修改参数类型
![20240422014612](http://oss.yohn-z.cn/img/20240422014612.png)
导出为OpenAPI格式文档
![20240422014627](http://oss.yohn-z.cn/img/20240422014627.png)
生成代码
![20240422014644](http://oss.yohn-z.cn/img/20240422014644.png)
可生成多种类型的请求接口代码/业务代码
![20240422014700](http://oss.yohn-z.cn/img/20240422014700.png)


OpenAPI规范，也称作OAS，是一种API文档标准，
OpenAPI以前被称为Swagger，Swagger 规范已于2015 年捐赠给 Linux 基金会后改名为 OpenAPI，并定义最新的规范为 OpenAPI 3.0。

OpenAPI自动生成代码

有时，img标签中的src图片加载失败，原来的图片位置会出现一个碎片图标。

![](http://oss.yohn-z.cn/myblog/%E4%B8%83%E7%89%9B%E4%BA%91%E4%BD%BF%E7%94%A8/20200124022314-879825.png#alt=img)

这样是不是看着很不舒服呢。

那怎么让这个碎片图标变得好看些呢，这是我今天要讨论的问题。

可以借用img标签的**onerror**事件，img标签支持**onerror** 事件，在装载文档或图像的过程中如果发生了错误，就会触发**onerror**事件。可以使用一张**提示错误的图片**代替显示不了的图片。

```html
<img src="images/logo.png" onerror="javascript:this.src='http://oss.yohn-z.cn/myblog/noimg/github/github-nopig.png';">
```

![](http://oss.yohn-z.cn/myblog/onerror%E4%BE%BF%E7%AD%BE/20200124023142-332264.png#alt=img)

当图片images/logo.png不存在时，将触发 **onerror**事件，而 **onerror** 中又为该 img 指定了替代的图片。

但是，这种方法并不推荐使用！

> 当images/logoError.png 也不存在，则会继续触发 onerror事件，导致死循环，故会出现打开网页时提示 **Stack overflow at line: 0** 错误。特别说明：如果图片存在，但网络很不通畅，也可能触发 **onerror事件**。


解决方法（代码）：

```html
<script type="text/javascript"> 
    function imgerrorfun(){ 
        var img=event.srcElement; 
        img.src="替代的图片.png"; 
        img.onerror=null; 
    } 
</script> 
<img src="images/logo.png" onerror="imgerrorfun();" />
```

当然你可以这样

```
<img src="" onerror="this.src='javascript:test.png';this.onerror='null';">
```

也可以直接隐藏

```
<img src="" onerror="this.style.display = 'none';">
```

同时贴出我测试的另外一种解决方案：

```javascript
<script>  
    function imgExists(e){
            //默认图片
            var imgUrl = "http://oss.yohn-z.cn/myblog/assets/images/avatar.jpg";
            var img = new Image();
            img.src=imgUrl;
            //判断图片大小是否大于0 或者 图片高度与宽度都大于0
            if(img.filesize>0||(img.width>0&&img.height>0)){
                e.src = imgUrl;
            }else{
                //默认图片也不存在的时候
            }
      }
</script>
<img src="images/logo.png" onerror="imgExists(this);" />
```

附上参考链接：[w3school中img部分](https://www.w3school.com.cn/tags/tag_img.asp)

最后，感谢阅读！！！如果觉得不错，记得star哦！


有时，img标签中的src图片加载失败，原来的图片位置会出现一个碎片图标。可以借用img标签的onerror事件，img标签支持onerror 事件，在装载文档或图像的过程中如果发生了错误，就会触发onerror事件。可以使用一张提示错误的图片代替显示不了的图片。

忽如一夜春风来，千树万树梨花开 _