之前工作中做项目用到了VUE，实现了几个项目的完整开发。基本是后台管理系统，有一些涉及到人员管理树tree、table、search等组件的构建和表单页面的校验，审批流程页面组件的建立等，项目的webpack的打包发布等。后来发现一些原理性东西并没有十分的清晰，把一些东西杂糅在了一起。看到霍春阳的这本书评分很好，特意借来拜读和实践，梳理一遍自己对于vue的认知。

首先把所有内容做了一个脑图，是按照书中的提示做的。

文字版本

vue.js设计与实现

第一篇框架设计概览

第1章讨论命令式和声明式，虚拟DOM的性能状况。vvue.js 3.0是一个运行时+编译时的框架。

第2章主要从用户的开发体验、控制框架代码的体积、Tree- Shaking的工作机制、框架产物、特性开关、错误处理、typescript支持等方面出发，讨论了框架设计者再设计框架应该考虑的内容。

第3章从全局介绍vue.js 3.0的设计思路，以及各个模块之间如何协作。

第二篇响应系统

第4章从宏观介绍vue.js3.0的响应系统的实现机制。从副作用函数开始，逐步实现一个完善的响应系统，还讲述了计算属性和watch的实现原理，同时讨论了在实现相应系统的过程中所遇到的问题，以及相应的解决方案。

第5章从ECMAScript规范入手，从最基本的proxy、reflect以及js对象的工作原理开始，逐步讨论了使用proxy代理js对象的方式。

第6章主要讨论了ref的概念，并基于ref实现原始值的响应式方案，还讨论了如何使用ref解决响应丢失的问题。

第三篇渲染器

第7章主要讨论了渲染器与响应系统的关系，讲述了两者如何配合完成页面更新。渲染器的一些基本名词和概念，以及自定义渲染器的实现与应用。

第8章渲染器的挂载与更新的实现原理，其中包括子节点的处理、属性的处理和事件的处理。当挂载或更新组件类型的虚拟节点时，还要考虑组件生命周期函数的处理等。

第9章主要讨论了简单Diff算法的工作原理。

第10章主要讨论了双端Diff算法的工作原理。

第11章主要讨论了快速Diff的工作原理。

第四篇组件化

第12章主要讨论了组件的实现原理，介绍了组件自身状态的初始化，以及由自身状态变化引起的组件自更新，还介绍了组件的外部状态props、由外部状态变化引起的被动更新，以及组件事件和插槽的实现原理。

第13章异步组件和函数式组件的工作机制和实现原理。对于异步组件，我们还讨论了超时与错误处理、延迟展示loading组件、加载重试等内容。

第14章vuejs内建的三个组件的实现原理，即keepalive teleport和transition的组件。

第五篇编译器

第15章讨论vuejs模板编译器的工作流程，接着讨论了parser的实现原理与状态机，以及AST的转换与插件化架构，最后讨论了生成渲染函数代码的具体实现。

第16章主要讨论了如何实现一个符合whatwg组织的HTML解析规范的解析器，内容涵盖解析器的文本模式、文本模式对解析器的影响，以及如何使用递归下降算法构造模板AST。在解析文本内容时，我们还讨论了如何根据规范解码字符引用。

第17章模板编译优化的相关内容。具体包括block树的更新机制、动态节点的收集、静态提升、预字符串、缓存内联事件处理函数、v-once等优化机制。

第六篇服务器端

主要讨论了同构渲染的原理，探讨了CSR、SSR以及同构渲染等方案的各自优缺点，然后探讨了vuejs进行服务端和客户端即获得原理，最后总结了编写同构代码时的注意事项。

图片版本

单文件组件 SFC

在大多数启用了构建工具的VUE项目中，我们可以使用一种类似HTML格式的文件来书写VUE组件，它被称为单文件组件，也被称为*.vue文件。英文single-file components缩写为SFC。顾名思义，vue的单文件组件会将一个组件的逻辑 js模板html 和样式css封装在同一个文件里。

