装饰器模式的核心在于在不改变对象/函数的前提下，给该对象/函数添加功能，使其功能更强大，能应对更复杂的需求场景。

打个比方，就好比龙珠里的孙悟空可以变身为超级赛亚人，变成超级赛亚人的孙悟空依然具备普通状态下孙悟空的能力，不过变得更强了。

我们在前端开发中，肯定会封装接口请求方法。一般来说，我们会封装好通用的通用的请求方法，然后在业务层传入配置项（url, method 等）调用该方法。如果有些场景需要添加额外的信息，比如 Accept-Language 等参数之类的，就可以通过装饰器模式来实现。

假如我们已经事前封装好了一个前端通用的请求函数 request, 我们把配置项传入 request，它可以发送请求。
然后可以根据应用场景定义一个装饰函数 requestDecorator：

1
2
3
4
5
6
7
8
9
10

const requestDecorator = (params) => {
  const teamId = getTeamId();
  const locale = getLocale();
  params.headers = {
    ...params.headers,
    "Accept-Language": locale,
    "Team-Id": teamId,
  };
  return request(params);
};

可以看到，requestDecorator 主要作用是为 request 的入参添加”Accept-Language”和”Team-Id”，这就是一个简单的装饰器。

最后，业务层代码可以调用 requestDecorator 来完成请求任务，例如我们要写一个获取 userInfo 的功能：

1
2
3
4
5
6
7
8
9

const getUserInfo = (params) => {
  return requestDecorator({
      url: '/api/user_info',
      method: 'GET',
      params,
    }),
};

getUserInfo()

以上就是一个装饰器模式的应用例子。

策略模式在日常开发中的使用场景还是比较多的，举一个常见的例子，我们平时很可能会处理表格中数据项的操作功能，例如：

（图片是从 element-plus 官方文档截的。）

日常开发中，我们往往会处理好几个数据项的操作，每个操作都需要执行不同的逻辑。而处理这些逻辑时，我们往往会考虑使用 switch 语句或者 ifelse 语句，去根据不同操作执行不同的逻辑。

其实这种场景就非常适合用策略模式来处理，策略模式能有效的减少代码中 ifelse 语句的数量，并且它利于维护，它符合【开放-封闭】原则，以后添加功能时，只需要在原来基础上再加策略，而不用改动核心逻辑，引入 bug 的可能性较低。

例如我们有 a,b,c,d 四种操作，每种操作分别对应不同后续需要执行的逻辑：

1
2
3
4
5
6
7
8
9
10
11
12

const handleA = (row) => {
  // do something about row...
};
const handleB = (row) => {
  // do something about row...
};
const handleC = (row) => {
  // do something about row...
};
const handleD = (row) => {
  // do something about row...
};

我们把这些逻辑都封装好，放到一个对象里：

1
2
3
4
5
6

const optObj = {
  a: handleA,
  b: handleB,
  c: handleC,
  d: handleD,
};

然后写一个函数来承接操作，该函数会调用 optObj 来完成具体逻辑的分发处理：

1
2
3
4
5

const handleOpt = (opt) => {
  // opt是a/b/c/d
  const fn = optObj[opt];
  fn && fn();
};

这样，一个策略模式的简单应用就完成了。

[美] 雷·布拉德伯里

深夜，威尔斯夫妇离开电影院，走进了一家安静的小店之中。这是一家餐厅，兼营熟食。他们在一个小隔间里坐下来，威尔斯夫人说道：“裸麦粗面包，上面加烤火腿。”威尔斯先生望向柜台，那里正放着一条裸麦粗面包。

“为什么，”他喃喃地说，“裸麦粗面包 ⋯⋯ 德鲁斯湖 ⋯⋯”

夜深人静的时刻，空荡荡的餐馆——这场景愈发熟悉。任何事物都能将他卷入回忆之潮。秋叶的气味，或是午夜之风的吹拂，都能够搅动他的回忆，于是过往的记忆淋洒在他的身上。此时，在这个电影散场后的虚幻时刻，在这家孤独的商店里，他看到了一条裸麦粗面包，正如成千个其他夜晚，他发现自己开始回忆过去。

“德鲁斯湖。”他重复了一遍。

“你说什么？”妻子抬头瞥了他一眼。

