feat: delete invilid word

_posts/2020-02-1-test-markdown.md

@@ -23,9 +23,9 @@ comments: true
 ```shell
 echo 'export PATH="/opt/homebrew/opt/node@18/bin:$PATH"' >> ~/.zshrc
 ```
-此命令将 export PATH=... 添加到你的 ~/.zshrc 文件中，以确保 node@18 的二进制文件在你的路径中优先被找到。
+此命令将 export PATH=... 添加到的 ~/.zshrc 文件中，以确保 node@18 的二进制文件在的路径中优先被找到。
 
-另外，为了让编译器能找到 node@18，你可能需要设置以下环境变量：
+另外，为了让编译器能找到 node@18，可能需要设置以下环境变量：
 
 
 ```shell
@@ -37,7 +37,7 @@ export CPPFLAGS="-I/opt/homebrew/opt/node@18/include"
 
 
 ## 更换Homebrew的镜像源
-你可以通过以下步骤来更换Homebrew的镜像源：
+可以通过以下步骤来更换Homebrew的镜像源：
 1. **更换Homebrew的formula源**：
 
 ```shell
@@ -49,7 +49,7 @@ git remote set-url origin https://mirrors.tuna.tsinghua.edu.cn/git/homebrew/brew
 
 1. **更换Homebrew的bottle源**：
 
-在你的shell配置文件（比如`~/.bash_profile`或者`~/.zshrc`）中添加以下行：
+在的shell配置文件（比如`~/.bash_profile`或者`~/.zshrc`）中添加以下行：
 
 ```shell
 export HOMEBREW_BOTTLE_DOMAIN=https://mirrors.tuna.tsinghua.edu.cn/homebrew-bottles
@@ -67,7 +67,7 @@ cd "$(brew --repo)/Library/Taps/homebrew/homebrew-core"
 git remote set-url origin https://mirrors.tuna.tsinghua.edu.cn/git/homebrew/homebrew-core.git
 ```
 
-以上步骤将Homebrew的源更换为了清华大学的镜像站点，你可以根据需要更换为其他的镜像站点。
+以上步骤将Homebrew的源更换为了清华大学的镜像站点，可以根据需要更换为其他的镜像站点。
 
 注意：如果在更换源之后遇到了问题，可以通过运行以上命令并将URL更换为官方源的URL来恢复到官方源。官方源的URL分别为：
 

_posts/2020-02-26-flake-it-till-you-make-it.md

@@ -13,14 +13,14 @@ tags: [设计模式]
 
 ## 1.概念
 
-**中介者模式**是一种行为设计模式， 能让你减少对象之间混乱无序的依赖关系。 该模式会限制对象之间的直接交互， 迫使它们通过一个中介者对象进行合作。
+**中介者模式**是一种行为设计模式， 能让减少对象之间混乱无序的依赖关系。 该模式会限制对象之间的直接交互， 迫使它们通过一个中介者对象进行合作。
 