VUE3中选项式API optionsAPI

使用选项式API我们可以用包含多个选项的对象来描述组件的逻辑，例如data、methods和mounted。选项所定义的属性都会暴露在函数内部的this上，它会指向当前的组件实例。

 

组合式API compositionAPI

通过组合式API，我们可以使用导入的API函数来描述组件逻辑。在单文件组件中，组合式API通常会与<script setup>中的导入和顶层变量、函数都能够在模板中直接使用

之前电脑装过各种环境，直接乱了。重新卸载node npm后再安装nvm。亲测可用，简单快速

1、卸载node、npm

brew uninstall node

2、以上卸载完成后，继续清理

which node

//可以看到 /usr/local/bin/node

which npm

//可以看到 /usr/local/lib/node_modules/

//全部删除，通过以下两句

sudo rm -rf /usr/local/bin/node
sudo rm -rf /usr/local/lib/node_modules/

//删除全局node模块注册的软链 
cd /usr/local/bin && ls -l | grep "../lib/node_modules/" | awk '{print $9}'| xargs sudo rm

3、安装 nvm

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash

4、关闭重启命令窗口,验证nvm版本
nvm --vesion

1. 什么是语法糖？‌

语法糖（Syntactic Sugar）是由英国计算机科学家彼得·约翰·兰达提出的术语，指编程语言中添加的某种语法，这种语法对语言的功能没有影响，但更方便程序员使用。它通过简化代码结构，使代码更易读、更符合人类的思维习惯。

2. 语法糖的作用

• ‌提高可读性‌：简化代码结构，使代码更直观，更容易被其他开发者理解。
• ‌减少错误‌：由于语法糖通常让代码更简洁，因此可以减少因复杂代码而导致的错误。
• ‌提升效率‌：开发人员能够更快地写出正确的代码，从而提高编码效率。

3. 语法糖的示例

• ‌C语言‌：用 a[i] 表示 *(a+i)，用 a[i][j] 表示 *(*(a+i)+j)。
• ‌Java‌：自动装箱/拆箱、增强的 for 循环、泛型以及Lambda表达式。
• ‌Python‌：列表推导式、字典推导式、集合推导式、生成器表达式。
• VUE：v-bind:src=>:src v-on:click => @click

4. 语法糖的意义

语法糖不仅是一种便捷的写法，编译器会帮我们做转换，而且可以提高开发编码的效率，在性能上也不会带来损失。它与其他编程思想一样重要，如duck type、人本接口、最小接口、约定优于配置等，广义来讲都是一些思想上的“语法糖”。

5. 语法糖的争议

尽管语法糖带来了诸多便利，但也有反对的声音。例如，图灵奖的第一个获得者Alan Perlis曾对此提出质疑。然而，大多数开发者认为，语法糖是一种让编程语言更加用户友好、更具表现力的方式。

通过以上分析，我们可以看到，语法糖在编程语言中扮演着重要角色，它不仅简化了代码，还提高了开发效率和代码的可读性。

最近在看SLA，看到里面一个词叫混沌工程，故整理一下。

定义：混沌工程是一门对系统进行实验的学科，旨在了解系统对应生产环境的各种混乱状况的能力，建立对系统的信心。所有系统的用户都希望系统具备可靠性，但影响可靠性的因素有很多。混沌工程师能找到证据，指明那些异常但不可回避的状况下系统的应变情况。

简单来说：混沌工程是在分布式系统上进行实验的学科，目的是建立对该系统能够承受生产环境的动荡的信心。

我们的用户将 TiDB 运行在国内某云厂商的机器上面，然后跟我们反映，读延迟会不定期的增长，我们看了看监控，发现唯一的异常指标就是 Cached 的 memory 那段时间会突然下降。当时真的就懵逼了，完全不知道是为啥，最终发现，云厂商的运维监控脚本里面有个 bug，会不定期的将磁盘热拔插，并且将现有的 page cache 刷到磁盘，所以那段时间 TiDB 的 read 操作很多是从磁盘重新读取数据的。