“我几乎忘掉的事情。”威尔斯先生说道，“在 1910 年，我二十岁的时候，把一条裸麦粗面包钉在了衣柜的镜子上 ⋯”

在面包那带有阳光色泽的坚硬外壳上，德鲁斯湖畔的男孩子们刻下了他们的名字：汤姆、尼克、比尔、亚历克、保罗、杰克。这是史上最棒的野餐！他们在积满灰尘的小路上玩闹，晒黑了脸庞。那时的道路还满是尘土；棕色、细腻的滑石粉会在你的车后漫天飞扬。而那时在湖边玩耍的时光，总是比之后衣着整洁、没有一丝褶皱的时候要快乐得多。

“那是我们那群老伙计最后一次聚在一起了。”威尔斯先生说道。

在那之后，学业、工作和婚姻会将你们分开。你会突然发现自己身处其他圈子之中。而你再也不会感受到那样的闲适和轻松了。

第 1 章 重构，第一个示例

这是我个人的编码风格：永远将函数的返回值命名为“result”

如果重构引入了性能损耗，先完成重构，再做性能优化。

好代码的检验标准就是人们是否能轻而易举地修改它。

小的步子可以更快前进，请保持代码永远处于可工作状态，小步修改累积起来也能大大改善系统的设计。

“所有漂泊的人生都梦想着平静、童年、杜鹃花，正如所有平静的人生都幻想伏特加、乐队和醉生梦死。”
——萨冈

“人们很少做他们相信是对的事，他们做比较方便的事，然后后悔。”
——鲍勃迪伦

“平时你有过觉得无聊的时候吗?

我的字典里没有这个词。看到我可以一连好几天就那么站在窗边，望着窗外，我妻子都惊呆了。乍一看，那时的我好似表情呆滞，但其实内心并非如此。维特根斯坦曾经说过，由屋内关闭着的窗户望出去，看到路上有个男人奇怪地挥舞着手臂。你没法看到或是听到外头的暴风咆哮嘶吼，所以你不知道这男人光是想要站定，就得付出多大的努力。我们每个人的内心，都有隐藏着的风暴。”
——赫尔佐格《陆上行舟：赫尔佐格谈电影》

愤怒是一个累赘，生命短暂，不值得愤世嫉俗。

——《美国 X 档案》

HTTP 协议在不断演进，从 HTTP/1.x 到 HTTP/2，现在的 HTTP/3 也在演进中。对性能的追求是 HTTP 协议演进的主要目的之一。

HTTP2

就 HTTP/2 而言，其提高性能的主要手段有连接复用、头部压缩和 Server Push。

连接复用

HTTP 协议是基于 TCP 协议的，而 TCP 协议则是面向连接的。对于 HTTP/1 的请求—响应来说，每次请求就意味着一次 TCP 连接，而 TCP 连接的耗时是比较高的，而维持大量的 TCP 连接也会占用服务器端的资源，对同一个客户端& 服务器端建立多个 TCP 连接来传输多个请求—响应显然是一种浪费。

HTTP1 还有队头阻塞问题，由于 HTTP 请求—响应是一一对应的，使用同一个连接发送多个 HTTP 请求会产生队头阻塞问题，即第二个请求需要等待第一个请求返回后才能发起。

在这种情况下，虽然多个请求可以复用同一个 TCP 连接而不是关闭重新建立连接（HTTP1 可以重复利用 TCP 连接），但是请求只能排队逐个进行，第二个请求必须等待第一个请求的响应返回后才能发起，即使它们之间不存在任何依赖关系。为了实现并行请求，客户端（浏览器）可以同时建立多个 TCP 连接来并发发送多个 HTTP 请求，但由于 TCP 连接的建立和维持需要成本，因此浏览器一般以域名为维度限制 TCP 连接的并发数，这个数字大多数是 6。

HTTP/2 对此提出了更根本的解决方案，即让 HTTP 在单个 TCP 连接内可以发送多个请求，并且可以乱序返回。

在开启 HTTP/2 的情况下，浏览器只建立了一个请求，所有的请求都是并行发起的，响应的时间也和先后无关，这样整体的响应时间得以提前。

原型链继承