-假如你有一个创建和修改客户资料的对话框， 它由各种控件组成， 例如文本框 （Text­Field）、 复选框 （Checkbox） 和按钮 （Button） 等。![用户界面中各元素间的混乱关系](https://refactoringguru.cn/images/patterns/diagrams/mediator/problem1-zh.png)
+假如有一个创建和修改客户资料的对话框， 它由各种控件组成， 例如文本框 （Text­Field）、 复选框 （Checkbox） 和按钮 （Button） 等。![用户界面中各元素间的混乱关系](https://refactoringguru.cn/images/patterns/diagrams/mediator/problem1-zh.png)
 
 
 - 元素间存在许多关联。 因此， 对某些元素进行修改可能会影响其他元素。
 
-- 如果直接在表单元素代码中实现业务逻辑， 你将很难在程序其他表单中复用这些元素类。 
+- 如果直接在表单元素代码中实现业务逻辑， 将很难在程序其他表单中复用这些元素类。 
 
 
 ## 2.问题
@@ -38,9 +38,9 @@ tags: [设计模式]
 
 ## 3.解决方法
 
-> 中介者模式建议你停止组件之间的直接交流并使其相互独立。 这些组件必须调用特殊的中介者对象， 通过中介者对象重定向调用行为， 以间接的方式进行合作。 最终， 组件仅依赖于一个中介者类， 无需与多个其他组件相耦合。
+> 中介者模式建议停止组件之间的直接交流并使其相互独立。 这些组件必须调用特殊的中介者对象， 通过中介者对象重定向调用行为， 以间接的方式进行合作。 最终， 组件仅依赖于一个中介者类， 无需与多个其他组件相耦合。
 
-在资料编辑表单的例子中， 对话框 （Dialog） 类本身将作为中介者， 其很可能已知自己所有的子元素， 因此你甚至无需在该类中引入新的依赖关系。
+在资料编辑表单的例子中， 对话框 （Dialog） 类本身将作为中介者， 其很可能已知自己所有的子元素， 因此甚至无需在该类中引入新的依赖关系。
 
 ![UI 元素必须通过中介者进行沟通。](https://refactoringguru.cn/images/patterns/diagrams/mediator/solution1-zh.png)
 
@@ -58,15 +58,15 @@ tags: [设计模式]
 
 ![中介者设计模式的结构](https://refactoringguru.cn/images/patterns/diagrams/mediator/structure-indexed.png)
 
-1. **组件** （Component） 是各种包含业务逻辑的类。 每个组件都有一个指向中介者的引用， 该引用被声明为中介者接口类型。 组件不知道中介者实际所属的类， 因此你可通过将其连接到不同的中介者以使其能在其他程序中复用。
+1. **组件** （Component） 是各种包含业务逻辑的类。 每个组件都有一个指向中介者的引用， 该引用被声明为中介者接口类型。 组件不知道中介者实际所属的类， 因此可通过将其连接到不同的中介者以使其能在其他程序中复用。
 2. **中介者** （Mediator） 接口声明了与组件交流的方法， 但通常仅包括一个通知方法。 组件可将任意上下文 （包括自己的对象） 作为该方法的参数， 只有这样接收组件和发送者类之间才不会耦合。
 3. **具体中介者** （Concrete Mediator） 封装了多种组件间的关系。 具体中介者通常会保存所有组件的引用并对其进行管理， 甚至有时会对其生命周期进行管理。
 4. 组件并不知道其他组件的情况。 如果组件内发生了重要事件， 它只能通知中介者。 中介者收到通知后能轻易地确定发送者， 这或许已足以判断接下来需要触发的组件了。
 5. 对于组件来说， **中介者看上去完全就是一个黑箱。 发送者不知道最终会由谁来处理自己的请求， 接收者也不知道最初是谁发出了请求**。
 
 ## 6.伪代码
 
-**中介者**模式可帮助你减少各种 UI 类 （按钮、 复选框和文本标签） 之间的相互依赖关系。![中介者模式示例的结构](https://refactoringguru.cn/images/patterns/diagrams/mediator/example.png)
+**中介者**模式可帮助减少各种 UI 类 （按钮、 复选框和文本标签） 之间的相互依赖关系。![中介者模式示例的结构](https://refactoringguru.cn/images/patterns/diagrams/mediator/example.png)
 
 用户触发的元素不会直接与其他元素交流， 即使看上去它们应该这样做。 相反， 元素只需让中介者知晓事件即可， 并能在发出通知时同时传递任何上下文信息。
 
@@ -134,23 +134,23 @@ class Checkbox extends Component is
 
 - 当一些对象和其他对象紧密耦合以致难以对其进行修改时， 可使用中介者模式。
 
-  该模式让你将对象间的所有关系抽取成为一个单独的类， 以使对于特定组件的修改工作独立于其他组件。
+  该模式让将对象间的所有关系抽取成为一个单独的类， 以使对于特定组件的修改工作独立于其他组件。
 
 - 当组件因过于依赖其他组件而无法在不同应用中复用时，可使用中介者模式
 
-  应用中介者模式后， 每个组件不再知晓其他组件的情况。 尽管这些组件无法直接交流， 但它们仍可通过中介者对象进行间接交流。 如果你希望在不同应用中复用一个组件， 则需要为其提供一个新的中介者类。
+  应用中介者模式后， 每个组件不再知晓其他组件的情况。 尽管这些组件无法直接交流， 但它们仍可通过中介者对象进行间接交流。 如果希望在不同应用中复用一个组件， 则需要为其提供一个新的中介者类。
 
-- 如果为了能在不同情景下复用一些基本行为，导致你需要被迫创建大量组件子类时，可使用中介者模式。
+- 如果为了能在不同情景下复用一些基本行为，导致需要被迫创建大量组件子类时，可使用中介者模式。
 
-- 由于所有组件间关系都被包含在中介者中， 因此你无需修改组件就能方便地新建中介者类以定义新的组件合作方式。
+- 由于所有组件间关系都被包含在中介者中， 因此无需修改组件就能方便地新建中介者类以定义新的组件合作方式。
 
 ## 7.实现
 
 1. 找到一组当前紧密耦合， 且提供其独立性能带来更大好处的类 （例如更易于维护或更方便复用）。
 2. 声明中介者接口并描述中介者和各种组件之间所需的交流接口。 在绝大多数情况下， 一个接收组件通知的方法就足够了。
-3. 如果你希望在不同情景下复用组件类， 那么该接口将非常重要。 只要组件使用通用接口与其中介者合作， 你就能将该组件与不同实现中的中介者进行连接。
+3. 如果希望在不同情景下复用组件类， 那么该接口将非常重要。 只要组件使用通用接口与其中介者合作， 就能将该组件与不同实现中的中介者进行连接。
 4. 实现具体中介者类。 该类可从自行保存其下所有组件的引用中受益。
-5. 你可以更进一步， 让中介者负责组件对象的创建和销毁。 此后， 中介者可能会与工厂或外观模式类似。
+5. 可以更进一步， 让中介者负责组件对象的创建和销毁。 此后， 中介者可能会与工厂或外观模式类似。
 6. 组件必须保存对于中介者对象的引用。 该连接通常在组件的构造函数中建立， 该函数会将中介者对象作为参数传递。
 7. 修改组件代码， 使其可调用中介者的通知方法， 而非**其他组件**的方法。 然后将调用其他组件的代码抽取到中介者类中， 并在**中介者**接收到该组件通知时**执行**这些**代码**。（中介者执行调用其他组件代码的逻辑）
 

_posts/2020-02-28-test-markdown.md

@@ -50,7 +50,7 @@ func GetInstance() *singleton {
 
 实际上，这解决了线程安全问题，但会产生其他潜在的严重问题。我们通过`Sync.Mutex`在创建单例实例之前引入并获取锁来解决线程安全问题。问题是在这里我们执行了过多的锁定，即使我们不需要这样做，**如果实例已经创建并且我们应该简单地返回缓存的单例实例。** 高度并发的代码库上，这可能会产生瓶颈，因为一次只有一个 go 例程可以获取单例实例。
 
-- **当某个函数，执行的功能，第一次创建一个单例，之后要做的仅仅是返回这个单例时，如果你为单例的第一次创建加了锁，这么做是为了保证，第一次全局我们只能获取到一个单例，但是，之后的每一次调用，我们的函数要做的仅仅是返回这个单例，而加锁，导致的后果是每次只有一个进程可以获取到已经存在的单例，如果这种获取是百万并发级别的，那么后果是不堪设想的。**
+- **当某个函数，执行的功能，第一次创建一个单例，之后要做的仅仅是返回这个单例时，如果为单例的第一次创建加了锁，这么做是为了保证，第一次全局我们只能获取到一个单例，但是，之后的每一次调用，我们的函数要做的仅仅是返回这个单例，而加锁，导致的后果是每次只有一个进程可以获取到已经存在的单例，如果这种获取是百万并发级别的，那么后果是不堪设想的。**
 
 ## 3.Check-Lock-Check Pattern
 

_posts/2020-06-15-test-markdown.md

@@ -44,9 +44,9 @@ Output:
 
 在这里变量a被拷贝后，地址发生了变化，地址上存储的是原先地址存储的值 10 变量p被拷贝后，地址发生了变化，地址上存储的还是原先地址存储的值 ）0X001, 然后按照这个地址去查找，找到的是 0X001 上面存储的值
 
-所以，当你去修改拷贝后的*p的值，其实修改的还是0X001地址上的值，而不是 拷贝后a的值
+所以，当去修改拷贝后的*p的值，其实修改的还是0X001地址上的值，而不是 拷贝后a的值
 
-> 怎么理解呢？就是对于切片的底层数据而言，其中三个 要素。类型，容量，指针，指针是用来干嘛的，就是指向数组啊，所以说，不论你怎么拷贝切片，切片的指针都是指向原来的数组，当你修改切片的值时，你其实是在修改数组的值！！！！
+> 怎么理解呢？就是对于切片的底层数据而言，其中三个 要素。类型，容量，指针，指针是用来干嘛的，就是指向数组啊，所以说，不论怎么拷贝切片，切片的指针都是指向原来的数组，当修改切片的值时，其实是在修改数组的值！！！！
 
 **slice在实现的时候，其实是对array的映射，也就是说slice存对应的是原array的地址，就类似于p与a的关系，那么整个slice拷贝后，拷贝后的slice中存储的还是array的地址，去修改拷贝后的slice，其实跟修改slice，和原array是一样的**
 
@@ -58,7 +58,7 @@ Output:
 
 #### 总结：
 
-> go 值的拷贝都是值拷贝，只是切片中储存的是原数组的地址，“切片是对数组的引用” 每得到的一个切片都是一个指向数组的指针，当你企图修改切片的值，就是在修改数组的值。内在的逻辑是：一个切片就是你一个指向数组的指针，你通过切片去修改数组，然后在引用数组，自始至终，你都是在引用数组，不存在你切片里面存了你所引用的数组的数据！！！
+> go 值的拷贝都是值拷贝，只是切片中储存的是原数组的地址，“切片是对数组的引用” 每得到的一个切片都是一个指向数组的指针，当企图修改切片的值，就是在修改数组的值。内在的逻辑是：一个切片就是一个指向数组的指针，通过切片去修改数组，然后在引用数组，自始至终，都是在引用数组，不存在切片里面存了所引用的数组的数据！！！
 
 ![img](https://segmentfault.com/img/remote/1460000020086649?w=896&h=498)
 

_posts/2022-02-15-test-markdown.md

@@ -16,11 +16,11 @@ REST API 也称为 RESTful API，是遵循 REST 架构规范的应用编程接
 >
 > API 由一组定义和协议组合而成，可用于构建和集成应用软件。有时我们可以把它们当做信息提供者和信息用户之间的合同——建立消费者（呼叫）所需的内容和制作者（响应）要求的内容。例如，天气服务的 API 可指定用户提供邮编，制作者回复的答案由两部分组成，第一部分是最高温度，第二部分是最低温度。
 >
-> 换言之，如果你想与计算机或系统交互以检索信息或执行某项功能，API 可帮助你将你需要的信息传达给该系统，使其能够理解并满足你的请求。 
+> 换言之，如果想与计算机或系统交互以检索信息或执行某项功能，API 可帮助将需要的信息传达给该系统，使其能够理解并满足的请求。 
 >
 > 可以把 API 看做是用户或客户端与他们想要的资源或 Web 服务之间的传递者。它也是企业在共享资源和信息的同时保障安全、控制和身份验证的一种方式，即确定哪些人可以访问什么内容。 
 >
-> API 的另一个优势是你无需了解缓存的具体信息，即如何检索资源或资源来自哪里。
+> API 的另一个优势是无需了解缓存的具体信息，即如何检索资源或资源来自哪里。
 
 > #### 如何理解 REST 的含义？
 >
@@ -38,7 +38,7 @@ API 要被视为 RESTful API，必须遵循以下标准：
 
 - **[无状态](https://www.redhat.com/zh/topics/cloud-native-apps/stateful-vs-stateless)客户端-服务器通信，即 get 请求间隔期间，不会存储任何客户端信息，并且每个请求都是独立的，互不关联。**客户端到服务端的所有请求必须包含了所有信息，不能够利用任何服务器存储的上下文。 这一约束可以保证绘画状态完全由客户端控制
 
-  这一点在你写一个接口的时候需要独立思考一下，如果每个请求都是独立的，互不关联的，那么他们怎么配合着实现一整套的功能，
+  这一点在写一个接口的时候需要独立思考一下，如果每个请求都是独立的，互不关联的，那么他们怎么配合着实现一整套的功能，
 
 - **可缓存性数据**：可简化客户端-服务器交互。
 
@@ -70,13 +70,13 @@ API 要被视为 RESTful API，必须遵循以下标准：
 
 ## REST vs HTTP
 
-从上面的概念我们就可以知道，REST和任何具体技术无关。 我们会认为REST就是HTTP，主要是因为HTTP是最广为流行的客户端服务端通信协议。 但是HTTP本身和REST无关，你可以通过其他协议构建RESTful服务； 你用HTTP构建的服务也很有可能不是RESTful的。
+从上面的概念我们就可以知道，REST和任何具体技术无关。 我们会认为REST就是HTTP，主要是因为HTTP是最广为流行的客户端服务端通信协议。 但是HTTP本身和REST无关，可以通过其他协议构建RESTful服务； 用HTTP构建的服务也很有可能不是RESTful的。
 
 
 
 ## REST vs JSON
 
-与通信协议一样，REST与任何具体的数据格式无关。 无论你用XML，JSON或是HTML，都可以构建REST服务。
+与通信协议一样，REST与任何具体的数据格式无关。 无论用XML，JSON或是HTML，都可以构建REST服务。
 
 更进一步的，JSON甚至不是一种超媒体格式，只是一种数据格式。 比如JSON并没有定义超链接发现的行为。 真正的REST需要的是有着清楚规范的超媒体格式，比较标准的JSON-base超媒体格式有 [JSON-LD](http://www.w3.org/TR/json-ld/) 和 [HAL](http://stateless.co/hal_specification.html)
 
@@ -260,7 +260,7 @@ Web 存在支持的关键元素是安全（例如 GET）和非安全操作之间
 
 ## 3 级 - 超媒体控制
 
-最后一层介绍了一些你经常听到的东西，它被称为 HATEOAS（超文本作为应用程序状态的引擎）它解决了如何从列表中获取空缺职位以了解如何进行预约的问题。
+最后一层介绍了一些经常听到的东西，它被称为 HATEOAS（超文本作为应用程序状态的引擎）它解决了如何从列表中获取空缺职位以了解如何进行预约的问题。
 
 ![img](https://martinfowler.com/articles/images/richardsonMaturityModel/level3.png)
 

_posts/2022-02-19-test-markdown.md

@@ -29,4 +29,4 @@ Model提供数据，View负责显示，Controller/Presenter负责逻辑的处理
 
 MVVM 模式将 Presenter 改名为 ViewModel，基本上与 MVP 模式完全一致.唯一的区别是，它采用双向绑定（data-binding）：View的变动，自动反映在 ViewModel，反之亦然;
 
-这种模式跟经典的MVP（Model-View-Presenter）模式很相似，除了你需要一个为View量身定制的model，这个model就是ViewModel.ViewModel包含所有由UI特定的接口和属性，并由一个 ViewModel 的视图的绑定属性，并可获得二者之间的松散耦合，所以需要在ViewModel 直接更新视图中编写相应代码.数据绑定系统还支持提供了标准化的方式传输到视图的验证错误的输入的验证.
+这种模式跟经典的MVP（Model-View-Presenter）模式很相似，除了需要一个为View量身定制的model，这个model就是ViewModel.ViewModel包含所有由UI特定的接口和属性，并由一个 ViewModel 的视图的绑定属性，并可获得二者之间的松散耦合，所以需要在ViewModel 直接更新视图中编写相应代码.数据绑定系统还支持提供了标准化的方式传输到视图的验证错误的输入的验证.