可以看到，分布式系统真的是一个非常复杂的系统，故障无处不在，那么我们如何在这么复杂的分布式系统的世界里面生存下去呢？现在，一个很好的答案就是 – Chaos Engineering，中文里面叫做混沌工程。

混沌工程

相比于我们成天担惊受怕系统会出现什么样的问题，还不如提前就模拟线上环境可能出现的各种情况，来看我们的系统是否能做到容错，仍然能继续对外提供服务。当然，我们并不是简单的就在线上环境上面，把机器给断电，或者把网线给拔掉，在混沌工程领域，有一套指导原则，以及标准的实验步骤，具体的可以参考 PRINCIPLES OF CHAOS ENGINEERING 。

简单来说，要做一次混沌实验，我们只需要做到如下的 4 个步骤：

1. 定义系统的稳态，这个稳态就是系统在正常运行的时候一些指标，譬如当前请求的 QPS，latency 这些。
2. 将系统分为实验组以及对照组，做出一个假设，譬如我在实验组引入一个故障，这个稳态仍然能在实验组保持。
3. 执行试验，给实验组引入现实世界中的故障，譬如拔掉网卡。
4. 验证第 2 步的假设是否成立，如果实验组的稳态跟对照组不一样了，证明我们的系统在第 3 步的故障中不能很好的容错，所以我们需要改进。

可以看到，上面的步骤非常的简单，但要在实际从很好的做混沌试验，还是有一些困难的，主要在以下几点：

1. 自动化，我们需要有一套自动化的系统帮我们进行故障注入，进行假设对比等。
2. 尽可能多的引入不同故障。现实环境中可能会出现非常多的故障，仅仅不是拔网线这么简单，所以引入的故障越多越好。
3. 业务方无感知。如果我们每次做混沌试验，都要业务系统去配合，譬如在业务里面写一些混沌相关的代码，让混沌试验调用，或者更改系统的部署逻辑，跟混沌试验配合，这种的就属于紧耦合的。

你好，ChaosMesh！！！

所以，为了让大家更好的做混沌试验，我们开发了 ChaosMesh，ChaosMesh 是一套基于 Kubernetes 的云原生混沌工程平台。ChaosMesh 的架构如下：

相比于其他混沌平台，ChaosMesh 有如下优势：

1. 基于 K8s，只要你的系统能跑在 K8s 上面，那么就可以无缝的集成 ChaosMesh，而且不用修改任何业务代码，真正是被测系统无感知。
2. 多种多样的故障注入。ChaosMesh 能全方位的帮你对网络，磁盘，文件系统，操作系统等进行故障注入。我们后面也会提供对 K8s，或者云服务自身进行 chaos 的能力。
3. 易于使用，你无需关注 ChaosMesh 的底层实现细节，只需用 YAML 配置好混沌试验，就可以实施，后面所有的实验是全自动化的。我们也提供了 Dashboard 能让你在网页上就轻松的进行试验。
4. 可观测性，ChaosMesh 的 Dashboard 能很方便的让你观测系统，知道什么时候进行了什么试验，知道你自己的系统当前的运行情况，当然，这里需要一点配置，你需要告诉 ChaosMesh 如何去获取你系统的稳态指标，譬如你的系统使用 Prometheus，那么就可以告诉 ChaosMesh 如何去 Prometheus 查询相关的监控指标。
5. 强大的开源社区支持，ChaosMesh 的社区成长的非常迅速，我们非常高兴的看到大部分的功能已经由社区支持，并且也有很多用户。你无需担心遇到问题不知道如何解决，当然，你可能要担心下 ChaosMesh 做实验的时候把你的数据给完全干掉，所以做实验的时候一定要控制好实验半径，这个也是混沌工程的一条原则。

来一次 Chaos 实验？

在我们开始一次 Chaos 实验之前，你首先需要满足两个条件：

1. 你自己的业务是跑在 K8s 上面的
2. 在 K8s 上面安装了 ChaosMesh

