Merge branch 'master' of https://github.com/ascoders/weekly

fix: spelling mistake in 167

SQL/231.SQL 入门.md

@@ -0,0 +1,174 @@
+本系列是 SQL 系列的开篇，介绍一些宏观与基础的内容。
+
+## SQL 是什么？
+
+SQL 是一种结构化查询语言，用于管理关系型数据库，我们 90% 接触的都是查询语法，但其实它包含完整的增删改查和事物处理功能。
+
+## 声明式特性
+
+SQL 属于声明式编程语言，而现代通用编程语言一般都是命令式的。但是不要盲目崇拜声明式语言，比如说它未来会代替低级的命令式语言，因为声明式本身也有它的缺点，它与命令式语言也有相通的地方。
+
+为什么我们觉得声明式编程语言更高级？因为声明式语言抽象程度更高，比如 `select * from table1` 仅描述了要从 table1 查询数据，但查询的具体步骤的完全没提，这背后可能存在复杂的索引优化与锁机制，但我们都无需关心，这简直是编程的最高境界。
+
+那为什么现在所有通用业务代码都是命令式呢？因为 **命令式给了我们描述具体实现的机会** ，而通用领域的编程正需要建立在严谨的实现细节上。比如校验用户权限这件事，即便 AI 编程提供了将 “登陆用户仅能访问有权限的资源” 转化为代码的能力，我们也不清楚资源具体指哪些，以及在权限转移过程中的资源所有权属于谁。
+
+SQL 之所以能保留声明式特性，完全因为锁定了关系型数据管理这个特定领域，而恰恰对这个领域的需求是标准化且可枚举的，才使声明式成为可能。
+
+基于命令式语言也完全可拓展出声明式能力，比如许多 ORM 提供了类似 `select({}).from({}).where({})` 之类的语法，甚至一个 `login()` 函数也是声明式编程的体现，因为调用者无需关心是如何登陆的，总之调用一下就完成了登陆，这不就是声明式的全部精髓吗？
+
+## 语法分类
+
+作为关系型数据库管理工具，SQL 需要定义、操纵与控制数据。
+
+数据定义即修改数据库与表级别结构，这些是数据结构，或者是数据元信息，它不代表具体数据，但描述数据的属性。
+
+数据操纵即修改一行行具体数据，增删改查。
+
+数据控制即对事务、用户权限的管理与控制。
+
+### 数据定义
+
+DDL（Data Definition Language）数据定义，包括 `CREATE` `DROP` `ALTER` 方法。
+
+### 数据操纵
+
+DML（Data Manipulation Language）数据操纵，包括 `SELECT` `INSERT` `UPDATE` `DELETE` 方法。
+
+### 数据控制
+
+DCL（Data Control Language）数据控制，包括 `COMMIT`、`ROLLBACK` 等。
+
+所有 SQL 操作都围绕这三种类型，其中数据操纵几乎占了 90% 的代码量，毕竟数据查询的诉求远大于写，数据写入对应数据采集，而数据查询对应数据分析，数据分析领域能玩出的花样远比数据采集要多。
+
+PS：有些情况下，会把最重要的 `SELECT` 提到 DQL（Data Query Language）分类下，这样分类就变成了四个。
+
+## 集合运算
+
+SQL 世界的第一公民是集合，就像 JAVA 世界第一公民是对象。我们只有以集合的视角看待 SQL，才能更好的理解它。
+
+何为集合视角，即所有的查询、操作都是二维数据结构中进行的，而非小学算术里的单个数字间加减乘除关系。
+
+集合的运算一般有 `UNION` 并集、`EXCEPT` 差集、`INTERSECT` 交集，这些都是以行为单位的操作，而各种 JOIN 语句则是以列为单位的集合运算，也是后面提到的连接查询。
+
+只要站在二维数据结构中进行思考，运算无非是横向或纵向的操作。
+
+## 数据范式
+
+数据范式分为五层，每层要求都比上一层更严苛，因此是一个可以逐步遵循的范式。数据范式要求数据越来越解耦，减少冗余。
+
+比如第一范式要求每列都具有原子性，即都是不可分割的最小数据单元。如果数据采集时，某一列作为字符串存储，并且以 "|" 分割表示省市区，那么它就不具有原子性。
+
+当然实际生产过程往往不都遵循这种标准，因为表不是孤立的，在数据处理流中，可能在某个环节再把列原子化，而原始数据为了压缩体积，进行列合并处理。
+
+希望违反范式的还不仅是底层表，现在大数据处理场景下，越来越多的业务采用大宽表结构，甚至故意进行数据冗余以提升查询效率，列存储引擎就是针对这种场景设计的，所以数据范式在大数据场景下是可以变通的，但依然值得学习。
+
+## 聚合
+
+当采用 GROUP BY 分组聚合数据时，如希望针对聚合值筛选，就不能用 WHERE 限定条件了，因为 WHERE 是基于行的筛选，而不是针对组合的。（GROUP BY 对数据进行分组，我们称这些组为 “组合”），所以需要使用针对组合的筛选语句 HAVING：
+
+```sql
+SELECT SUM(pv) FROM table
+GROUP BY city
+HAVING AVG(uv) > 100
+```
+
+这个例子中，如果 HAVING 换成 WHERE 就没有意义，因为 WHERE 加聚合条件时，需要对所有数据进行合并，不符合当前视图的详细级别。（关于视图详细级别，在我之前写的 [精读《什么是 LOD 表达式》](https://github.com/ascoders/weekly/blob/master/%E5%89%8D%E6%B2%BF%E6%8A%80%E6%9C%AF/215.%E7%B2%BE%E8%AF%BB%E3%80%8A%E4%BB%80%E4%B9%88%E6%98%AF%20LOD%20%E8%A1%A8%E8%BE%BE%E5%BC%8F%E3%80%8B.md) 有详细说明）。
+
+聚合如此重要，是因为我们分析数据必须在高 LEVEL 视角看，明细数据是看不出趋势的。而复杂的需求往往伴随着带有聚合的筛选条件，明白 SQL 是如何支持的非常重要。
+
+## CASE 表达式
+
+CASE 表达式分为简单与搜索 CASE 表达式，简单表达式：
+
+```sql
+SELECT CASE pv WHEN 1 THEN 'low' ELSE 'high' END AS quality
+```
+
+上面的例子利用 CASE 简单表达式形成了一个新字段，这种模式等于生成了业务自定义临时字段，在对当前表进行数据加工时非常有用。搜索 CASE 表达式能力完全覆盖简单 CASE 表达式：
+
+```sql
+SELECT CASE WHEN pv < 100 THEN 'low' ELSE 'high' END AS quality
+```
+
+可以看到，搜索 CASE 表达式可以用 “表达式” 描述条件，可以轻松完成更复杂的任务，甚至可以在表达式里使用子查询、聚合等手段，这些都是高手写 SQL 的惯用技巧，所以 CASE 表达式非常值得深入学习。
+
+## 复杂查询
+
+SELECT 是 SQL 最复杂的部分，其中就包含三种复杂查询模式，分别是连接查询与子查询。
+
+### 连接查询
+
+指 JOIN 查询，比如 LEFT JOIN、RIGHT JOIN、INNER JOIN。
+
+在介绍聚合时我们提到了，连接查询本质上就是对列进行拓展，而两个表之间不会无缘无故合成一个，所以必须有一个外键作为关系纽带：
+
+```sql
+SELECT A.pv, B.uv
+FROM table1 as t1 LEFT JOIN table2 AS P t2
+ON t1.productId = t2.productId
+```
+
+连接查询不仅拓展了列，还会随之拓展行，而拓展方式与连接的查询的类型有关。除了连接查询别的表，还可以连接查询自己，比如：
+
+```sql
+SELECT t1.pv AS pv1, P2.pv AS pv2
+FROM tt t1, tt t2
+```
+
+这种子连接查询结果就是自己对自己的笛卡尔积，可通过 WHERE 筛选去重，后面会有文章专门介绍。
+
+### 子查询与视图
+
+子查询就是 SELECT 里套 SELECT，一般来说 SELECT 会从内到外执行，只有在关联子查询模式下，才会从外到内执行。
+
+而如果把子查询保存下来，就是一个视图，这个视图并不是实体表，所以很灵活，且数据会随着原始表数据而变化：
+
+```sql
+CREATE VIEW countryGDP (country, gdp)
+AS
+SELECT country, SUM(gdp)
+FROM tt
+GROUP BY country
+```
+
+之后 `countryGDP` 这个视图就可以作为临时表来用了。
+
+这种模式其实有点违背 SQL 声明式的特点，因为定义视图类似于定义变量，如果继续写下去，势必会形成一定命令式思维逻辑，但这是无法避免的。
+
+## 事务
+
+当 SQL 执行一连串操作时，难免遇到不执行完就会出现脏数据的问题，所以事务可以保证操作的原子性。一般来说每个 DML 操作都是一个内置事务，而 SQL 提供的 START TRANSACTION 就是让我们可以自定义事务范围，使一连串业务操作都可以包装在一起，成为一个原子性操作。
+
+对 SQL 来说，原子性操作是非常安全的，即失败了不会留下任何痕迹，成功了会全部成功，不会存在中间态。
+
+## OLAP
+
+OLAP（OnLine Analytical Processing）即实时数据分析，是 BI 工具背后计算引擎实现的基础。
+
+现在越来越多的 SQL 数据库支持了窗口函数实现，用于实现业务上的 runningSum 或 runningAvg 等功能，这些都是数据分析中很常见的。
+
+以 runningSum 为例，比如双十一实时表的数据是以分钟为单位的实时 GMV，而我们要做一张累计到当前时间的 GMV 汇总折线图，Y 轴就需要支持 `running_sum(GMV)` 这样的表达式，而这背后可能就是通过窗口函数实现的。
+
+当然也不是所有业务函数都由 SQL 直接提供，业务层仍需实现大量内存函数，在 JAVA 层计算，这其中一部分是需要下推到 SQL 执行的，只有内存函数与下推函数结合在一起，才能形成我们在 BI 工具看到的复杂计算字段效果。
+
+## 总结
+
+SQL 是一种声明式语言，一个看似简单的查询语句，在引擎层往往对应着复杂的实现，这就是 SQL 为何如此重要却又如此普及的原因。
+
+虽然 SQL 容易上手，但要系统的理解它，还得从结构化数据与集合的概念开始进行思想转变。
+
+不要小看 CASE 语法，它不仅与容易与编程语言的 CASE 语法产生混淆，本身结合表达式进行条件分支判断，是许多数据分析师在日常工作中最长用的套路。
+
+现在使用简单 SQL 创建应用的场景越来越少了，但 BI 场景下，基于 SQL 的增强表达式场景越来越多了，本系列我就是以理解 BI 场景下查询表达式为目标创建的，希望能够学以致用。
+
+> 讨论地址是：[精读《SQL 入门》· Issue #398 · ascoders/weekly](https://github.com/ascoders/weekly/issues/398)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/ascoders/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
+
+

SQL/232.SQL 聚合查询.md

@@ -0,0 +1,199 @@
+SQL 为什么要支持聚合查询呢？
+
+这看上去是个幼稚的问题，但我们还是一步步思考一下。数据以行为粒度存储，最简单的 SQL 语句是 `select * from test`，拿到的是整个二维表明细，但仅做到这一点远远不够，出于以下两个目的，需要 SQL 提供聚合函数：
+
+1. 明细数据没有统计意义，比如我想知道今天的营业额一共有多少，而不太关心某桌客人消费了多少。
+2. 虽然可以先把数据查到内存中再聚合，但在数据量非常大的情况下很容易把内存撑爆，可能一张表一天的数据量就有 10TB，而 10TB 数据就算能读到内存里，聚合计算可能也会慢到难以接受。
+
+另外聚合本身也有一定逻辑复杂度，而 SQL 提供了聚合函数与分组聚合能力，可以方便快速的统计出有业务价值的聚合数据，这奠定了 SQL 语言的分析价值，因此大部分分析软件直接采用 SQL 作为直接面向用户的表达式。
+
+## 聚合函数
+
+常见的聚合函数有：
+
+- COUNT：计数。
+- SUM：求和。
+- AVG：求平均值。
+- MAX：求最大值。
+- MIN：求最小值。
+
+### COUNT
+
+COUNT 用来计算有多少条数据，比如我们看 id 这一列有多少条：
+
+```sql
+SELECT COUNT(id) FROM test
+```
+
+但我们发现其实查任何一列的 COUNT 都是一样的，那传入 id 有什么意义呢？没必要特殊找一个具体列指代呀，所以也可以写成：
+
+```sql
+SELECT COUNT(*) FROM test
+```
+
+但这两者存在微妙差异。SQL 存在一种很特殊的值类型 `NULL`，如果 COUNT 指定了具体列，则统计时会跳过此列值为 `NULL` 的行，而 `COUNT(*)` 由于未指定具体列，所以就算包含了 `NULL`，甚至某一行所有列都为 `NULL`，也都会包含进来。所以 `COUNT(*)` 查出的结果一定大于等于 `COUNT(c1)`。
+
+当然任何聚合函数都可以跟随查询条件 WHERE，比如：
+
+```sql
+SELECT COUNT(*) FROM test
+WHERE is_gray = 1
+```
+
+### SUM
+
+SUM 求和所有项，因此必须作用于数值字段，而不能用于字符串。
+
+```sql
+SELECT SUM(cost) FROM test
+```
+
+SUM 遇到 NULL 值时当 0 处理，因为这等价于忽略。
+
+### AVG
+
+AVG 求所有项均值，因此必须作用于数值字段，而不能用于字符串。
+
+```sql
+SELECT AVG(cost) FROM test
+```
+
+AVG 遇到 NULL 值时采用了最彻底的忽略方式，即 NULL 完全不参与分子与分母的计算，就像这一行数据不存在一样。
+
+### MAX、MIN
+
+MAX、MIN 分别求最大与最小值，与上面不同的是，也可以作用于字符串上，因此可以根据字母判断大小，从大到小依次对应 `a-z`，但即便能算，也没有实际意义且不好理解，因此不建议对字符串求极值。
+
+```sql
+SELECT MAX(cost) FROM test
+```
+
+### 多个聚合字段
+
+虽然都是聚合函数，但 MAX、MIN 严格意义上不算是聚合函数，因为它们只是寻找了满足条件的行。可以看看下面两段查询结果的对比：
+
+```sql
+SELECT MAX(cost), id FROM test -- id: 100
+SELECT SUM(cost), id FROM test -- id: 1
+```
+
+第一条查询可以找到最大值那一行的 id，而第二条查询的 id 是无意义的，因为不知道归属在哪一行，所以只返回了第一条数据的 id。
+
+当然，如果同时计算 MAX、MIN，那么此时 id 也只返回第一条数据的值，因为这个查询结果对应了复数行：
+
+```sql
+SELECT MAX(cost), MIN(cost), id FROM test -- id: 1
+```
+
+基于这些特性，最好不要混用聚合与非聚合，也就是一条查询一旦有一个字段是聚合的，那么所有字段都要聚合。
+
+现在很多 BI 引擎的自定义字段都有这条限制，因为混用聚合与非聚合在自定义内存计算时处理起来边界情况很多，虽然 SQL 能支持，但业务自定义的函数可能不支持。
+
+## 分组聚合
+
+分组聚合就是 GROUP BY，其实可以把它当作一种高级的条件语句。
+
+举个例子，查询每个国家的 GDP 总量：
+
+```sql
+SELECT SUM(GDP) FROM amazing_table
+GROUP BY country
+```
+
+返回的结果就会按照国家进行分组，这时，聚合函数就变成了在组内聚合。
+
+其实如果我们只想看中、美的 GDP，用非分组也可以查，只是要分成两条 SQL：
+
+```sql
+SELECT SUM(GDP) FROM amazing_table
+WHERE country = '中国'
+
+SELECT SUM(GDP) FROM amazing_table
+WHERE country = '美国'
+```
+
+所以 GROUP BY 也可理解为，将某个字段的所有可枚举的情况都查了出来，并整合成一张表，每一行代表了一种枚举情况，不需要分解为一个个 WHERE 查询了。
+
+### 多字段分组聚合
+
+GROUP BY 可以对多个维度使用，含义等价于表格查询时行/列拖入多个维度。
+
+上面是 BI 查询工具视角，如果没有上下文，可以看下面这个递进描述：
+
+- 按照多个字段进行分组聚合。
+- 多字段组合起来成为唯一 Key，即 `GROUP BY a,b` 表示 a,b 合在一起描述一个组。
+- `GROUP BY a,b,c` 查询结果第一列可能看到许多重复的 a 行，第二列看到重复 b 行，但在同一个 a 值内不会重复，c 在 b 行中同理。
+
+下面是一个例子：
+
+```sql
+SELECT SUM(GDP) FROM amazing_table
+GROUP BY province, city, area
+```
+
+查询结果为：
+
+```text
+浙江 杭州 余杭区
+浙江 杭州 西湖区
+浙江 宁波 海曙区
+浙江 宁波 江北区
+北京 .........
+```
+
+### GROUP BY + WHERE
+
+WHERE 是根据行进行条件筛选的。因此 GROUP BY + WHERE 并不是在组内做筛选，而是对整体做筛选。
+
+但由于按行筛选，其实组内或非组内结果都完全一样，所以我们几乎无法感知这种差异：
+
+```sql
+SELECT SUM(GDP) FROM amazing_table
+GROUP BY province, city, area
+WHERE industry = 'internet'
+```
+
+然而，忽略这个差异会导致我们在聚合筛选时碰壁。
+
+比如要筛选出平均分大于 60 学生的成绩总和，如果不使用子查询，是无法在普通查询中在 WHERE 加聚合函数实现的，比如下面就是一个语法错误的例子：
+
+```sql
+SELECT SUM(score) FROM amazing_table
+WHERE AVG(score) > 60
+```
+
+不要幻想上面的 SQL 可以执行成功，不要在 WHERE 里使用聚合函数。
+
+### GROUP BY + HAVING
+
+HAVING 是根据组进行条件筛选的。因此可以在 HAVING 使用聚合函数：
+
+```sql
+SELECT SUM(score) FROM amazing_table
+GROUP BY class_name
+HAVING AVG(score) > 60
+```
+
+上面的例子中可以正常查询，表示按照班级分组看总分，且仅筛选出平均分大于 60 的班级。
+
+所以为什么 HAVING 可以使用聚合条件呢？因为 HAVING 筛选的是组，所以可以对组聚合后过滤掉不满足条件的组，这样是有意义的。而 WHERE 是针对行粒度的，聚合后全表就只有一条数据，无论过滤与否都没有意义。
+
+但要注意的是，GROUP BY 生成派生表是无法利用索引筛选的，所以 WHERE 可以利用给字段建立索引优化性能，而 HAVING 针对索引字段不起作用。
+
+## 总结
+
+聚合函数 + 分组可以实现大部分简单 SQL 需求，在写 SQL 表达式时，需要思考这样的表达式是如何计算的，比如 `MAX(c1), c2` 是合理的，而 `SUM(c1), c2` 这个 `c2` 就是无意义的。
+
+最后记住 WHERE 是 GROUP BY 之前执行的，HAVING 针对组进行筛选。
+
+> 讨论地址是：[精读《SQL 聚合查询》· Issue #401 · ascoders/weekly](https://github.com/ascoders/weekly/issues/401)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/ascoders/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
+
+

SQL/233.SQL 复杂查询.md

@@ -0,0 +1,176 @@
+SQL 复杂查询指的就是子查询。
+
+为什么子查询叫做复杂查询呢？因为子查询相当于查询嵌套查询，因为嵌套导致复杂度几乎可以被无限放大（无限嵌套），因此叫复杂查询。下面是一个最简单的子查询例子：
+
+```sql
+SELECT pv FROM (
+  SELECT pv FROM test
+)
+```
+
+上面的例子等价于 `SELECT pv FROM test`，但因为把表的位置替换成了一个新查询，所以摇身一变成为了复杂查询！所以复杂查询不一定真的复杂，甚至可能写出和普通查询等价的复杂查询，要避免这种无意义的行为。
+
+我们也要借此机会了解为什么子查询可以这么做。
+
+### 理解查询的本质
+
+当我们查一张表时，数据库认为我们在查什么？
+
+这点很重要，因为下面两个语句都是合法的：
+
+```sql
+SELECT pv FROM test
+
+SELECT pv FROM (
+  SELECT pv FROM test
+)
+```
+
+为什么数据库可以把子查询当作表呢？为了统一理解这些概念，我们有必要对查询内容进行抽象理解：**任意查询位置都是一条或多条记录**。
+
+比如 `test` 这张表，显然是多条记录（当然只有一行就是一条记录），而 `SELECT pv FROM test` 也是多条记录，然而因为 `FROM` 后面可以查询任意条数的记录，所以这两种语法都支持。
+
+不仅是 `FROM` 可以跟单条或多条记录，甚至 `SELECT`、`GROUP BY`、`WHERE`、`HAVING` 后都可以跟多条记录，这个后面再说。
+
+说到这，也就很好理解子查询的变种了，比如我们可以在子查询内使用 `WHERE` 或 `GROUP BY` 等等，因为无论如何，只要查询结果是多条记录就行了：
+
+```sql
+SELECT sum(people) as allPeople, sum(gdp), city FROM (
+  SELECT people, gdp, city FROM test
+  GROUP BY city
+  HAVING sum(gdp) > 10000
+)
+```
+
+这个例子就有点业务含义了。子查询是从内而外执行的，因此我们先看内部的逻辑：按照城市分组，筛选出总 GDP 超过一万的所有地区的人口数量明细。外层查询再把人口数加总，这样就能对比每个 GDP 超过一万的地区，总人口和总 GDP 分别是多少，方便对这些重点城市做对比。
+
+不过这个例子看起来还是不太自然，因为我们没必要写成复杂查询，其实简单查询也是等价的：
+
+```sql
+SELECT sum(people) as allPeople, sum(gdp), city FROM test
+GROUP BY city
+HAVING sum(gdp) > 10000
+```
+
+那为什么要多此一举呢？因为复杂查询的真正用法并不在这里。
+
+### 视图
+
+正因为子查询的存在，我们才可能以类似抽取变量的方式，抽取子查询，这个抽取出来的抽象就是视图：
+
+```sql
+CREATE VIEW my_table(people, gdp, city)
+AS
+SELECT sum(people) as allPeople, sum(gdp), city FROM test
+GROUP BY city
+HAVING sum(gdp) > 10000
+
+SELECT sum(people) as allPeople, sum(gdp), city FROM my_table
+```
+
+这样的好处是，这个视图可以被多条 SQL 语句复用，不仅可维护性变好了，执行时也仅需查询一次。
+
+要注意的是，SELECT 可以使用任何视图，但 INSERT、DELETE、UPDATE 用于视图时，需要视图满足一下条件：
+
+1. 未使用 DISTINCT 去重。
+2. FROM 单表。
+3. 未使用 GROUP BY 和 HAVING。
+
+因为上面几种模式都会导致视图成为聚合后的数据，不方便做除了查以外的操作。
+
+另外一个知识点就是物化视图，即使用 MATERIALIZED 描述视图：
+
+```sql
+CREATE MATERIALIZED VIEW my_table(people, gdp, city)
+AS ...
+```
+
+这种视图会落盘，为什么要支持这个特性呢？因为普通视图作为临时表，无法利用索引等优化手段，查询性能较低，所以物化视图是较为常见的性能优化手段。
+
+说到性能优化手段，还有一些比较常见的理念，即把读的复杂度分摊到写的时候，比如提前聚合新表落盘或者对 CASE 语句固化为字段等，这里先不展开。
+
+### 标量子查询
+
+上面说了，WHERE 也可以跟子查询，比如：
+
+```sql
+SELECT city FROM test
+WHERE gdp > (
+  SELECT avg(gdp) from test
+)
+```
+
+这样可以查询出 gdp 大于平均值的城市。
+
+那为什么不能直接这么写呢？
+
+```sql
+SELECT city FROM test
+WHERE gdp > avg(gdp) -- 报错，WHERE 无法使用聚合函数
+```
+
+看上去很美好，但其实第一篇我们就介绍了，WHERE 不能跟聚合查询，因为这样会把整个父查询都聚合起来。那为什么子查询可以？因为子查询聚合的是子查询啊，父查询并没有被聚合，所以这才符合我们的意图。
+
+所以上面例子不合适的地方在于，直接在当前查询使用 `avg(gdp)` 会导致聚合，而我们并不想聚合当前查询，但又要通过聚合拿到平均 GDP，所以就要使用子查询了！
+
+回过头来看，为什么这一节叫标量子查询？标量即单一值，因为 `avg(gdp)` 聚合出来的只有一个值，所以 WHERE 可以把它当做一个单一数值使用。反之，如果子查询没有使用聚合函数，或 GROUP BY 分组，那么就不能使用 `WHERE >` 这种语法，但可以使用 `WHERE IN`，这涉及到单条与多条记录的思考，我们接着看下一节。
+
+### 单条和多条记录
+
+介绍标量子查询时说到了，`WHERE >` 的值必须时单一值。但其实 WHERE 也可以跟返回多条记录的子查询结果，只要使用合理的条件语句，比如 IN：
+
+```sql
+SELECT area FROM test
+WHERE gdp IN (
+  SELECT max(gdp) from test
+  GROUP BY city
+)
+```
+
+上面的例子，子查询按照城市分组，并找到每一组 GDP 最大的那条记录，所以如果数据粒度是区域，那么我们就查到了每个城市 GDP 最大的那些记录，然后父查询通过 WHERE IN 找到 gdp 符合的复数结果，所以最后就把每个城市最大 gdp 的区域列了出来。
+
+但实际上 `WHERE >` 语句跟复数查询结果也不会报错，但没有任何意义，所以我们要理解查询结果是单条还是多条，在 WHERE 判断时选择合适的条件。WHERE 适合跟复数查询结果的语法有：`WHERE IN`、`WHERE SOME`、`WHERE ANY`。
+
+### 关联子查询
+
+所谓关联子查询，即父子查询间存在关联，既然如此，子查询肯定不能单独优先执行，毕竟和父查询存在关联嘛，所以关联子查询是先执行外层查询，再执行内层查询的。要注意的是，对每一行父查询，子查询都会执行一次，因此性能不高（当然 SQL 会对相同参数的子查询结果做缓存）。
+
+那这个关联是什么呢？关联的是每一行父查询时，对子查询执行的条件。这么说可能有点绕，举个例子：
+
+```sql
+SELECT * FROM test where gdp > (
+  select avg(gdp) from test
+  group by city
+)
+```
+
+对这个例子来说，想要查找 gdp 大于按城市分组的平均 gdp，比如北京地区按北京比较，上海地区按上海比较。但很可惜这样做是不行的，因为父子查询没有关联，SQL 并不知道要按照相同城市比较，因此只要加一个 WHERE 条件，就变成关联子查询了：
+
+```sql
+SELECT * FROM test as t1 where gdp > (
+  select avg(gdp) from test as t2 where t1.city = t2.city
+  group by city
+)
+```
+
+就是在每次判断 `WHERE gdp >` 条件时，重新计算子查询结果，将平均值限定在相同的城市，这样就符合需求了。
+
+## 总结
+
+学会灵活运用父子查询，就掌握了复杂查询了。
+
+SQL 第一公民是集合，所以所谓父子查询就是父子集合的灵活组合，这些集合可以出现在几乎任何位置，根据集合的数量、是否聚合、关联条件，就派生出了标量查询、关联子查询。
+
+更深入的了解就需要大量实战案例了，但万变不离其宗，掌握了复杂查询后，就可以理解大部分 SQL 案例了。
+
+> 讨论地址是：[精读《SQL 复杂查询》· Issue #403 · ascoders/weekly](https://github.com/ascoders/weekly/issues/403)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/ascoders/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
+
+

SQL/234.SQL CASE 表达式.md

@@ -0,0 +1,154 @@
+CASE 表达式分为简单表达式与搜索表达式，其中搜索表达式可以覆盖简单表达式的全部能力，我也建议只写搜索表达式，而不要写简单表达式。
+
+简单表达式：
+
+```sql
+SELECT CASE city
+WHEN '北京' THEN 1
+WHEN '天津' THEN 2
+ELSE 0
+END AS abc
+FROM test
+```
+
+搜索表达式：
+
+```sql
+SELECT CASE
+WHEN city = '北京' THEN 1
+WHEN city = '天津' THEN 2
+ELSE 0
+END AS abc
+FROM test
+```
+
+明显可以看出，简单表达式只是搜索表达式 `a = b` 的特例，因为无法书写任何符号，只要条件换成 `a > b` 就无法胜任了，而搜索表达式不但可以轻松胜任，甚至可以写聚合函数。
+
+## CASE 表达式里的聚合函数
+
+为什么 CASE 表达式里可以写聚合函数？
+
+因为本身表达式就支持聚合函数，比如下面的语法，我们不会觉得奇怪：
+
+```sql
+SELECT sum(pv), avg(uv) from test
+```
+
+本身 SQL 就支持多种不同的聚合方式同时计算，所以将其用在 CASE 表达式里，也是顺其自然的：
+
+```sql
+SELECT CASE
+WHEN count(city) = 100 THEN 1
+WHEN sum(dau) > 200 THEN 2
+ELSE 0
+END AS abc
+FROM test
+```
+
+只要 SQL 表达式中存在聚合函数，那么整个表达式都聚合了，此时访问非聚合变量没有任何意义。所以上面的例子，即便在 CASE 表达式中使用了聚合，其实也不过是聚合了一次后，按照条件进行判断罢了。
+
+这个特性可以解决很多实际问题，比如将一些复杂聚合判断条件的结果用 SQL 结构输出，那么很可能是下面这种写法：
+
+```sql
+SELECT CASE
+WHEN 聚合函数(字段) 符合什么条件 THEN xxx
+... 可能有 N 个
+ELSE NULL
+END AS abc
+FROM test
+```
+
+这也可以认为是一种行转列的过程，即 **把行聚合后的结果通过一条条 CASE 表达式形成一个个新的列**。
+
+## 聚合与非聚合不能混用
+
+我们希望利用 CASE 表达式找出那些 pv 大于平均值的行，以下这种想当然的写法是错误的：
+
+```sql
+SELECT CASE
+WHEN pv > avg(pv) THEN 'yes'
+ELSE 'no'
+END AS abc
+FROM test
+```
+
+原因是，只要 SQL 中存在聚合表达式，那么整条 SQL 就都是聚合的，所以返回的结果只有一条，而我们期望查询结果不聚合，只是判断条件用到了聚合结果，那么就要使用子查询。
+
+为什么子查询可以解决问题？因为子查询的聚合发生在子查询，而不影响当前父查询，理解了这一点，就知道为什么下面的写法才是正确的了：
+
+```sql
+SELECT CASE
+WHEN pv > ( SELECT avg(pv) from test ) THEN 'yes'
+ELSE 'no'
+END AS abc
+FROM test
+```
+
+这个例子也说明了 CASE 表达式里可以使用子查询，因为子查询是先计算的，所以查询结果在哪儿都能用，CASE 表达式也不例外。
+
+## WHERE 中的 CASE
+
+WHERE 后面也可以跟 CASE 表达式的，用来做一些需要特殊枚举处理的筛选。
+
+比如下面的例子：
+
+```sql
+SELECT * FROM demo WHERE
+CASE
+WHEN city = '北京' THEN true
+ELSE ID > 5
+END
+```
+
+本来我们要查询 ID 大于 5 的数据，但我想对北京这个城市特别对待，那么就可以在判断条件中再进行 CASE 分支判断。
+
+这个场景在 BI 工具里等价于，创建一个 CASE 表达式字段，可以拖入筛选条件生效。
+
+## GROUP BY 中的 CASE
+
+想不到吧，GROUP BY 里都可以写 CASE 表达式：
+
+```sql
+SELECT isPower, sum(gdp) FROM test GROUP BY CASE
+WHEN isPower = 1 THEN city, area
+ELSE city
+END
+```
+
+上面例子表示，计算 GDP 时，对于非常发达的城市，按照每个区粒度查看聚合结果，也就是看的粒度更细一些，而对于欠发达地区，本身 gdp 也不高，直接按照城市粒度看聚合结果。
+
+这样，就按照不同的条件对数据进行了分组聚合。由于返回行结果是混在一起的，像这个例子，可以根据 isPower 字段是否为 1 判断，是否按照城市、区域进行了聚合，如果没有其他更显著的标识，可能导致无法区分不同行的聚合粒度，因此谨慎使用。
+
+## ORDER BY 中的 CASE
+
+同样，ORDER BY 使用 CASE 表达式，会将排序结果按照 CASE 分类进行分组，每组按照自己的规则排序，比如：
+
+```sql
+SELECT * FROM test ORDER BY CASE
+WHEN isPower = 1 THEN gdp
+ELSE people
+END
+```
+
+上面的例子，对发达地区采用 gdp 排序，否则采用人口数量排序。
+
+## 总结
+
+CASE 表达式总结一下有如下特点：
+
+1. 支持简单与搜索两种写法，推荐搜索写法。
+2. 支持聚合与子查询，需要注意不同情况的特点。
+3. 可以写在 SQL 查询的几乎任何地方，只要是可以写字段的地方，基本上就可以替换为 CASE 表达式。
+4. 除了 SELECT 外，CASE 表达式还广泛应用在 INSERT 与 UPDATE，其中 UPDATE 的妙用是不用将 SQL 拆分为多条，所以不用担心数据变更后对判断条件的二次影响。
+
+> 讨论地址是：[精读《SQL CASE 表达式》· Issue #404 · ascoders/weekly](https://github.com/ascoders/weekly/issues/404)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/ascoders/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
+
+

SQL/235.SQL 窗口函数.md

@@ -0,0 +1,124 @@
+窗口函数形如：
+
+```sql
+表达式 OVER (PARTITION BY 分组字段 ORDER BY 排序字段)
+```
+
+有两个能力：
+
+1. 当表达式为 `rank()` `dense_rank()` `row_number()` 时，拥有分组排序能力。
+2. 当表达式为 `sum()` 等聚合函数时，拥有累计聚合能力。
+
+无论何种能力，**窗口函数都不会影响数据行数，而是将计算平摊在每一行**。
+
+这两种能力需要区分理解。
+
+## 底表
+
+<img width=500 src="https://s1.ax1x.com/2022/03/26/qdUL60.png">
+
+以上是示例底表，共有 8 条数据，城市1、城市2 两个城市，下面各有地区1～4，每条数据都有该数据的人口数。
+
+## 分组排序
+
+如果按照人口排序，`ORDER BY people` 就行了，但如果我们想在城市内排序怎么办？
+
+此时就要用到窗口函数的分组排序能力：
+
+<img width=500 src="https://s1.ax1x.com/2022/03/26/qddfIg.png">
+
+```sql
+SELECT *, rank() over (PARTITION BY city ORDER BY people) FROM test
+```
+
+该 SQL 表示在 city 组内按照 people 进行排序。
+
+其实 PARTITION BY 也是可选的，如果我们忽略它：
+
+```sql
+SELECT *, rank() over (ORDER BY people) FROM test
+```
+
+也是生效的，但该语句与普通 ORDER BY 等价，因此利用窗口函数进行分组排序时，一般都会使用 PARTITION BY。
+
+### 各分组排序函数的差异
+
+我们将 `rank()` `dense_rank()` `row_number()` 的结果都打印出来：
+
+```sql
+SELECT *, 
+rank() over (PARTITION BY city ORDER BY people),
+dense_rank() over (PARTITION BY city ORDER BY people),
+row_number() over (PARTITION BY city ORDER BY people)
+FROM test
+```
+
+<img width=500 src="https://s1.ax1x.com/2022/03/26/qd0uh4.png">
+
+其实从结果就可以猜到，这三个函数在处理排序遇到相同值时，对排名统计逻辑有如下差异：
+
+1. `rank()`: 值相同时排名相同，但占用排名数字。
+2. `dense_rank()`: 值相同时排名相同，但不占用排名数字，整体排名更加紧凑。
+3. `row_number()`: 无论值是否相同，都强制按照行号展示排名。
+
+上面的例子可以优化一下，因为所有窗口逻辑都是相同的，我们可以利用 WINDOW AS 提取为一个变量：
+
+```sql
+SELECT *, 
+rank() over wd, dense_rank() over wd, row_number() over wd
+FROM test
+WINDOW wd as (PARTITION BY city ORDER BY people)
+```
+
+## 累计聚合
+
+我们之前说过，凡事使用了聚合函数，都会让查询变成聚合模式。如果不用 GROUP BY，聚合后返回行数会压缩为一行，即使用了 GROUP BY，返回的行数一般也会大大减少，因为分组聚合了。
+
+然而使用窗口函数的聚合却不会导致返回行数减少，那么这种聚合是怎么计算的呢？我们不如直接看下面的例子：
+
+```sql
+SELECT *, 
+sum(people) over (PARTITION BY city ORDER BY people)
+FROM test
+```
+
+<img width=500 src="https://s1.ax1x.com/2022/03/26/qdsDJS.png">
+
+可以看到，在每个 city 分组内，按照 people 排序后进行了 **累加**（相同的值会合并在一起），这就是 BI 工具一般说的 RUNNGIN_SUM 的实现思路，当然一般我们排序规则使用绝对不会重复的日期，所以不会遇到第一个红框中合并计算的问题。
+
+累计函数还有 `avg()` `min()` 等等，这些都一样可以作用于窗口函数，其逻辑可以按照下图理解：
+
+<img width=400 src="https://s1.ax1x.com/2022/03/26/qd6or9.png">
+
+你可能有疑问，直接 `sum(上一行结果，下一行)` 不是更方便吗？为了验证猜想，我们试试 `avg()` 的结果：
+
+<img width=400 src="https://s1.ax1x.com/2022/03/26/qdciIP.png">
+
+可见，如果直接利用上一行结果的缓存，那么 avg 结果必然是不准确的，所以窗口累计聚合是每行重新计算的。当然也不排除对于 sum、max、min 做额外性能优化的可能性，但 avg 只能每行重头计算。
+
+### 与 GROUP BY 组合使用
+
+窗口函数是可以与 GROUP BY 组合使用的，遵循的规则是，窗口范围对后面的查询结果生效，所以其实并不关心是否进行了 GROUP BY。我们看下面的例子：
+
+<img width=500 src="https://s1.ax1x.com/2022/03/26/qdgMOH.png">
+
+按照地区分组后进行累加聚合，是对 GROUP BY 后的数据行粒度进行的，而不是之前的明细行。
+
+## 总结
+
+窗口函数在计算组内排序或累计 GVM 等场景非常有用，我们只要牢记两个知识点就行了：
+
+1. 分组排序要结合 PARTITION BY 才有意义。
+2. 累计聚合作用于查询结果行粒度，支持所有聚合函数。
+
+> 讨论地址是：[精读《SQL 窗口函数》· Issue #405 · ascoders/weekly](https://github.com/ascoders/weekly/issues/405)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/ascoders/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
+
+

SQL/236.SQL grouping.md

@@ -0,0 +1,151 @@
+SQL grouping 解决 OLAP 场景总计与小计问题，其语法分为几类，但要解决的是同一个问题：
+
+ROLLUP 与 CUBE 是封装了规则的 GROUPING SETS，而 GROUPING SETS 则是最原始的规则。
+
+为了方便理解，让我们从一个问题入手，层层递进吧。
+
+## 底表
+
+<img width=500 src="https://s1.ax1x.com/2022/03/26/qdUL60.png">
+
+以上是示例底表，共有 8 条数据，城市1、城市2 两个城市，下面各有地区1～4，每条数据都有该数据的人口数。
+
+现在想计算人口总计，以及各城市人口小计。在没有掌握 grouping 语法前，我们只能通过两个 select 语句 union 后得到：
+
+```sql
+SELECT city, sum(people) FROM test GROUP BY city
+union
+SELECT '合计' as city, sum(people) FROM test
+```
+
+<img width=500 src="https://s1.ax1x.com/2022/04/04/qbKPRs.png">
+
+但两条 select 语句聚合了两次，性能是一个不小的开销，因此 SQL 提供了 GROUPING SETS 语法解决这个问题。
+
+## GROUPING SETS
+
+GROUP BY GROUPING SETS 可以指定任意聚合项，比如我们要同时计算总计与分组合计，就要按照空内容进行 GROUP BY 进行一次 sum，再按照 city 进行 GROUP BY 再进行一次 sum，换成 GROUPING SETS 描述就是：
+
+```sql
+SELECT 
+city, area,
+sum(people)
+FROM test
+GROUP BY GROUPING SETS((), (city, area))
+```
+
+其中 `GROUPING SETS((), (city, area))` 表示分别按照 `()`、`(city, area)` 聚合计算总计。返回结果是：
+
+<img width=500 src="https://s1.ax1x.com/2022/04/04/qbRnWF.png">
+
+可以看到，值为 NULL 的行就是我们要的总计，其值是没有任何 GROUP BY 限制算出来的。
+
+类似的，我们还可以写 `GROUPING SETS((), (city), (city, area), (area))` 等任意数量、任意组合的 GROUP BY 条件。
+
+通过这种规则计算的数据我们称为 “超级分组记录”。我们发现 “超级分组记录” 产生的 NULL 值很容易和真正的 NULL 值弄混，所以 SQL 提供了 GROUPING 函数解决这个问题。
+
+## 函数 GROUPING
+
+对于超级分组记录产生的 NULL，是可以被 `GROUPING()` 函数识别为 1 的：
+
+```sql
+SELECT 
+GROUPING(city),
+GROUPING(area),
+sum(people)
+FROM test
+GROUP BY GROUPING SETS((), (city, area))
+```
+
+具体效果见下图：
+
+<img width=500 src="https://s1.ax1x.com/2022/04/04/qbRLpF.png">
+
+可以看到，但凡是超级分组计算出来的字段都会识别为 1，我们利用之前学习的 [SQL CASE 表达式](https://github.com/ascoders/weekly/blob/master/SQL/234.SQL%20CASE%20%E8%A1%A8%E8%BE%BE%E5%BC%8F.md) 将其转换为总计、小计字样，就可以得出一张数据分析表了：
+
+```sql
+SELECT 
+CASE WHEN GROUPING(city) = 1 THEN '总计' ELSE city END,
+CASE WHEN GROUPING(area) = 1 THEN '小计' ELSE area END,
+sum(people)
+FROM test
+GROUP BY GROUPING SETS((), (city, area))
+```
+
+<img width=500 src="https://s1.ax1x.com/2022/04/04/qbRz01.png">
+
+然后前端表格展示时，将第一行 “总计”、“小计” 单元格合并为 “总计”，就完成了总计这个 BI 可视化分析功能。
+
+## ROLLUP
+
+ROLLUP 是卷起的意思，是一种特定规则的 GROUPING SETS，以下两种写法是等价的：
+
+```sql
+SELECT sum(people) FROM test
+GROUP BY ROLLUP(city)
+
+-- 等价于
+SELECT sum(people) FROM test
+GROUP BY GROUPING SETS((), (city))
+```
+
+再看一组等价描述：
+
+```sql
+SELECT sum(people) FROM test
+GROUP BY ROLLUP(city, area)
+
+-- 等价于
+SELECT sum(people) FROM test
+GROUP BY GROUPING SETS((), (city), (city, area))
+```
+
+发现规律了吗？ROLLUP 会按顺序把 GROUP BY 内容 “一个个卷起来”。用 GROUPING 函数判断超级分组记录对 ROLLUP 同样适用。
+
+## CUBE
+
+CUBE 又有所不同，它对内容进行了所有可能性展开（所以叫 CUBE）。
+
+类比上面的例子，我们再写两组等价的展开：
+
+```sql
+SELECT sum(people) FROM test
+GROUP BY CUBE(city)
+
+-- 等价于
+SELECT sum(people) FROM test
+GROUP BY GROUPING SETS((), (city))
+```
+
+上面的例子因为只有一项还看不出来，下面两项分组就能看出来了：
+
+```sql
+SELECT sum(people) FROM test
+GROUP BY CUBE(city, area)
+
+-- 等价于
+SELECT sum(people) FROM test
+GROUP BY GROUPING SETS((), (city), (area), (city, area))
+```
+
+所谓 CUBE，是一种多维形状的描述，二维时有 2^1 种展开，三维时有 2^2 种展开，四维、五维依此类推。可以想象，如果用 CUBE 描述了很多组合，复杂度会爆炸。
+
+## 总结
+
+学习了 GROUPING 语法，以后前端同学的你不会再纠结这个问题了吧：
+
+> 产品开启了总计、小计，我们是额外取一次数还是放到一起获取啊？
+
+这个问题的标准答案和原理都在这篇文章里了。PS：对于不支持 GROUPING 语法数据库，要想办法屏蔽，就像前端 polyfill 一样，是一种降级方案。至于如何屏蔽，参考文章开头提到的两个 SELECT + UNION。
+
+> 讨论地址是：[精读《SQL grouping》· Issue #406 · ascoders/weekly](https://github.com/ascoders/weekly/issues/406)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/ascoders/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
+
+

helper.js

@@ -12,6 +12,7 @@ const dirs = [
   "源码解读",
   "商业思考",
   "算法",
+  "SQL"
 ];
 
 dirs.forEach((dir) => {

readme.md

@@ -6,7 +6,7 @@
 
 前端界的好文精读，每周更新！
 
-最新精读：<a href="./前沿技术/229.%E7%B2%BE%E8%AF%BB%E3%80%8Avue-lit%20%E6%BA%90%E7%A0%81%E3%80%8B.md">229.精读《vue-lit 源码》</a>
+最新精读：<a href="./前沿技术/237.%E7%B2%BE%E8%AF%BB%E3%80%8ATypescript%204.5-4.6%20%E6%96%B0%E7%89%B9%E6%80%A7%E3%80%8B.md">237.精读《Typescript 4.5-4.6 新特性》</a>
 
 素材来源：[周刊参考池](https://github.com/ascoders/weekly/issues/2)
 
@@ -185,7 +185,8 @@
 - <a href="./前沿技术/225.%E7%B2%BE%E8%AF%BB%E3%80%8AExcel%20JS%20API%E3%80%8B.md">225.精读《Excel JS API》</a>
 - <a href="./前沿技术/226.%E7%B2%BE%E8%AF%BB%E3%80%8A2021%20%E5%89%8D%E7%AB%AF%E6%96%B0%E7%A7%80%E5%9B%9E%E9%A1%BE%E3%80%8B.md">226.精读《2021 前端新秀回顾》</a>
 - <a href="./前沿技术/228.%E7%B2%BE%E8%AF%BB%E3%80%8Apipe%20operator%20for%20JavaScript%E3%80%8B.md">228.精读《pipe operator for JavaScript》</a>
-- <a href="./前沿技术/229.%E7%B2%BE%E8%AF%BB%E3%80%8Avue-lit%20%E6%BA%90%E7%A0%81%E3%80%8B.md">229.精读《vue-lit 源码》</a>
+- <a href="./前沿技术/230.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%AF%B9%20Markdown%20%E7%9A%84%E6%80%9D%E8%80%83%E3%80%8B.md">230.精读《对 Markdown 的思考》</a>
+- <a href="./前沿技术/237.%E7%B2%BE%E8%AF%BB%E3%80%8ATypescript%204.5-4.6%20%E6%96%B0%E7%89%B9%E6%80%A7%E3%80%8B.md">237.精读《Typescript 4.5-4.6 新特性》</a>
 
 ### 设计模式
 
@@ -241,6 +242,7 @@
 - <a href="./源码解读/155.%20%E7%B2%BE%E8%AF%BB%E3%80%8Ause-what-changed%20%E6%BA%90%E7%A0%81%E3%80%8B.md">155. 精读《use-what-changed 源码》</a>
 - <a href="./源码解读/156.%20%E7%B2%BE%E8%AF%BB%E3%80%8Areact-intersection-observer%20%E6%BA%90%E7%A0%81%E3%80%8B.md">156. 精读《react-intersection-observer 源码》</a>
 - <a href="./源码解读/227.%20%E7%B2%BE%E8%AF%BB%E3%80%8Azustand%20%E6%BA%90%E7%A0%81%E3%80%8B.md">227. 精读《zustand 源码》</a>
+- <a href="./源码解读/229.%E7%B2%BE%E8%AF%BB%E3%80%8Avue-lit%20%E6%BA%90%E7%A0%81%E3%80%8B.md">229.精读《vue-lit 源码》</a>
 
 ### 商业思考
 
@@ -264,6 +266,15 @@
 - <a href="./算法/201.%E7%B2%BE%E8%AF%BB%E3%80%8A%E7%AE%97%E6%B3%95%20-%20%E4%BA%8C%E5%8F%89%E6%A0%91%E3%80%8B.md">201.精读《算法 - 二叉树》</a>
 - <a href="./算法/203.%E7%B2%BE%E8%AF%BB%E3%80%8A%E7%AE%97%E6%B3%95%20-%20%E4%BA%8C%E5%8F%89%E6%90%9C%E7%B4%A2%E6%A0%91%E3%80%8B.md">203.精读《算法 - 二叉搜索树》</a>
 
+### SQL
+
+- <a href="./SQL/231.SQL%20%E5%85%A5%E9%97%A8.md">231.SQL 入门</a>
+- <a href="./SQL/232.SQL%20%E8%81%9A%E5%90%88%E6%9F%A5%E8%AF%A2.md">232.SQL 聚合查询</a>
+- <a href="./SQL/233.SQL%20%E5%A4%8D%E6%9D%82%E6%9F%A5%E8%AF%A2.md">233.SQL 复杂查询</a>
+- <a href="./SQL/234.SQL%20CASE%20%E8%A1%A8%E8%BE%BE%E5%BC%8F.md">234.SQL CASE 表达式</a>
+- <a href="./SQL/235.SQL%20%E7%AA%97%E5%8F%A3%E5%87%BD%E6%95%B0.md">235.SQL 窗口函数</a>
+- <a href="./SQL/236.SQL%20grouping.md">236.SQL grouping</a>
+
 ## 关注前端精读微信公众号
 
 <img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">

前沿技术/19.精读《最佳前端面试题》及面试官技巧.md

@@ -88,7 +88,7 @@
 
 通过了基础问题还远远不够。甚至当问一个复杂的问题的时候，如果候选人瞬间把答案完美流畅表达出来，说明这个问题基本上白问了。
 
-**技术面更应该考察候选人的思考过程和基于此来表达出的技术能力和项目经验。**如果候选人基础没有落下太多，思维足够灵活，在过往项目中主动学习，并主导解决过项目问题，说明已经比较优秀了，我们招的每一人都应当拥有激情与学习能力。
+**技术面更应该考察候选人的思考过程和基于此来表达出的技术能力和项目经验**。如果候选人基础没有落下太多，思维足够灵活，在过往项目中主动学习，并主导解决过项目问题，说明已经比较优秀了，我们招的每一人都应当拥有激情与学习能力。
 
 所以，当问到候选人不了解的知识点时，通过引导并挖掘出候选人拥有多少问题解决能力，才是最大的权重项，如果这个问题候选人也提前准备了，那说明准备对了。
 

前沿技术/230.精读《对 Markdown 的思考》.md

@@ -0,0 +1,143 @@
+Markdown 即便在 2022 年也非常常用，比如这篇文章依然采用 Markdown 编写。
+
+但 Markdown 是否应该成为文本编辑领域的默认技术选型呢？答案是否定的。我找到了一篇批判无脑使用 Markdown 作为技术选型的好文 [Thoughts On Markdown](https://www.smashingmagazine.com/2022/02/thoughts-on-markdown/)，它提到 Markdown 在标准化、结构化、组件化都存在硬伤，如果你真的想做一个现代化的文本结构编辑器，不要采用 Markdown。
+
+## 概述
+
+Markdown 流传甚广，甚至已成为我们的第二语言。Markdown 最早的解析器由 John Gruber 在 2004 年基于 Perl 编写发布，那时候 Markdown 只有一个目的，即为了方便网络写作。
+
+网络写作必须基于 HTML 规范，而 HTML 规范对大部分人上手成本太高，因此 Markdown 就是基于文本创建的更易理解，或者说上手成本更低，甚至傻瓜化的一种语法，而要解析这个语法需要配套一个解析器，将这种语法文本最终转化为 HTML。
+
+而数字化发展到今天，Markdown 已不再适合当下的写作场景了，主要原因有二：
+
+1. Markdown 不再适合当下富交互、内容形态的编写。
+2. Markdown 纯文本的开发体验不再满足当代开发者日益提高的体验需求。
+
+首先还是从 Markdown 思想开始介绍。
+
+### Markdown 的核心思想
+
+Markdown 最大优势就是好上手，不需要接触 HTML 这种复杂的嵌套语句（虽然对程序员来说 HTML 也简单到处于鄙视链底端）。原文抽象了三个优势：
+
+1. 基于文本的合适抽象。虽然 HTML 甚至代码都是文本，但 “合适” 这个词很重要，即任何文本都可以是 Markdown，只要加一点点小标记就能描述专业结构，学习成本极低。
+2. 有大量生态工具。比如语法解析器、高亮、格式转换、格式化、渲染等工具完备。
+3. 编辑内容便于维护。比如 Markdown 很方便作为源码存储，而其他格式的富文本可能并不方便在源码里维护。
+
+如果把 Markdown 与数据库表结构做比较，那数据库的理解成本真是太高了。
+
+但是在如今后端即服务的时代，数据库访问越来越轻松，甚至出现大量如 AirTable 等 SAAS 产品将结构化数据快速转化为应用，其实接触了这些后才真正发现，结构化数据对开发者有多重要。Markdown 用来写写文章还是不错的，但用来表达逻辑结构最后一定会引发灾难后果，原文作者的团队就深受 Markdown 技术选型的困扰，被迫解决大量远超预期的难题。
+
+如果真的要在 Markdown 的坑越走越深，就必须使用语法拓展来满足自定义诉求。
+
+### Markdown 语法拓展
+
+最初 Markdown 语法是不支持表格的，如果想用 Markdown 绘制一张表格，只能使用原生 HTML 标签：`<table></table>`，当然，这也说明了 Markdown 本质就是给 HTML 加强了便捷的语法，我们完全可以将其当 HTML 使用。
+
+然而并不是所有创作平台都支持 `<table></table>` 语法的，笔者自己就经常受到困扰，比如有些平台会屏蔽原生 HTML 语法，已保障所谓的 “安全性” 或者内容体验的 “一致性”，而这些平台为了弥补缺失的绘制表格能力，往往会支持一些自定义语法，更糟糕的是不支持，这就说到了 Markdown 的语法拓展。
+
+Markdown 有哪些拓展呢？比如：[multiMarkdown](https://fletcherpenney.net/multimarkdown/)、[commonMark](https://commonmark.org/)、[Github Flavored Markdown](https://docs.github.com/en/get-started/writing-on-github) 等等。
+
+这里随便举个例子，比如标准 MD 格式，其实第一行最后要加两个空格才能换行，但 GFM 取消了这个限制。这虽然更方便了，但暴露出平台间规范的不一致性，导致 Markdown 跨平台基本一定被坑。
+
+而各平台拓展的语法，我们是否有足够的精力学习和记忆呢？先不说能不能记得下来，首先值不值得学习就是个问题，为什么一个网络写作平台需要占用写手学习与认知成本，而不是想办法去简化写作流程呢？所以语法拓展看似很美好，但放在写手角度，或者整个互联网各平台林立的角度来看，这种非标准的做法一定不靠谱，没有用户觉得你的平台有资格 “教他语法”，除非你是微信，钉钉或者飞书。
+
+原文提到的观点是：
+
+1. 作为写手，你不知道 Markdown 哪些语法可用，哪些语法不可用。
+2. 标准规范存在一些 [模糊地带](https://johnmacfarlane.net/babelmark2/faq.html#what-is-this-for) 导致开发者实现时也会遇到各种纠结。
+
+原文还提到一个语法拓展导致理解成本增高的例子：slack 平台自定义的 [mrkdown](https://api.slack.com/reference/surfaces/formatting#basics) 就不支持 `[link](https://slack.com)` 方式描述链接，而使用了 `<link|https://slack.com>` 语法。
+
+总结来说，Markdown 语法拓展本应该是件好事，但实际无标准导致了标准的百花齐放，使 Markdown 成为了实际上没有标准的状态，整体来看弊端更多。
+
+### Markdown 面向的用户群
+
+Markdown 的对自己的定位其实很不清晰，这也导致了一直不想确定标准化语法。
+
+最初 Markdown 是服务给熟悉 HTML 的人提供的标记语言，而后来面向用户群实质上转向了开发者，因为开发者才会想到拓展语法以满足更复杂的使用场景，Markdown 原生语法无法适应越来越复杂的视觉展示形态。
+
+如今 Markdown 的主要用户已经是开发人员与对代码感兴趣的人了，这倒不是说开发者有多喜欢它，而是在说 Markdown 的受众变窄了。如今任何一款面向非开发者群体的文档编辑器都不会采用 Markdown 了，而是所见即所得的 WYSIWYG（what you see is what you want）模式。
+
+这个转变的过程是痛苦的，但现在来看，富文本编辑器不应用用 Markdown 语法，而是 WYSIWYG 模式已经是共识了。
+
+### 从段落到区块、从文章到应用
+
+简单来说，即 Markdown 已经不适应当前 HTML 丰富的生态了，能轻松描述段落的标记语言，遇到富有交互的组件区块时，不得不引入例如 [MDX](https://mdxjs.com/) 等方案，但这样的方案根本只适合程序员群体，完全无法移植。
+
+网络浏览形态也从简单的文章发展到具有整体性的应用，这些应用拥有复杂的布局、样式与交互，如果你尝试基于 Markdown 拓展语法来支持，最后可能发现还不如直接用原生 HTML。
+
+### 对结构化内容的诉求
+
+从编程角度理解就是 “组件复用”。Markdown 原生语法无法实现内容的复用，如果必须要复用内容，只能将其重复写在每一处，势必造成巨大同步成本。
+
+比如 Jekyll 就提出了 [FrontMatter](https://jekyllrb.com/docs/front-matter/) 概念用来创建复用的变量：
+
+```yml
+---
+food: Pizza
+---
+
+<h1>{{ page.food }}</h1>
+```
+
+### WYSIWYG 编辑器不应将 HTML 作为底层数据结构
+
+虽然浏览器真正将 HTML 作为底层数据结构，但这并不代表所见即所得的编辑器也可以如此，这也是为什么浏览器只能提供从源码到 UI 的输出，而不能提供从 UI 编辑到源码的反向输入。
+
+因为用户的输入与 HTML 并不是一一对应关系，其中存在大量模糊地带，比如当前光标处在粗体与细体文字中间，那下一个输入到底算加粗还是不加粗呢？从 UI 上看不到加粗标签。再有，如果 HTML 存在冗余，其实当前光标所在位置已经被加粗标签包裹了好几层，但因为光标所在区域又被另一个样式标签覆盖成非加粗模式，当再次输入时可能就跳出了覆盖范围，重新变成了加粗，这个过程符合用户预期吗？从技术上，这种复杂标签结构也几乎无法被处理，因为组合花样实在太多。
+
+现代大多数编辑器都以 JSON 格式存储数据结构，就因为其结构化且易于检索。
+
+结构化最重要的体现是，其生成的 HTML 结构可以是稳定的，即对于一个既加粗又标红的文字，一定包裹在一个 `<strong style="color: red">` 标签里，而不是 `<strong><div style="color: red">`，也就是这种模式根本没把 HTML 作为结构化数据去看待，自然就不会出现歧义。
+
+Markdown 也是一样，其本身也会出现类似 HTML 标签的二义性，不适合作为底层数据结构存储。
+
+## 精读
+
+批判 Markdown 的文章不多见，笔者也是看了之后才恍然发现 Markdown 竟然有这么多缺点。笔者结合自己的经验谈谈 Markdown 的缺点吧。
+
+### 不支持富交互的无奈
+
+Markdown 仅能支持简单的 HTML 结构，而无法描述逻辑区块。Github 上大部分 Readme 都采用图片来实现这些功能，包括状态卡片、构建结果、个人信息名片等，可惜交互能力还是太弱，我觉得有朝一日 Github 应该会推出比如 Block 小区块的概念，让这些区块可以直接插入 Markdown 成为一个可交互的元素。
+
+### MDX 解决了 Markdown 的痛点吗？
+
+看似完美兼容 JSX 与 Markdown 的 MDX 曾经也是笔者写作的救命稻草，但该方案移植性是一大痛点，组件只能在自己部署的网站用，如果你想把文章发布到另一个平台，完全不可能。
+
+这还仅是笔者的视角，如果从 Markdown 生态来看，MDX 面向用户仅是程序员群体，根本没有解决其使命 “方便网络写作”，而程序员最终也会抛弃 MDX 而转向开发所见即所得编辑器解决问题。
+
+### Markdown 到 HTML 的转换存在逻辑问题
+
+Markdown 本质上还是一种脱离 HTML 的文本表示结构，看上去解耦很优雅，实际上会遇到不少不一致的问题。
+
+比如说连续敲击多个空格会出现什么情况呢？在 Markdown 会变成一个引用区块，那如何才能展示多个空格呢？谁也不知道，可能需要查阅具体平台提供的额外语法才可以做到。
+
+这种大体上用起来方便，但细节无法定制，甚至用户无法控制的情况会大大伤害已经深度使用 Markdown 的用户，此时用户要么硬着头皮发明新语法解决这些漏洞，要么就完全放弃 Markdown 了。
+
+### 结构化能力不足
+
+看上去 Markdown 的语法挺具有结构化的，但实际上 Markdown 的结构化不具有强约束力。
+
+拿 JSON 作对比，比如我们可以用 JSON 拓展出 [https://json-schema.org/](jsonSchema) 结构，这个结构甚至可以反推出一个完整的表单应用，其原因是 JSON 可以针对每一个 Key、层级下定义，首先有结构，其次才有内容。
+
+而 Markdown 正好反过来，是先有内容，再有结构。比如我们可以在 Markdown 任何地方写任何 HTML 标签，或者任意段落的问题，这些内容是无法被序列化的，即便我们按照浏览器解析 HTML 的规则解析成 JSON，也无法从中方便的提取信息。
+
+背后的根本原因是，Markdown 本身定位就是 “近乎于 UI 渲染结果” 的，而实际上浏览器渲染 UI 背后是需要一套严谨的 HTML 语法，因为 UI 与背后语法并不能一一建立映射，一个稳定的渲染逻辑只能是从源码推导到渲染，而不能从渲染反推出源码。Markdown 本身定位就近乎于渲染结果，所以结构化能力不足是天然的问题。
+
+## 总结
+
+记得语雀早期内部试用时，编辑态还是采用 Markdown 的，但后来很快就把 Markdown 的编辑入口下掉了，这件事还引发了不少开发者的不满，甚至还有一些 Markdown 编辑的插件被开发出来，一度很受欢迎。但渐渐的我们都习惯用所见即所得方式编辑了，Markdown 唯一留给我们的印象就是快捷键，比如 `###` 后敲入空格可以生成 `h3` 标题段落，而语雀编辑器也在富交互组件区块上越走越远，要是当年被 Markdown 锁定住了技术，也不可能有今天这么高级的编辑体验。
+
+所以技术前瞻性真的很重要，Markdown 所有程序员都爱，但提前看到它在当前互联网发展阶段的局限性，并设计一套结构化数据代替 Markdown 结构不是所有人都能想到的，我们需要以动态的眼光看待技术，也要放下技术人的偏见，把偏爱让位于产品定位。
+
+> 讨论地址是：[精读《对 Markdown 的思考》· Issue #397 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/397)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
+
+

前沿技术/237.精读《Typescript 4.5-4.6 新特性》.md

@@ -0,0 +1,502 @@
+## 新增 Awaited 类型
+
+Awaited 可以将 Promise 实际返回类型抽出来，按照名字可以理解为：等待 Promise resolve 了拿到的类型。下面是官方文档提供的 Demo：
+
+```ts
+// A = string
+type A = Awaited<Promise<string>>;
+
+// B = number
+type B = Awaited<Promise<Promise<number>>>;
+
+// C = boolean | number
+type C = Awaited<boolean | Promise<number>>;
+```
+
+## 捆绑的 dom lib 类型可以被替换
+
+TS 因开箱即用的特性，捆绑了所有 dom 内置类型，比如我们可以直接使用 Document 类型，而这个类型就是 TS 内置提供的。
+
+也许有时不想随着 TS 版本升级而升级连带的 dom 内置类型，所以 TS 提供了一种指定 dom lib 类型的方案，在 `package.json` 申明 `@typescript/lib-dom` 即可：
+
+```json
+{
+ "dependencies": {
+    "@typescript/lib-dom": "npm:@types/web"
+  }
+}
+```
+
+这个特性提升了 TS 的环境兼容性，但一般情况还是建议开箱即用，省去繁琐的配置，项目更好维护。
+
+## 模版字符串类型也支持类型收窄
+
+```ts
+export interface Success {
+    type: `${string}Success`;
+    body: string;
+}
+
+export interface Error {
+    type: `${string}Error`;
+    message: string;
+}
+
+export function handler(r: Success | Error) {
+    if (r.type === "HttpSuccess") {
+        // 'r' has type 'Success'
+        let token = r.body;
+    }
+}
+```
+
+模版字符串类型早就支持了，但现在才支持按照模版字符串在分支条件时，做类型收窄。
+
+## 增加新的 --module es2022
+
+虽然可以使用 --module esnext 保持最新特性，但如果你想使用稳定的版本号，又要支持顶级 await 特性的话，可以使用 es2022。
+
+## 尾递归优化
+
+TS 类型系统支持尾递归优化了，拿下面这个例子就好理解：
+
+```ts
+type TrimLeft<T extends string> =
+    T extends ` ${infer Rest}` ? TrimLeft<Rest> : T;
+
+// error: Type instantiation is excessively deep and possibly infinite.
+type Test = TrimLeft<"                                                oops">;
+```
+
+在没有做尾递归优化前，TS 会因为堆栈过深而报错，但现在可以正确返回执行结果了，因为尾递归优化后，不会形成逐渐加深的调用，而是执行完后立即退出当前函数，堆栈数量始终保持不变。
+
+JS 目前还没有做到自动尾递归优化，但可以通过自定义函数 TCO 模拟实现，下面放出这个函数的实现：
+
+```js
+function tco(f) {
+  var value;
+  var active = false;
+  var accumulated = [];
+  return function accumulator(...rest) {
+    accumulated.push(rest);
+    if (!active) {
+      active = true;
+      while (accumulated.length) {
+        value = f.apply(this, accumulated.shift());
+      }
+      active = false;
+      return value;
+    }
+  };
+}
+```
+
+核心是把递归变成 while 循环，这样就不会产生堆栈。
+
+## 强制保留 import
+
+TS 编译时会把没用到的 import 干掉，但这次提供了 `--preserveValueImports` 参数禁用这一特性，原因是以下情况会导致误移除 import：
+
+```ts
+import { Animal } from "./animal.js";
+
+eval("console.log(new Animal().isDangerous())");
+```
+
+因为 TS 无法分辨 eval 里的引用，类似的还有 vue 的 `setup` 语法：
+
+```html
+<!-- A .vue File -->
+<script setup>
+import { someFunc } from "./some-module.js";
+</script>
+
+<button @click="someFunc">Click me!</button>
+```
+
+## 支持变量 import type 声明
+
+之前支持了如下语法标记引用的变量是类型：
+
+```ts
+import type { BaseType } from "./some-module.js";
+```
+
+现在支持了变量级别的 type 声明：
+
+```ts
+import { someFunc, type BaseType } from "./some-module.js";
+```
+
+这样方便在独立模块构建时，安全的抹去 `BaseType`，因为单模块构建时，无法感知 `some-module.js` 文件内容，所以如果不特别指定 `type BaseType`，TS 编译器将无法识别其为类型变量。
+
+## 类私有变量检查
+
+包含两个特性，第一是 TS 支持了类私有变量的检查：
+
+```ts
+class Person {
+    #name: string;
+}
+```
+
+第二是支持了 `#name in obj` 的判断，如：
+
+```ts
+class Person {
+    #name: string;
+    constructor(name: string) {
+        this.#name = name;
+    }
+
+    equals(other: unknown) {
+        return other &&
+            typeof other === "object" &&
+            #name in other && // <- this is new!
+            this.#name === other.#name;
+    }
+}
+```
+
+该判断隐式要求了 `#name in other` 的 `other` 是 Person 实例化的对象，因为该语法仅可能存在于类中，而且还能进一步类型缩窄为 Persion 类。
+
+## Import 断言
+
+支持了导入断言提案：
+
+```ts
+import obj from "./something.json" assert { type: "json" };
+```
+
+以及动态 import 的断言：
+
+```ts
+const obj = await import("./something.json", {
+    assert: { type: "json" }
+})
+```
+
+TS 该特性支持了任意类型的断言，而不关心浏览器是否识别。所以该断言如果要生效，需要以下两种支持的任意一种：
+
+- 浏览器支持。
+- 构建脚本支持。
+
+不过目前来看，构建脚本支持的语法并不统一，比如 Vite 对导入类型的断言有如下两种方式：
+
+```ts
+import obj from "./something?raw"
+
+// 或者自创的语法 blob 加载模式
+const modules = import.meta.glob(
+  './**/index.tsx',
+  {
+    assert: { type: 'raw' },
+  },
+);
+```
+
+所以该导入断言至少在未来可以统一构建工具的语法，甚至让浏览器原生支持后，就不需要构建工具处理 import 断言了。
+
+其实完全靠浏览器解析要走的路还有很远，因为一个复杂的前端工程至少有 3000~5000 个资源文件，目前生产环境不可能使用 bundless 一个个加载这些资源，因为速度太慢了。
+
+## const 只读断言
+
+```ts
+const obj = {
+  a: 1
+} as const
+
+obj.a = 2 // error
+```
+
+通过该语法指定对象所有属性为 `readonly`。
+
+## 利用 realpathSync.native 实现更快加载速度
+
+对开发者没什么感知，就是利用 `realpathSync.native` 提升了 TS 加载速度。
+
+## 片段自动补全增强
+
+在 Class 成员函数与 JSX 属性的自动补全功能做了增强，在使用了最新版 TS 之后应该早已有了体感，比如 JSX 书写标签输入回车后，会自动根据类型补全内容，如：
+
+```tsx
+<App cla />
+//    ↑回车↓
+//        <App className="|" />
+//                        ↑光标自动移到这里
+```
+
+## 代码可以写在 super() 前了
+
+JS 对 `super()` 的限制是此前不可以调用 this，但 TS 限制的更严格，在 `super()` 前写任何代码都会报错，这显然过于严格了。
+
+现在 TS 放宽了校验策略，仅在 `super()` 前调用 this 会报错，而执行其他代码是被允许的。
+
+这点其实早就该改了，这么严格的校验策略让我一度以为 JS 就是不允许 `super()` 前调用任何函数，但想想也觉得不合理，因为 `super()` 表示调用父类的 `constructor` 函数，之所以不自动调用，而需要手动调用 `super()` 就是为了开发者可以灵活决定哪些逻辑在父类构造函数前执行，所以 TS 之前一刀切的行为实际上导致 `super()` 失去了存在的意义，成为一个没有意义的模版代码。
+
+## 类型收窄对解构也生效了
+
+这个特性真的很厉害，即解构后类型收窄依然生效。
+
+此前，TS 的类型收窄已经很强大了，可以做到如下判断：
+
+```ts
+function foo(bar: Bar) {
+  if (bar.a === '1') {
+    bar.b // string 类型
+  } else {
+    bar.b // number 类型
+  }
+}
+```
+
+但如果提前把 a、b 从 bar 中解构出来就无法自动收窄了。现在该问题也得到了解决，以下代码也可以正常生效了：
+
+```ts
+function foo(bar: Bar) {
+  const { a, b } = bar
+  if (a === '1') {
+    b // string 类型
+  } else {
+    b // number 类型
+  }
+}
+```
+
+## 深度递归类型检查优化
+
+下面的赋值语句会产生异常，原因是属性 prop 的类型不匹配：
+
+```ts
+interface Source {
+    prop: string;
+}
+
+interface Target {
+    prop: number;
+}
+
+function check(source: Source, target: Target) {
+    target = source;
+    // error!
+    // Type 'Source' is not assignable to type 'Target'.
+    //   Types of property 'prop' are incompatible.
+    //     Type 'string' is not assignable to type 'number'.
+}
+```
+
+这很好理解，从报错来看，TS 也会根据递归检测的方式查找到 prop 类型不匹配。但由于 TS 支持泛型，如下写法就是一种无限递归的例子：
+
+```ts
+interface Source<T> {
+    prop: Source<Source<T>>;
+}
+
+interface Target<T> {
+    prop: Target<Target<T>>;
+}
+
+function check(source: Source<string>, target: Target<number>) {
+    target = source;
+}
+```
+
+实际上不需要像官方说明写的这么复杂，哪怕是 `props: Source<T>` 也足以让该例子无限递归下去。TS 为了确保该情况不会出错，做了递归深度判断，过深的递归会终止判断，但这会带来一个问题，即无法识别下面的错误：
+
+```ts
+interface Foo<T> {
+    prop: T;
+}
+
+declare let x: Foo<Foo<Foo<Foo<Foo<Foo<string>>>>>>;
+declare let y: Foo<Foo<Foo<Foo<Foo<string>>>>>;
+
+x = y;
+```
+
+为了解决这一问题，TS 做了一个判断：递归保护仅对递归写法的场景生效，而上面这个例子，虽然也是很深层次的递归，但因为是一个个人肉写出来的，TS 也会不厌其烦的一个个递归下去，所以该场景可以正确 Work。
+
+这个优化的核心在于，TS 可以根据代码结构解析哪些是 “非常抽象/启发式” 写法导致的递归，哪些是一个个枚举产生的递归，并对后者的递归深度检查进行豁免。
+
+## 增强的索引推导
+
+下面的官方文档给出的例子，一眼看上去比较复杂，我们来拆解分析一下：
+
+```ts
+interface TypeMap {
+    "number": number;
+    "string": string;
+    "boolean": boolean;
+}
+
+type UnionRecord<P extends keyof TypeMap> = { [K in P]:
+    {
+        kind: K;
+        v: TypeMap[K];
+        f: (p: TypeMap[K]) => void;
+    }
+}[P];
+
+function processRecord<K extends keyof TypeMap>(record: UnionRecord<K>) {
+    record.f(record.v);
+}
+
+// This call used to have issues - now works!
+processRecord({
+    kind: "string",
+    v: "hello!",
+
+    // 'val' used to implicitly have the type 'string | number | boolean',
+    // but now is correctly inferred to just 'string'.
+    f: val => {
+        console.log(val.toUpperCase());
+    }
+})
+```
+
+该例子的目的是实现 `processRecord` 函数，该函数通过识别传入参数 `kind` 来自动推导回调函数 `f` 中 `value` 的类型。
+
+比如 `kind: "string"`，那么 `val` 就是字符串类型，`kind: "number"`，那么 `val` 就是数字类型。
+
+因为 TS 这次更新解决了之前无法识别 `val` 类型的问题，我们不需要关心 TS 是怎么解决的，只要记住 TS 可以正确识别该场景（有点像围棋的定式，对于经典例子最好逐一学习），并且理解该场景是如何构造的。
+
+如何做到呢？首先定义一个类型映射：
+
+```ts
+interface TypeMap {
+    "number": number;
+    "string": string;
+    "boolean": boolean;
+}
+```
+
+之后定义最终要的函数 `processRecord`:
+
+```ts
+function processRecord<K extends keyof TypeMap>(record: UnionRecord<K>) {
+    record.f(record.v);
+}
+```
+
+这里定义了一个泛型 K，`K extends keyof TypeMap` 等价于 `K extends 'number' | 'string' | 'boolean'`，所以这里是限定了以下泛型 K 的取值范围，值为这三个字符串之一。
+
+重点来了，参数 `record` 需要根据传入的 `kind` 决定 `f` 回调函数参数类型。我们先想象以下 `UnionRecord` 类型怎么写：
+
+```ts
+type UnionRecord<K extends keyof TypeMap> = {
+  kind: K;
+  v: TypeMap[K];
+  f: (p: TypeMap[K]) => void;
+}
+```
+
+如上，自然的想法是定义一个泛型 K，这样 `kind` 与 `f`, `p` 类型都可以表示出来，这样 `processRecord<K extends keyof TypeMap>(record: UnionRecord<K>)` 的 `UnionRecord<K>` 就表示了将当前接收到的实际类型 K 传入 `UnionRecord`，这样 `UnionRecord` 就知道实际处理什么类型了。
+
+本来到这里该功能就已经结束了，但官方给的 `UnionRecord` 定义稍有些不同：
+
+```ts
+type UnionRecord<P extends keyof TypeMap> = { [K in P]:
+    {
+        kind: K;
+        v: TypeMap[K];
+        f: (p: TypeMap[K]) => void;
+    }
+}[P];
+```
+
+这个例子特意提升了一个复杂度，用索引的方式绕了一下，可能之前 TS 就无法解析这种形式吧，总之现在这个写法也被支持了。我们看一下为什么这个写法与上面是等价的，上面的写法简化一下如下：
+
+```ts
+type UnionRecord<P extends keyof TypeMap> = { 
+  [K in P]: X
+}[P];
+```
+
+可以解读为，`UnionRecord` 定义了一个泛型 P，该函数从对象 `{ [K in P]: X }` 中按照索引（或理解为下标） `[P]` 取得类型。而 `[K in P]` 这种描述对象 Key 值的类型定义，等价于定义了复数个类型，由于正好 `P extends keyof TypeMap`，你可以理解为类型展开后是这样的：
+
+```ts
+type UnionRecord<P extends keyof TypeMap> = { 
+  'number': X,
+  'string': X,
+  'boolean': X
+}[P];
+```
+
+而 P 是泛型，由于 `[K in P]` 的定义，所以必定能命中上面其中的一项，所以实际上等价于下面这个简单的写法：
+
+```ts
+type UnionRecord<K extends keyof TypeMap> = {
+  kind: K;
+  v: TypeMap[K];
+  f: (p: TypeMap[K]) => void;
+}
+```
+
+## 参数控制流分析
+
+这个特性字面意思翻译挺奇怪的，还是从代码来理解吧：
+
+```ts
+type Func = (...args: ["a", number] | ["b", string]) => void;
+
+const f1: Func = (kind, payload) => {
+    if (kind === "a") {
+        payload.toFixed();  // 'payload' narrowed to 'number'
+    }
+    if (kind === "b") {
+        payload.toUpperCase();  // 'payload' narrowed to 'string'
+    }
+};
+
+f1("a", 42);
+f1("b", "hello");
+```
+
+如果把参数定义为数组且使用或并列枚举时，其实就潜在包含了一个运行时的类型收窄。比如当第一个参数值为 `a` 时，第二个参数类型就确定为 `number`，第一个参数值为 `b` 时，第二个参数类型就确定为 `string`。
+
+值得注意的是，这种类型推导是从前到后的，因为参数是自左向右传递的，所以是前面推导出后面，而不能是后面推导出前面（比如不能理解为，第二个参数为 `number` 类型，那第一个参数的值就必须为 `a`）。
+
+## 移除 JSX 编译时产生的非必要代码
+
+JSX 编译时干掉了最后一个没有意义的 `void 0`,减少了代码体积：
+
+```js
+- export const el = _jsx("div", { children: "foo" }, void 0);
++ export const el = _jsx("div", { children: "foo" });
+```
+
+由于改动很小，所以可以借机学习一下 TS 源码是怎么修改的，这是 [PR DIFF 地址](https://github.com/microsoft/TypeScript/pull/47467/files#)。
+
+可以看到，修改位置是 `src/compiler/transformers/jsx.ts` 文件，改动逻辑为移除了 `factory.createVoidZero()` 函数，该函数正如其名，会创建末尾的 `void 0`，除此之外就是大量的 tests 文件修改，其实理解了源码上下文，这种修改并不难。
+
+## JSDoc 校验提示
+
+JSDoc 注释由于与代码是分离的，随着不断迭代很容易与实际代码产生分叉：
+
+```ts
+/**
+ * @param x {number} The first operand
+ * @param y {number} The second operand
+ */
+function add(a, b) {
+    return a + b;
+}
+```
+
+现在 TS 可以对命名、类型等不一致给出提示了。顺便说一句，用了 TS 就尽量不要用 JSDoc，毕竟代码和类型分离随时有不一致的风险产生。
+
+## 总结
+
+从这两个更新来看，TS 已经进入成熟期，但 TS 在泛型类的问题上依然还处于早期阶段，有大量复杂的场景无法支持，或者没有优雅的兼容方案，希望未来可以不断完善复杂场景的类型支持。
+
+> 讨论地址是：[精读《Typescript 4.5-4.6 新特性》· Issue #408 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/408)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
+
+

前沿技术/7.精读《请停止 css-in-js 的行为》.md

@@ -32,7 +32,7 @@ const Title = styled.h1`
 
 ## css-modules
 
-顾名思义，css-modules 将 css 代码模块化，可以很方面的避免本模块样式被污染。并且可以很方便的复用 css 代码。
+顾名思义，css-modules 将 css 代码模块化，可以很方便的避免本模块样式被污染。并且可以很方便的复用 css 代码。
 
 ```css
 // 全局变量

设计模式/167.精读《设计模式 - Abstract Factory 抽象工厂》.md

@@ -44,7 +44,7 @@ Abstract Factory（抽象工厂）属于创建型模式，工厂类模式抽象
 
 `AbstractProduct` 是产品抽象类，描述了比如方向盘、墙壁、折线图的创建方法，而 `ConcreteProduct` 是具体实现产品的方法，比如 `ConcreteProduct1` 创建的表格是用 `canvas` 画的，折线图是用 `G2` 画的，而 `ConcreteProduct2` 创建的表格是用 `div` 画的，折线图是用 `Echarts` 画的。
 
-这样，当我们要拓展一个用 `Rcharts` 画的折线图，用 `svg` 画的表格，用 `div` 画的模态框组成的事件机制时，只需要再创建一个 `ConcreteFactory3` 做相应的实现即可，再将这个 `ConcreteFactory3` 传递给 `AbstractFactory`，并不需要修改 `AbstractFactory` 方法本身。
+这样，当我们要拓展一个用 `Echarts` 画的折线图，用 `svg` 画的表格，用 `div` 画的模态框组成的事件机制时，只需要再创建一个 `ConcreteFactory3` 做相应的实现即可，再将这个 `ConcreteFactory3` 传递给 `AbstractFactory`，并不需要修改 `AbstractFactory` 方法本身。
 
 ## 代码例子