利用原型链让一个构造函数的原型指向另一个构造函数的实例，从而实现继承。但是原型链继承存在一些问题，比如引用类型值的共享和在创建子类型的实例时无法向超类型传递参数等。

1
2
3
4
5
6
7
8
9
10
11
12

function Parent() {
    this.name = 'Parent';
}

function Child() {
    this.age = 5;
}

Child.prototype = new Parent();

const child = new Child();
console.log(child.name); // 输出: Parent

强制缓存和协商缓存都是浏览器在加载网页时使用的缓存机制。

强制缓存是指浏览器在第一次请求资源时，服务器返回资源时会附带一个过期时间（Expires）或者验证标识（Cache-Control），浏览器在过期时间之前不会再次请求该资源，直接从缓存中加载资源。这样可以减少服务器的负载，提高网页加载速度。但缺点是，如果资源在服务器上有更新，浏览器无法知道，只能使用缓存的老版本。

协商缓存则是在资源过期时，浏览器发起请求到服务器，询问是否需要重新下载资源。如果服务器返回 304（Not Modified）状态码，则表示资源未修改，可以继续使用缓存的资源。如果返回新的资源，浏览器会重新下载更新的资源并缓存起来。

常用的协商缓存机制包括使用 ETag（实体标识）和 Last-Modified（最后修改时间）来判断资源是否更新。

强制缓存和协商缓存可以同时使用，浏览器会先进行强制缓存的判断，如果命中强制缓存，则直接使用缓存的资源，不发起请求。如果未命中强制缓存，则发起请求并使用协商缓存的机制进行判断。

通过合理设置缓存策略，可以在一定程度上提高网页的加载速度，并减轻服务器的负载。

History模式和Hash模式都是前端路由的两种实现方式，它们的主要区别在于实现原理、URL的表现形式以及对服务器和SEO的影响。

实现原理：History模式使用HTML5的History API（pushState和replaceState方法）来实现页面的跳转，同时监听popstate事件来响应浏览器的前进后退功能。而Hash模式则通过监听hashChange事件来实现页面的跳转，前端js把当前hash地址对应的组件渲染到浏览器中。

URL的表现形式：History模式的URL路径不带#号，看起来更加美观。而Hash模式的URL路径中则包含#号以及后面的字符。

对服务器和SEO的影响：由于Hash模式中的hash值变化不会导致浏览器向服务器发出请求，因此它对服务器的压力较小，但是不利于SEO优化。而History模式在URL变化时会向服务器发送请求，服务器会返回对应的页面内容，因此可以更好地支持SEO优化，但是需要服务器端的支持。

总的来说，History模式和Hash模式各有优缺点，选择哪种模式取决于具体的应用场景和需求。如果更关心页面的美观性和用户体验，可以选择History模式；如果更关心服务器的性能和SEO优化，可以选择Hash模式。

作用域

作用域是一套规则，用于确定在何处以及如何查找变量（标识符）。这套规则用来管理引擎如何在当前作用域以及嵌套的子作用域中根据标识符名称进行变量查找。

作用域查找会在找到第一个匹配的标识符时停止。在多层的嵌套作用域中可以定义同名的标识符，这叫作“遮蔽效应”（内部的标识符“遮蔽”了外部的标识符）。抛开遮蔽效应，作用域查找始终从运行时所处的最内部作用域开始，逐级向外或者说向上进行，直到遇见第一个匹配的标识符为止。

无论函数在哪里被调用，也无论它如何被调用，它的词法作用域都只由函数被声明时所处的位置决定。

词法作用域意味着作用域是由书写代码时函数声明的位置来决定的。编译的词法分析阶段基本能够知道全部标识符在哪里以及是如何声明的，从而能够预测在执行过程中如何对它们进行查找。

JavaScript中有两个机制可以“欺骗”词法作用域：eval(..)和with。前者可以对一段包含一个或多个声明的“代码”字符串进行演算，并借此来修改已经存在的词法作用域（在运行时）。后者本质上是通过将一个对象的引用当作作用域来处理，将对象的属性当作作用域中的标识符来处理，从而创建了一个新的词法作用域（同样是在运行时）。这两个机制的副作用是引擎无法在编译时对作用域查找进行优化，因为引擎只能谨慎地认为这样的优化是无效的。使用这其中任何一个机制都将导致代码运行变慢。不要使用它们。