另外，在开始实验之前，这里我还是要强调一下 Chaos 实验的一些注意事项，可能你觉得我这个大叔很啰嗦，但小心驶得万年船，因为稍微一不注意，你可能就丢了数据了。

1. 如果你刚准备将你的系统应用 ChaosMesh，一定要保证首先在测试环境中使用。你的系统应该还非常的脆弱，如果在线上进行试验，会非常的危险。
2. 在生产系统中，一定要控制好试验的爆炸半径，控制好影响范围，譬如我们可以先对某一个街道的用户进行干扰，然后在扩大到某一个区域，或者某一个城市，如果我们一开始的影响半径就很大，一个稍微不留意，你的 boss 就可能让你第二天滚蛋了。
3. 做混沌实验一定不是随机的瞎做实验，我们是带有目的的，是需要规划好的，与其漫无目的的对系统随机进行故障注入，我们还不如先问自己一个问题『为了对系统在混乱状况下的表现更有信心，在哪里做混沌实验最有价值？』也就是我们要熟悉了解我们的系统，做高杠杆价值的混沌实验。

好了，现在你已经完全准备好了，现在就可以踏上混沌之旅了，因为 ChaosMesh 的使用是如此简单，你只需要参考 用户指南 就能上手使用，所以我就不过多介绍了，如果你仍然遇到了问题，欢迎给 ChaosMesh 提 issue，相信我，ChaosMesh 社区会很热情的帮你解决问题的。

总结

随着 ServiceMesh，Serverless 等理念的兴起，我们的系统真的趋向于越来越分布式，这样虽然简化了我们单个模块的实现，但整体来看，也可能会导致我们的系统因为过于分布式而变得复杂，那么如何在这种复杂的环境下仍然让我们有信心能保证系统能正常稳定运行，混沌工程可以算是一个很不错的选择。

现在市面上面，支持混沌工程的平台已经有很多了，但我这里仍然推荐 ChaosMesh，毕竟使用它能让你极大提升你对系统的信心。

该咋做混沌工程？

在讨论咋做混沌工程之前，让我们先回答下面5个问题。

什么是混沌工程？

先说一个能说出点名堂的我个人对混沌工程的理解，**混沌工程，是Netflix公司当面对具有不可预知的“暗债”的复杂系统时，在“目标一致，关系宽松”的企业文化下，“逼上梁山”的结果**。

什么是“暗债”？这个词来源于2017年发表的一篇名为[STELLA](https://snafucatchers.github.io/)的报告。这份报告由一群韧性工程专家在聚会后所撰写。就在他们聚会的那几天，这群专家赶上了一场极具破坏性的暴风雪。而那场暴风雪的名字，就是 STELLA。

**暗债**，指当复杂系统内部子系统间相互作用时，所**必然存在**的**不可预知**的漏洞，最终会由此引发系统的意外故障。

再说说上面那个“除了‘实验’貌似啥也没说”的定义。

2015年，Netflix将混沌工程正规化，主持起草了[混沌工程原则](https://principlesofchaos.org/?lang=ENcontent)，并给混沌工程下了定义。

混沌工程是在分布式系统上进行实验的学科，目的是建立对该系统能够承受生产环境的动荡的信心。

“貌似啥也没说”的背后，其实这个定义是大有深意的。

• 分布式系统就是一种复杂系统，其活动规律是**不可预知和非线性的**。详情参见我之前撰写的[“不可能构建第二个云环境去做测试”](“不可能构建第二个云环境去做测试”——为复杂混沌的微服务生产环境设计韧性系统 v0.11)和[“混沌工程与系统稳定性设计模式”](https://myslide.cn/slides/22341)
• 生产环境的动荡，来源于复杂系统内部**所固有的“暗债”**。见与不见，暗债就在那里，不增不减
• 具有“可证伪性”的科学实验，只关注所定义的稳态是否被证伪，而对于**具体采取哪种方法保持稳态，不做要求**，悉听尊便，这就孕育了混沌猴
• 要建立对系统能够承受生产环境的动荡的信心，需要**针对生产环境“丰富多彩”的暗债，设计同样“丰富多彩”的防范手段**。依据是控制论学者艾什比的[必要多样性法则（Law of Requisite Variety）](艾什比定律_百度百科)——要实现控制，控制系统能够执行的行为的多样性，必须不低于需要应对的环境动荡的多样性
• 一个不断演化的分布式系统的复杂性，只会增加，而不会减少。依据是著有《人月神话》的那位大神Frederick Brooks的一篇文章中所谈到的两类复杂性（偶然复杂性与本质复杂性），都不会减少，甚至有一类还会增加。

其中，偶然复杂性，是在资源有限的条件下，对相互冲突的限制条件作出权衡后的必然结果。

不存在已知的可持续方法，能减少偶然复杂性，因为资源总是有限的，权衡总是要做出的，暗债总是要欠下的。

而本质复杂性，是满足不断增加的新需求的必然结果。一个不断演化的分布式系统，新需求能少得了吗？

混沌工程和测试有什么区别？

两者的运行环境有区别。

测试一般运行在**测试环境**上，而混沌猴一般运行在**生产环境**上。因为生产环境必然存在不可预知且与测试环境不同的暗债，所以对测试环境所建立的信心，并不能用在生产环境上。

两者的侧重点也有区别。

测试一般只关注**已知**的断言是否通过，而混沌工程会更关注发现更多**未知**的暗债。

混沌工程和故障演练啥区别？

两者的侧重点有区别。

故障演练侧重操练**已知**的故障应对过程，而混沌工程侧重通过实验发现**未知**的暗债。

生产环境是不允许引入任何风险的。如果混沌工程是在生产环境上做实验，那风险多大呀。领导会答应吗？

前面提到，暗债是生产系统这个复杂系统所固有且不可预知的。那么即使不人为地引入风险，生产环境也是遍布暗债的。不在生产环境进行最小化爆炸半径的实验，来发现暗债，那么**只能任凭暗债在最不希望发生的时刻爆发**。

该咋做混沌工程？

借鉴Netflix的实例，可以从“摆正心态、人员主动和试点业务”三方面入手，来启动混沌工程。

### 摆正心态

承认暗债为复杂系统所固有，而不是一味要求工程师[“不能也不该出现失误”](6月27日阿里云故障说明-阿里云开发者社区)。否则在故障面前，大家就只会花大量时间相互甩锅，耽误了发现更多暗债和防范措施。

### 人员主动

前面说过，根据必要多样性法则，要建立对系统能够承受生产环境的动荡的信心，需要针对生产环境“丰富多彩”的暗债，设计同样“丰富多彩”的防范手段。而技术骨干一个人，是发现不了那么多暗债，并找到那么多的防范手段的。所以，就需要发挥各位工程师的主动性。此时，领导者要创造能调动工程师主动性和创造性的企业文化，来促进工程师更安全地发现与修复更多“花样”的暗债。在修复暗债的过程中，就可以使用文章[【分布式系统稳定性设计入门】如果不想总是半夜爬起来抢修生产事故……《发布！》第2版解读](【分布式系统稳定性设计入门】如果不想总是半夜爬起来抢修生产事故……《发布！》第2版解读 v0.2)所介绍的“分布式系统稳定性设计关键清单”。

### 试点业务

• 选择一个出现生产事故频率较高的业务系统，尝试混沌工程。因为事故的反复，出现会让发现与解决暗债的动力更大
• 基于能反映用户体验的业务稳态行为建立假设，而不是先聚焦于在系统内寻找弱点。因为这样能更利于进行全局优化，让成效更大
• 为了让暗债浮现出来，设计引入足够多样化的现实世界可能发生的事件，而不是设计那些易于生成但在现实中不大可能出现的事件，以便切中要害。针对每一个所引入的事件，参考上述“分布式系统稳定性设计关键清单”，来进行稳定性设计
• 可以先从准生产环境入手进行混沌实验，等条件成熟后，再逐渐过渡到生产环境
• 自动化地持续进行混沌实验，以起到回归实验的效果，持续发现并解决暗债，避免系统随着时间的推移，在韧性方面逐渐“掉队”
• 设计更安全的实验方式，以最小化爆炸半径，让实验所导致的业务损失降到最低，而不是明知故障难以控制，还要贸然进行实验。如果实验的假设被证伪，那么就遇到了发现新的暗债的好机会。在寻找暗债的过程中，可以参考上述“分布式系统稳定性设计关键清单”，来启发寻找漏洞及修复

混沌工程的唯一目标就是证明系统存在缺陷。通过开展混沌工程方面的科学实验，你可以测试系统是否存在缺陷，从而了解系统在混乱的类生产环境条件下如何表现。

混沌工程属于一门新兴的技术学科，行业认知和实践积累比较少，大多数IT团队对它的理解还没有上升到一个领域概念。阿里电商域在2010年左右开始尝试故障注入测试的工作，希望解决微服务架构带来的强弱依赖问题。

参考来源1：https://zhuanlan.zhihu.com/p/149599011
参考来源2：https://zhuanlan.zhihu.com/p/149419512

onShareAppMessage: function() {
	wx.showShareMenu({
	      withShareTicket: true,
	      menus: ['shareAppMessage', 'shareTimeline']
      })
      return {
        title: '帮我选车',
        path: ''
	    }
	},
	//用户点击右上角分享朋友圈
	onShareTimeline: function () {
		return {
	      title: '帮我选车',
	      query: {
	        key: ''
        },
	      imageUrl: ''
	    }
	},

体验版已支持iOS和android，只是微信官方文档还未做更新

• 

• 

• 

• 

• 

昨天和牡丹下山，在逛了n个地方后，我们找了一块靠近松月湖的凉快的小树林休息。我们坐着边聊边看风景，后来我注意到有一只蚂蚁扛着一只比它自身大四五倍的大虫子飞快的走动着。

不一会儿走到了一根树枝前方，它拖动着虫子艰难的想翻过去。可是怎么也翻不过去，如果它把它的食物扔掉它就能很快的爬过去，可是拖动着虫子总是被绊住，它尝试了七八次就在那个小树枝的范围，无论怎样努力也拖动不过去。牡丹看着说：“我们就是上帝视角“，想到蚂蚁可以换个方向来个曲线绕过去，可是蚂蚁不知道，它继续尝试，终于决定稍稍绕一点弯，可是树枝相对于它来说还是有长，它还是需要翻过树枝，还是失败了。

牡丹不忍心就轻轻的把拦在它面前的树枝给拿掉了。蚂蚁顺利的拖着食物过去了。它会感慨什么吗？

我在想，天道酬勤是不是就是老天看我们就像蚂蚁，我们持之以恒的撞南墙撞了好多次，失败了好多次的继续撞南墙，最后老天也不忍心看下去了，就轻轻的把拦在我们面前的障碍给拿掉了。我们就恍若如神助直达目标。就像稻盛和夫在《活法》里面写的自己，绞尽脑汁的做实验，百思不得其解找不到合适的材料，终于某天他又思考着进实验室，突然被某个容器绊了一下，下意识一看脚下，发现了松香。他立即拿松香做起了实验，那么令人头痛的难题居然一下子就解决了！他就感慨道“看到我那么拼命的工作，那样苦苦思索，神都看不过去了，神可怜我，赋予了我智慧。我想事情只能这样来解释”。

现在疫情很严重，我们都戴口罩😷，有的时候我觉得可能老天会看到我们戴着口罩，是不是就像我们看到仓鼠🐹可可爱爱的戴着口罩，严谨的戴着口罩，也许老天会放我们一条生路。当然我们的医生更伟大，全心全意，专心致志的研究疫苗，是不是老天也可以给他们启示呢？

做事情就要全力以赴，认真的工作也会锤炼自己的性格。