From de6945f55acbafcf7e7811c5bfa16a81d24dc09c Mon Sep 17 00:00:00 2001
From: krahets <krahets@163.com>
Date: Fri, 7 Apr 2023 22:31:50 +0800
Subject: [PATCH] Polish the contents 1. Array and linked list. 2.
 Computational complexity. 3. Fix a mistake in counting_sort.md

---
 docs/chapter_array_and_linkedlist/array.md    |  24 ++---
 .../linked_list.md                            |  31 +++---
 docs/chapter_array_and_linkedlist/list.md     |  28 ++---
 docs/chapter_array_and_linkedlist/summary.md  |  14 +--
 .../performance_evaluation.md                 |  38 +++----
 .../space_complexity.md                       |  42 ++++----
 .../space_time_tradeoff.md                    |  20 ++--
 .../summary.md                                |  26 ++---
 .../time_complexity.md                        | 102 +++++++++---------
 docs/chapter_heap/build_heap.md               |   2 +-
 docs/chapter_sorting/counting_sort.md         |   2 +-
 11 files changed, 164 insertions(+), 165 deletions(-)

diff --git a/docs/chapter_array_and_linkedlist/array.md b/docs/chapter_array_and_linkedlist/array.md
index 534923e2b..6485dcc2a 100755
--- a/docs/chapter_array_and_linkedlist/array.md
+++ b/docs/chapter_array_and_linkedlist/array.md
@@ -1,14 +1,10 @@
 # 数组
 
-「数组 Array」是一种将 **相同类型元素** 存储在 **连续内存空间** 的数据结构，将元素在数组中的位置称为元素的「索引 Index」。
+「数组 Array」是一种线性数据结构，其将相同类型元素存储在连续的内存空间中。我们将元素在数组中的位置称为元素的「索引 Index」。
 
 ![数组定义与存储方式](array.assets/array_definition.png)
 
-!!! note
-
-    观察上图，我们发现 **数组首元素的索引为 $0$** 。你可能会想，这并不符合日常习惯，首个元素的索引为什么不是 $1$ 呢，这不是更加自然吗？我认同你的想法，但请先记住这个设定，后面讲内存地址计算时，我会尝试解答这个问题。
-
-**数组初始化**。一般会用到无初始值、给定初始值两种写法，可根据需求选取。在不给定初始值的情况下，一般所有元素会被初始化为默认值 $0$ 。
+**数组初始化**。通常有无初始值和给定初始值两种方式，我们可根据需求选择合适的方法。在未给定初始值的情况下，数组的所有元素通常会被初始化为默认值 $0$ 。
 
 === "Java"
 
@@ -98,7 +94,7 @@
 
 ## 数组优点
 
-**在数组中访问元素非常高效**。这是因为在数组中，计算元素的内存地址非常容易。给定数组首个元素的地址、和一个元素的索引，利用以下公式可以直接计算得到该元素的内存地址，从而直接访问此元素。
+**在数组中访问元素非常高效**。由于数组元素被存储在连续的内存空间中，因此计算数组元素的内存地址非常容易。给定数组首个元素的地址和某个元素的索引，我们可以使用以下公式计算得到该元素的内存地址，从而直接访问此元素。
 
 ![数组元素的内存地址计算](array.assets/array_memory_location_calculation.png)
 
@@ -107,9 +103,13 @@
 elementAddr = firtstElementAddr + elementLength * elementIndex
 ```
 
-**为什么数组元素索引从 0 开始编号？** 根据地址计算公式，**索引本质上表示的是内存地址偏移量**，首个元素的地址偏移量是 $0$ ，那么索引是 $0$ 也就很自然了。
+!!! question "为什么数组元素的索引要从 $0$ 开始编号呢？"
+
+    观察上图，我们发现数组首个元素的索引为 $0$ ，这似乎有些反直觉，因为从 $1$ 开始计数会更自然。
+    
+    然而，从地址计算公式的角度看，**索引本质上表示的是内存地址的偏移量**。首个元素的地址偏移量是 $0$ ，因此索引为 $0$ 也是合理的。
 
-访问元素的高效性带来了许多便利。例如，我们可以在 $O(1)$ 时间内随机获取一个数组中的元素。
+访问元素的高效性带来了诸多便利。例如，我们可以在 $O(1)$ 时间内随机获取数组中的任意一个元素。
 
 === "Java"
 
@@ -359,9 +359,9 @@ elementAddr = firtstElementAddr + elementLength * elementIndex
 
 总结来看，数组的插入与删除操作有以下缺点：
 
-- **时间复杂度高**：数组的插入和删除的平均时间复杂度均为 $O(N)$ ，其中 $N$ 为数组长度。
-- **丢失元素**：由于数组的长度不可变，因此在插入元素后，超出数组长度范围的元素会被丢失。
-- **内存浪费**：我们一般会初始化一个比较长的数组，只用前面一部分，这样在插入数据时，丢失的末尾元素都是我们不关心的，但这样做同时也会造成内存空间的浪费。
+- **时间复杂度高**：数组的插入和删除的平均时间复杂度均为 $O(n)$ ，其中 $n$ 为数组长度。
+- **丢失元素**：由于数组的长度不可变，因此在插入元素后，超出数组长度范围的元素会丢失。
+- **内存浪费**：我们可以初始化一个比较长的数组，只用前面一部分，这样在插入数据时，丢失的末尾元素都是我们不关心的，但这样做同时也会造成内存空间的浪费。
 
 ## 数组常用操作
 
diff --git a/docs/chapter_array_and_linkedlist/linked_list.md b/docs/chapter_array_and_linkedlist/linked_list.md
index 7f0faa4bf..d0867097b 100755
--- a/docs/chapter_array_and_linkedlist/linked_list.md
+++ b/docs/chapter_array_and_linkedlist/linked_list.md
@@ -1,10 +1,10 @@
 # 链表
 
-内存空间是所有程序的公共资源，排除已被占用的内存空间，空闲内存空间往往是散落在内存各处的。上节讲到，**存储数组的内存空间必须是连续的**，当我们需要申请一个非常大的数组时，系统不一定能够分配这么大的连续内存空间。
+内存空间是所有程序的公共资源，排除已被占用的内存空间，空闲内存空间通常散落在内存各处。在上一节中，我们提到存储数组的内存空间必须是连续的，而当我们需要申请一个非常大的数组时，空闲内存中可能没有这么大的连续空间。
 
-相对地，链表则更加灵活，可以被存储到非连续的内存空间。「链表 Linked List」是一种线性数据结构，其中每个元素都是单独的对象，各个元素（即结点）之间通过指针连接。由于结点中记录了连接关系，因此链表的存储方式相比于数组更加灵活，系统可将结点分散在内存各处，而不必保证内存地址的连续性。
+与数组相比，链表更具灵活性，因为它可以存储在非连续的内存空间。「链表 Linked List」是一种线性数据结构，其每个元素都是一个结点对象，各个结点之间通过指针连接，从当前结点通过指针可以访问到下一个结点。由于指针记录了下个结点的内存地址，因此无需保证内存地址的连续性，从而可以将各个结点分散存储在内存各处。
 
-链表的「结点 Node」包含两项数据，一是结点「值 Value」，二是指向下一结点的「指针 Pointer」（或称「引用 Reference」）。
+链表「结点 Node」包含两项数据，一是结点「值 Value」，二是指向下一结点的「指针 Pointer」，或称指向下一结点的「引用 Reference」。
 
 ![链表定义与存储方式](linked_list.assets/linkedlist_definition.png)
 
@@ -154,13 +154,15 @@
     }
     ```
 
-**尾结点指向什么？** 我们一般将链表的最后一个结点称为「尾结点」，其指向的是「空」，在 Java / C++ / Python 中分别记为 `null` / `nullptr` / `None` 。在不引起歧义下，本书都使用 `null` 来表示空。
+!!! question "尾结点指向什么？"
 
-**链表初始化方法**。建立链表分为两步，第一步是初始化各个结点对象，第二步是构建引用指向关系。完成后，即可以从链表的首个结点（即头结点）出发，访问其余所有的结点。
+    我们将链表的最后一个结点称为「尾结点」，其指向的是“空”，在 Java, C++, Python 中分别记为 `null`, `nullptr`, `None` 。在不引起歧义的前提下，本书都使用 `null` 来表示空。
 
-!!! tip
+!!! question "如何称呼链表？"
 
-    我们通常将头结点当作链表的代称，例如头结点 `head` 和链表 `head` 实际上是同义的。
+    在编程语言中，数组整体就是一个变量，例如数组 `nums` ，包含各个元素 `nums[0]` , `nums[1]` 等等。而链表是由多个结点对象组成，我们通常将头结点当作链表的代称，例如头结点 `head` 和链表 `head` 实际上是同义的。
+
+**链表初始化方法**。建立链表分为两步，第一步是初始化各个结点对象，第二步是构建引用指向关系。完成后，即可以从链表的头结点（即首个结点）出发，通过指针 `next` 依次访问所有结点。
 
 === "Java"
 
@@ -223,7 +225,6 @@
     n2 := NewListNode(2)
     n3 := NewListNode(5)
     n4 := NewListNode(4)
-    
     // 构建引用指向
     n0.Next = n1
     n1.Next = n2
@@ -335,7 +336,7 @@
 
 ## 链表优点
 
-**在链表中，插入与删除结点的操作效率高**。比如，如果我们想在链表中间的两个结点 `A` , `B` 之间插入一个新结点 `P` ，我们只需要改变两个结点指针即可，时间复杂度为 $O(1)$ ，相比数组的插入操作高效很多。
+**链表中插入与删除结点的操作效率高**。例如，如果我们想在链表中间的两个结点 `A` , `B` 之间插入一个新结点 `P` ，我们只需要改变两个结点指针即可，时间复杂度为 $O(1)$ ；相比之下，数组的插入操作效率要低得多。
 
 ![链表插入结点](linked_list.assets/linkedlist_insert_node.png)
 
@@ -399,7 +400,7 @@
     [class]{}-[func]{insert}
     ```
 
-在链表中删除结点也很方便，只需要改变一个结点指针即可。如下图所示，虽然在完成删除后结点 `P` 仍然指向 `n1` ，但实际上 `P` 已经不属于此链表了，因为遍历此链表是无法访问到 `P` 的。
+在链表中删除结点也非常方便，只需改变一个结点的指针即可。如下图所示，尽管在删除操作完成后，结点 `P` 仍然指向 `n1`，但实际上 `P` 已经不再属于此链表，因为遍历此链表时无法访问到 `P`。
 
 ![链表删除结点](linked_list.assets/linkedlist_remove_node.png)
 
@@ -465,7 +466,7 @@
 
 ## 链表缺点
 
-**链表访问结点效率低**。上节提到，数组可以在 $O(1)$ 时间下访问任意元素，但链表无法直接访问任意结点。这是因为计算机需要从头结点出发，一个一个地向后遍历到目标结点。例如，倘若想要访问链表索引为 `index` （即第 `index + 1` 个）的结点，那么需要 `index` 次访问操作。
+**链表访问结点效率较低**。如上节所述，数组可以在 $O(1)$ 时间下访问任意元素。然而，链表无法直接访问任意结点，这是因为系统需要从头结点出发，逐个向后遍历直至找到目标结点。例如，若要访问链表索引为 `index`（即第 `index + 1` 个）的结点，则需要向后遍历 `index` 轮。
 
 === "Java"
 
@@ -527,7 +528,7 @@
     [class]{}-[func]{access}
     ```
 
-**链表的内存占用多**。链表以结点为单位，每个结点除了保存值外，还需额外保存指针（引用）。这意味着同样数据量下，链表比数组需要占用更多内存空间。
+**链表的内存占用较大**。链表以结点为单位，每个结点除了保存值之外，还需额外保存指针（引用）。这意味着在相同数据量的情况下，链表比数组需要占用更多的内存空间。
 
 ## 链表常用操作
 
@@ -595,11 +596,11 @@
 
 ## 常见链表类型
 
-**单向链表**。即上述介绍的普通链表。单向链表的结点有「值」和指向下一结点的「指针（引用）」两项数据。我们将首个结点称为头结点，尾结点指向 `null` 。
+**单向链表**。即上述介绍的普通链表。单向链表的结点包含值和指向下一结点的指针（引用）两项数据。我们将首个结点称为头结点，将最后一个结点成为尾结点，尾结点指向 `null` 。
 
-**环形链表**。如果我们令单向链表的尾结点指向头结点（即首尾相接），则得到一个环形链表。在环形链表中，我们可以将任意结点看作是头结点。
+**环形链表**。如果我们令单向链表的尾结点指向头结点（即首尾相接），则得到一个环形链表。在环形链表中，任意结点都可以视作头结点。
 
-**双向链表**。单向链表仅记录了一个方向的指针（引用），在双向链表的结点定义中，同时有指向下一结点（后继结点）和上一结点（前驱结点）的「指针（引用）」。双向链表相对于单向链表更加灵活，即可以朝两个方向遍历链表，但也需要占用更多的内存空间。
+**双向链表**。与单向链表相比，双向链表记录了两个方向的指针（引用）。双向链表的结点定义同时包含指向后继结点（下一结点）和前驱结点（上一结点）的指针。相较于单向链表，双向链表更具灵活性，可以朝两个方向遍历链表，但相应地也需要占用更多的内存空间。
 
 === "Java"
 
diff --git a/docs/chapter_array_and_linkedlist/list.md b/docs/chapter_array_and_linkedlist/list.md
index 0921a0c0b..1cc270156 100755
--- a/docs/chapter_array_and_linkedlist/list.md
+++ b/docs/chapter_array_and_linkedlist/list.md
@@ -1,12 +1,12 @@
 # 列表
 
-**由于长度不可变，数组的实用性大大降低**。在很多情况下，我们事先并不知道会输入多少数据，这就为数组长度的选择带来了很大困难。长度选小了，需要在添加数据中频繁地扩容数组；长度选大了，又造成内存空间的浪费。
+**数组长度不可变导致实用性降低**。在许多情况下，我们事先无法确定需要存储多少数据，这使数组长度的选择变得困难。若长度过小，需要在持续添加数据时频繁扩容数组；若长度过大，则会造成内存空间的浪费。
 
-为了解决此问题，诞生了一种被称为「列表 List」的数据结构。列表可以被理解为长度可变的数组，因此也常被称为「动态数组 Dynamic Array」。列表基于数组实现，继承了数组的优点，同时还可以在程序运行中实时扩容。在列表中，我们可以自由地添加元素，而不用担心超过容量限制。
+为解决此问题，出现了一种被称为「动态数组 Dynamic Array」的数据结构，即长度可变的数组，也常被称为「列表 List」。列表基于数组实现，继承了数组的优点，并且可以在程序运行过程中动态扩容。在列表中，我们可以自由添加元素，而无需担心超过容量限制。
 
 ## 列表常用操作
 
-**初始化列表**。我们通常会使用到“无初始值”和“有初始值”的两种初始化方法。
+**初始化列表**。通常我们会使用“无初始值”和“有初始值”的两种初始化方法。
 
 === "Java"
 
@@ -106,7 +106,7 @@
     try list.appendSlice(&[_]i32{ 1, 3, 2, 5, 4 });
     ```
 
-**访问与更新元素**。列表的底层数据结构是数组，因此可以在 $O(1)$ 时间内访问与更新元素，效率很高。
+**访问与更新元素**。由于列表的底层数据结构是数组，因此可以在 $O(1)$ 时间内访问和更新元素，效率很高。
 
 === "Java"
 
@@ -204,7 +204,7 @@
     list.items[1] = 0; // 将索引 1 处的元素更新为 0  
     ```
 
-**在列表中添加、插入、删除元素**。相对于数组，列表可以自由地添加与删除元素。在列表尾部添加元素的时间复杂度为 $O(1)$ ，但是插入与删除元素的效率仍与数组一样低，时间复杂度为 $O(N)$ 。
+**在列表中添加、插入、删除元素**。相较于数组，列表可以自由地添加与删除元素。在列表尾部添加元素的时间复杂度为 $O(1)$ ，但插入和删除元素的效率仍与数组相同，时间复杂度为 $O(N)$ 。
 
 === "Java"
 
@@ -392,7 +392,7 @@
     _ = list.orderedRemove(3); // 删除索引 3 处的元素
     ```
 
-**遍历列表**。与数组一样，列表可以使用索引遍历，也可以使用 `for-each` 直接遍历。
+**遍历列表**。与数组一样，列表可以根据索引遍历，也可以直接遍历各元素。
 
 === "Java"
 
@@ -545,7 +545,7 @@
     }
     ```
 
-**拼接两个列表**。再创建一个新列表 `list1` ，我们可以将其中一个列表拼接到另一个的尾部。
+**拼接两个列表**。给定一个新列表 `list1`，我们可以将该列表拼接到原列表的尾部。
 
 === "Java"
 
@@ -628,7 +628,7 @@
     try list.insertSlice(list.items.len, list1.items); // 将列表 list1 拼接到 list 之后
     ```
 
-**排序列表**。排序也是常用的方法之一，完成列表排序后，我们就可以使用在数组类算法题中经常考察的「二分查找」和「双指针」算法了。
+**排序列表**。排序也是常用的方法之一。完成列表排序后，我们便可以使用在数组类算法题中经常考察的「二分查找」和「双指针」算法。
 
 === "Java"
 
@@ -699,15 +699,15 @@
     std.sort.sort(i32, list.items, {}, comptime std.sort.asc(i32));
     ```
 
-## 列表简易实现 *
+## 列表实现 *
 
-为了帮助加深对列表的理解，我们在此提供一个列表的简易版本的实现。需要关注三个核心点：
+为了帮助加深对列表的理解，我们在此提供一个简易版列表实现。需要关注三个核心点：
 
-- **初始容量**：选取一个合理的数组的初始容量 `initialCapacity` 。在本示例中，我们选择 10 作为初始容量。
-- **数量记录**：需要声明一个变量 `size` ，用来记录列表当前有多少个元素，并随着元素插入与删除实时更新。根据此变量，可以定位列表的尾部，以及判断是否需要扩容。
-- **扩容机制**：插入元素有可能导致超出列表容量，此时需要扩容列表，方法是建立一个更大的数组来替换当前数组。需要给定一个扩容倍数 `extendRatio` ，在本示例中，我们规定每次将数组扩容至之前的 2 倍。
+- **初始容量**：选取一个合理的数组初始容量。在本示例中，我们选择 10 作为初始容量。
+- **数量记录**：声明一个变量 size，用于记录列表当前元素数量，并随着元素插入和删除实时更新。根据此变量，我们可以定位列表尾部，以及判断是否需要扩容。
+- **扩容机制**：插入元素时可能超出列表容量，此时需要扩容列表。扩容方法是根据扩容倍数创建一个更大的数组，并将当前数组的所有元素依次移动至新数组。在本示例中，我们规定每次将数组扩容至之前的 2 倍。
 
-本示例是为了帮助读者对如何实现列表产生直观的认识。实际编程语言中，列表的实现远比以下代码复杂且标准，感兴趣的读者可以查阅源码学习。
+本示例旨在帮助读者直观理解列表的工作机制。实际编程语言中，列表实现更加标准和复杂，各个参数的设定也非常有考究，例如初始容量、扩容倍数等。感兴趣的读者可以查阅源码进行学习。
 
 === "Java"
 
diff --git a/docs/chapter_array_and_linkedlist/summary.md b/docs/chapter_array_and_linkedlist/summary.md
index 280ba75b3..996e53086 100644
--- a/docs/chapter_array_and_linkedlist/summary.md
+++ b/docs/chapter_array_and_linkedlist/summary.md
@@ -1,10 +1,10 @@
 # 小结
 
-- 数组和链表是两种基本数据结构，代表了数据在计算机内存中的两种存储方式，即连续空间存储和离散空间存储。两者的优点与缺点呈现出此消彼长的关系。
-- 数组支持随机访问、内存空间占用小；但插入与删除元素效率低，且初始化后长度不可变。
-- 链表可通过更改指针实现高效的结点插入与删除，并且可以灵活地修改长度；但结点访问效率低、占用内存多。常见的链表类型有单向链表、循环链表、双向链表。
-- 列表又称动态数组，是基于数组实现的一种数据结构，其保存了数组的优势，且可以灵活改变长度。列表的出现大大提升了数组的实用性，但副作用是会造成部分内存空间浪费。
-- 下表总结对比了数组与链表的各项特性。
+- 数组和链表是两种基本数据结构，分别代表数据在计算机内存中的连续空间存储和离散空间存储方式。两者的优缺点呈现出互补的特性。
+- 数组支持随机访问、占用内存较少；但插入和删除元素效率低，且初始化后长度不可变。
+- 链表通过更改指针实现高效的结点插入与删除，且可以灵活调整长度；但结点访问效率低、占用内存较多。常见的链表类型包括单向链表、循环链表、双向链表。
+- 动态数组，又称列表，是基于数组实现的一种数据结构。它保留了数组的优势，同时可以灵活调整长度。列表的出现极大地提高了数组的易用性，但可能导致部分内存空间浪费。
+- 下表总结并对比了数组与链表的各项特性。
 
 <div class="center-table" markdown>
 
@@ -17,11 +17,11 @@
 
 </div>
 
-!!! question "缓存局部性的简单解释"
+!!! note "缓存局部性"
 
     在计算机中，数据读写速度排序是“硬盘 < 内存 < CPU 缓存”。当我们访问数组元素时，计算机不仅会加载它，还会缓存其周围的其它数据，从而借助高速缓存来提升后续操作的执行速度。链表则不然，计算机只能挨个地缓存各个结点，这样的多次“搬运”降低了整体效率。
 
-- 下表对比了数组与链表的各种操作效率。
+- 下表对比了数组与链表在各种操作上的效率。
 
 <div class="center-table" markdown>
 
diff --git a/docs/chapter_computational_complexity/performance_evaluation.md b/docs/chapter_computational_complexity/performance_evaluation.md
index 519321b58..ccbc323ee 100644
--- a/docs/chapter_computational_complexity/performance_evaluation.md
+++ b/docs/chapter_computational_complexity/performance_evaluation.md
@@ -2,44 +2,44 @@
 
 ## 算法评价维度
 
-在开始学习算法之前，我们首先要想清楚算法的设计目标是什么，或者说，如何来评判算法的好与坏。整体上看，我们设计算法时追求两个层面的目标。
+在开始学习算法之前，我们首先需要明确算法的设计目标，换句话说，我们应该如何评判算法的优劣。从总体上看，算法设计追求以下两个层面的目标：
 
-1. **找到问题解法**。算法需要能够在规定的输入范围下，可靠地求得问题的正确解。
-2. **寻求最优解法**。同一个问题可能存在多种解法，而我们希望算法效率尽可能的高。
+1. **找到问题解法**。算法需要在规定的输入范围内，可靠地求得问题的正确解。
+2. **寻求最优解法**。同一个问题可能存在多种解法，我们希望找到尽可能高效的算法。
 
-换言之，在可以解决问题的前提下，算法效率则是主要评价维度，包括：
+因此，在能够解决问题的前提下，算法效率成为主要的评价维度，主要包括：
 
-- **时间效率**，即算法的运行速度的快慢。
-- **空间效率**，即算法占用的内存空间大小。
+- **时间效率**，即算法运行速度的快慢。
+- **空间效率**，即算法占用内存空间的大小。
 
-数据结构与算法追求“运行速度快、占用内存少”，而如何去评价算法效率则是非常重要的问题，因为只有知道如何评价算法，才能去做算法之间的对比分析，以及优化算法设计。
+数据结构与算法的终极目标是“又快又省”。了解如何评估算法效率非常重要，因为只有掌握了评价方法，我们才能进行算法间的对比分析，从而指导算法设计与优化。
 
 ## 效率评估方法
 
 ### 实际测试
 
-假设我们现在有算法 A 和 算法 B ，都能够解决同一问题，现在需要对比两个算法之间的效率。我们能够想到的最直接的方式，就是找一台计算机，把两个算法都完整跑一遍，并监控记录运行时间和内存占用情况。这种评估方式能够反映真实情况，但是也存在很大的硬伤。
+假设我们现在有算法 A 和算法 B，它们都能解决同一问题，现在需要对比这两个算法的效率。我们最直接的方法就是找一台计算机，运行这两个算法，并监控记录它们的运行时间和内存占用情况。这种评估方式能够反映真实情况，但也存在较大局限性。
 
-**难以排除测试环境的干扰因素**。硬件配置会影响到算法的性能表现。例如，在某台计算机中，算法 A 比算法 B 运行时间更短；但换到另一台配置不同的计算机中，可能会得到相反的测试结果。这意味着我们需要在各种机器上展开测试，而这是不现实的。
+**难以排除测试环境的干扰因素**。硬件配置会影响算法的性能表现。例如，在某台计算机中，算法 A 的运行时间比算法 B 短；但在另一台配置不同的计算机中，我们可能得到相反的测试结果。这意味着我们需要在各种机器上进行测试，而这是不现实的。
 
-**展开完整测试非常耗费资源**。随着输入数据量的大小变化，算法会呈现出不同的效率表现。比如，有可能输入数据量较小时，算法 A 运行时间短于算法 B ，而在输入数据量较大时，测试结果截然相反。因此，若想要达到具有说服力的对比结果，那么需要输入各种体量数据，这样的测试需要占用大量计算资源。
+**展开完整测试非常耗费资源**。随着输入数据量的变化，算法会表现出不同的效率。例如，输入数据量较小时，算法 A 的运行时间可能短于算法 B；而输入数据量较大时，测试结果可能相反。因此，为了得到有说服力的结论，我们需要测试各种规模的输入数据，这样需要占用大量的计算资源。
 
 ### 理论估算
 
-既然实际测试具有很大的局限性，那么我们是否可以仅通过一些计算，就获知算法的效率水平呢？答案是肯定的，我们将此估算方法称为「复杂度分析 Complexity Analysis」或「渐近复杂度分析 Asymptotic Complexity Analysis」。
+由于实际测试具有较大的局限性，我们可以考虑仅通过一些计算来评估算法的效率。这种估算方法被称为「复杂度分析 Complexity Analysis」或「渐近复杂度分析 Asymptotic Complexity Analysis」。
 
-**复杂度分析评估的是算法运行效率随着输入数据量增多时的增长趋势**。这句话有些拗口，我们可以将其分为三个重点来理解：
+**复杂度分析评估的是算法运行效率随着输入数据量增多时的增长趋势**。这个定义有些拗口，我们可以将其分为三个重点来理解：
 
-- “算法运行效率”可分为“运行时间”和“占用空间”，进而可将复杂度分为「时间复杂度 Time Complexity」和「空间复杂度 Space Complexity」。
-- “随着输入数据量增多时”代表复杂度与输入数据量有关，反映算法运行效率与输入数据量之间的关系；
-- “增长趋势”表示复杂度分析不关心算法具体使用了多少时间或占用了多少空间，而是给出一种“趋势性分析”；
+- “算法运行效率”可分为“运行时间”和“占用空间”，因此我们可以将复杂度分为「时间复杂度 Time Complexity」和「空间复杂度 Space Complexity」；
+- “随着输入数据量增多时”表示复杂度与输入数据量有关，反映了算法运行效率与输入数据量之间的关系；
+- “增长趋势”表示复杂度分析关注的是算法时间与空间的增长趋势，而非具体的运行时间或占用空间；
 
-**复杂度分析克服了实际测试方法的弊端**。一是独立于测试环境，分析结果适用于所有运行平台。二是可以体现不同数据量下的算法效率，尤其是可以反映大数据量下的算法性能。
+**复杂度分析克服了实际测试方法的弊端**。首先，它独立于测试环境，因此分析结果适用于所有运行平台。其次，它可以体现不同数据量下的算法效率，尤其是在大数据量下的算法性能。
 
-如果感觉对复杂度分析的概念一知半解，无需担心，后续章节会展开介绍。
+如果你对复杂度分析的概念仍感到困惑，无需担心，我们会在后续章节详细介绍。
 
 ## 复杂度分析重要性
 
-复杂度分析给出一把评价算法效率的“标尺”，告诉我们执行某个算法需要多少时间和空间资源，也让我们可以开展不同算法之间的效率对比。
+复杂度分析为我们提供了一把评估算法效率的“标尺”，告诉我们执行某个算法所需的时间和空间资源，并使我们能够对比不同算法之间的效率。
 
-复杂度是个数学概念，对于初学者可能比较抽象，学习难度相对较高。从这个角度出发，其并不适合作为第一章内容。但是，当我们讨论某个数据结构或者算法的特点时，难以避免需要分析它的运行速度和空间使用情况。**因此，在展开学习数据结构与算法之前，建议读者先对复杂度建立起初步的了解，并且能够完成简单案例的复杂度分析**。
+复杂度是个数学概念，对于初学者可能比较抽象，学习难度相对较高。从这个角度看，复杂度分析可能不太适合作为第一章的内容。然而，当我们讨论某个数据结构或算法的特点时，我们难以避免要分析其运行速度和空间使用情况。**因此，在深入学习数据结构与算法之前，建议读者先对复杂度建立初步的了解，并能够完成简单案例的复杂度分析**。
diff --git a/docs/chapter_computational_complexity/space_complexity.md b/docs/chapter_computational_complexity/space_complexity.md
index 3cdd1a8a5..0a7f4db23 100755
--- a/docs/chapter_computational_complexity/space_complexity.md
+++ b/docs/chapter_computational_complexity/space_complexity.md
@@ -1,24 +1,24 @@
 # 空间复杂度
 
-「空间复杂度 Space Complexity」统计 **算法使用内存空间随着数据量变大时的增长趋势**。这个概念与时间复杂度很类似。
+「空间复杂度 Space Complexity」用于衡量算法使用内存空间随着数据量变大时的增长趋势。这个概念与时间复杂度非常类似。
 
 ## 算法相关空间
 
-算法运行中，使用的内存空间主要有以下几种：
+算法运行过程中使用的内存空间主要包括以下几种：
 
 - 「输入空间」用于存储算法的输入数据；
-- 「暂存空间」用于存储算法运行中的变量、对象、函数上下文等数据；
+- 「暂存空间」用于存储算法运行过程中的变量、对象、函数上下文等数据；
 - 「输出空间」用于存储算法的输出数据；
 
-!!! tip
+通常情况下，空间复杂度统计范围是「暂存空间」+「输出空间」。
 
-    通常情况下，空间复杂度统计范围是「暂存空间」+「输出空间」。
+暂存空间可以进一步划分为三个部分：
 
-暂存空间可分为三个部分：
+- 「暂存数据」用于保存算法运行过程中的各种常量、变量、对象等。
+- 「栈帧空间」用于保存调用函数的上下文数据。系统在每次调用函数时都会在栈顶部创建一个栈帧，函数返回后，栈帧空间会被释放。
+- 「指令空间」用于保存编译后的程序指令，在实际统计中通常忽略不计。
 
-- 「暂存数据」用于保存算法运行中的各种 **常量、变量、对象** 等。
-- 「栈帧空间」用于保存调用函数的上下文数据。系统每次调用函数都会在栈的顶部创建一个栈帧，函数返回时，栈帧空间会被释放。
-- 「指令空间」用于保存编译后的程序指令，**在实际统计中一般忽略不计**。
+因此，在分析一段程序的空间复杂度时，我们一般统计 **暂存数据、输出数据、栈帧空间** 三部分。
 
 ![算法使用的相关空间](space_complexity.assets/space_types.png)
 
@@ -249,12 +249,12 @@
 
 ## 推算方法
 
-空间复杂度的推算方法和时间复杂度总体类似，只是从统计“计算操作数量”变为统计“使用空间大小”。与时间复杂度不同的是，**我们一般只关注「最差空间复杂度」**。这是因为内存空间是一个硬性要求，我们必须保证在所有输入数据下都有足够的内存空间预留。
+空间复杂度的推算方法与时间复杂度大致相同，只是将统计对象从“计算操作数量”转为“使用空间大小”。与时间复杂度不同的是，**我们通常只关注「最差空间复杂度」**，这是因为内存空间是一项硬性要求，我们必须确保在所有输入数据下都有足够的内存空间预留。
 
-**最差空间复杂度中的“最差”有两层含义**，分别为输入数据的最差分布、算法运行中的最差时间点。
+**最差空间复杂度中的“最差”有两层含义**，分别是输入数据的最差分布和算法运行过程中的最差时间点。
 
-- **以最差输入数据为准**。当 $n < 10$ 时，空间复杂度为 $O(1)$ ；但是当 $n > 10$ 时，初始化的数组 `nums` 使用 $O(n)$ 空间；因此最差空间复杂度为 $O(n)$ ；
-- **以算法运行过程中的峰值内存为准**。程序在执行最后一行之前，使用 $O(1)$ 空间；当初始化数组 `nums` 时，程序使用 $O(n)$ 空间；因此最差空间复杂度为 $O(n)$ ；
+- **以最差输入数据为准**。当 $n < 10$ 时，空间复杂度为 $O(1)$ ；但当 $n > 10$ 时，初始化的数组 `nums` 占用 $O(n)$ 空间；因此最差空间复杂度为 $O(n)$ ；
+- **以算法运行过程中的峰值内存为准**。例如，程序在执行最后一行之前，占用 $O(1)$ 空间；当初始化数组 `nums` 时，程序占用 $O(n)$ 空间；因此最差空间复杂度为 $O(n)$ ；
 
 === "Java"
 
@@ -364,7 +364,7 @@
 
     ```
 
-**在递归函数中，需要注意统计栈帧空间**。例如函数 `loop()`，在循环中调用了 $n$ 次 `function()` ，每轮中的 `function()` 都返回并释放了栈帧空间，因此空间复杂度仍为 $O(1)$ 。而递归函数 `recur()` 在运行中会同时存在 $n$ 个未返回的 `recur()` ，从而使用 $O(n)$ 的栈帧空间。
+**在递归函数中，需要注意统计栈帧空间**。例如，函数 `loop()` 在循环中调用了 $n$ 次 `function()`，每轮中的 `function()` 都返回并释放了栈帧空间，因此空间复杂度仍为 $O(1)$ 。而递归函数 `recur()` 在运行过程中会同时存在 $n$ 个未返回的 `recur()`，从而占用 $O(n)$ 的栈帧空间。
 
 === "Java"
 
@@ -564,7 +564,7 @@ $$
 
 !!! tip
 
-    部分示例代码需要一些前置知识，包括数组、链表、二叉树、递归算法等。如果遇到看不懂的地方无需担心，可以在学习完后面章节后再来复习，现阶段先聚焦在理解空间复杂度含义和推算方法上。
+    部分示例代码需要一些前置知识，包括数组、链表、二叉树、递归算法等。如果遇到看不懂的地方无需担心，可以在学习完后面章节后再来复习，现阶段我们先专注于理解空间复杂度的含义和推算方法。
 
 ### 常数阶 $O(1)$
 
@@ -762,7 +762,7 @@ $$
 
 ### 平方阶 $O(n^2)$
 
-平方阶常见于元素数量与 $n$ 成平方关系的矩阵、图。
+平方阶常见于矩阵和图，元素数量与 $n$ 成平方关系。
 
 === "Java"
 
@@ -824,7 +824,7 @@ $$
     [class]{}-[func]{quadratic}
     ```
 
-在以下递归函数中，同时存在 $n$ 个未返回的 `algorithm()` ，并且每个函数中都初始化了一个数组，长度分别为 $n, n-1, n-2, ..., 2, 1$ ，平均长度为 $\frac{n}{2}$ ，因此总体使用 $O(n^2)$ 空间。
+在以下递归函数中，同时存在 $n$ 个未返回的 `algorithm()`，并且每个函数中都初始化了一个数组，长度分别为 $n, n-1, n-2, ..., 2, 1$ ，平均长度为 $\frac{n}{2}$ ，因此总体占用 $O(n^2)$ 空间。
 
 === "Java"
 
@@ -890,7 +890,7 @@ $$
 
 ### 指数阶 $O(2^n)$
 
-指数阶常见于二叉树。高度为 $n$ 的「满二叉树」的结点数量为 $2^n - 1$ ，使用 $O(2^n)$ 空间。
+指数阶常见于二叉树。高度为 $n$ 的「满二叉树」的节点数量为 $2^n - 1$ ，占用 $O(2^n)$ 空间。
 
 === "Java"
 
@@ -956,8 +956,8 @@ $$
 
 ### 对数阶 $O(\log n)$
 
-对数阶常见于分治算法、数据类型转换等。
+对数阶常见于分治算法和数据类型转换等。
 
-例如「归并排序」，长度为 $n$ 的数组可以形成高度为 $\log n$ 的递归树，因此空间复杂度为 $O(\log n)$ 。
+例如“归并排序”算法，输入长度为 $n$ 的数组，每轮递归将数组从中点划分为两半，形成高度为 $\log n$ 的递归树，使用 $O(\log n)$ 栈帧空间。
 
-再例如「数字转化为字符串」，输入任意正整数 $n$ ，它的位数为 $\log_{10} n$ ，即对应字符串长度为 $\log_{10} n$ ，因此空间复杂度为 $O(\log_{10} n) = O(\log n)$ 。
+再例如“数字转化为字符串”，输入任意正整数 $n$ ，它的位数为 $\log_{10} n$ ，即对应字符串长度为 $\log_{10} n$ ，因此空间复杂度为 $O(\log_{10} n) = O(\log n)$ 。
diff --git a/docs/chapter_computational_complexity/space_time_tradeoff.md b/docs/chapter_computational_complexity/space_time_tradeoff.md
index 07a8064e1..409f6b59e 100755
--- a/docs/chapter_computational_complexity/space_time_tradeoff.md
+++ b/docs/chapter_computational_complexity/space_time_tradeoff.md
@@ -1,10 +1,10 @@
 # 权衡时间与空间
 
-理想情况下，我们希望算法的时间复杂度和空间复杂度都能够达到最优，而实际上，同时优化时间复杂度和空间复杂度是非常困难的。
+理想情况下，我们希望算法的时间复杂度和空间复杂度都能达到最优。然而在实际情况中，同时优化时间复杂度和空间复杂度通常是非常困难的。
 
-**降低时间复杂度，往往是以提升空间复杂度为代价的，反之亦然**。我们把牺牲内存空间来提升算法运行速度的思路称为「以空间换时间」；反之，称之为「以时间换空间」。选择哪种思路取决于我们更看重哪个方面。
+**降低时间复杂度通常需要以提升空间复杂度为代价，反之亦然**。我们将牺牲内存空间来提升算法运行速度的思路称为「以空间换时间」；反之，则称之为「以时间换空间」。
 
-大多数情况下，时间都是比空间更宝贵的，只要空间复杂度不要太离谱、能接受就行，**因此以空间换时间最为常用**。
+选择哪种思路取决于我们更看重哪个方面。在大多数情况下，时间比空间更宝贵，因此以空间换时间通常是更常用的策略。当然，在数据量很大的情况下，控制空间复杂度也是非常重要的。
 
 ## 示例题目 *
 
@@ -13,16 +13,16 @@
 !!! question "两数之和"
 
     给定一个整数数组 `nums` 和一个整数目标值 `target` ，请你在该数组中找出“和”为目标值 `target` 的那两个整数，并返回它们的数组下标。
-    
+
     你可以假设每种输入只会对应一个答案。但是，数组中同一个元素在答案里不能重复出现。
-    
+
     你可以按任意顺序返回答案。
 
-「暴力枚举」和「辅助哈希表」分别对应 **空间最优** 和 **时间最优** 的两种解法。本着时间比空间更宝贵的原则，后者是本题的最佳解法。
+「暴力枚举」和「辅助哈希表」分别对应“空间最优”和“时间最优”的两种解法。遵循时间比空间更宝贵的原则，后者是本题的最佳解法。
 
 ### 方法一：暴力枚举
 
-考虑直接遍历所有所有可能性。通过开启一个两层循环，判断两个整数的和是否为 `target` ，若是则返回它俩的索引（即下标）即可。
+考虑直接遍历所有可能的组合。通过开启一个两层循环，判断两个整数的和是否为 `target` ，若是，则返回它们的索引（即下标）。
 
 === "Java"
 
@@ -84,11 +84,11 @@
     [class]{}-[func]{twoSumBruteForce}
     ```
 
-该方法的时间复杂度为 $O(N^2)$ ，空间复杂度为 $O(1)$ ，**属于时间换空间**。本方法时间复杂度较高，在大数据量下非常耗时。
+该方法的时间复杂度为 $O(n^2)$ ，空间复杂度为 $O(1)$ ，**属于以时间换空间**。此方法时间复杂度太高，在大数据量下非常耗时。
 
 ### 方法二：辅助哈希表
 
-考虑借助一个哈希表，key 为数组元素、value 为元素索引。循环遍历数组中的每个元素 `num` ，并执行：
+考虑借助一个哈希表，key-value 分别为数组元素和元素索引。循环遍历数组中的每个元素 num，并执行：
 
 1. 判断数字 `target - num` 是否在哈希表中，若是则直接返回该两个元素的索引；
 2. 将元素 `num` 和其索引添加进哈希表；
@@ -153,4 +153,4 @@
     [class]{}-[func]{twoSumHashTable}
     ```
 
-该方法的时间复杂度为 $O(N)$ ，空间复杂度为 $O(N)$ ，**体现空间换时间**。本方法虽然引入了额外空间使用，但时间和空间使用整体更加均衡，因此为本题最优解法。
+该方法的时间复杂度为 $O(N)$ ，空间复杂度为 $O(N)$ ，**体现了以空间换时间**。尽管此方法引入了额外的空间使用，但在时间和空间的整体效率更为均衡，因此它是本题的最优解法。
diff --git a/docs/chapter_computational_complexity/summary.md b/docs/chapter_computational_complexity/summary.md
index e4e1d5773..9f2e84174 100644
--- a/docs/chapter_computational_complexity/summary.md
+++ b/docs/chapter_computational_complexity/summary.md
@@ -2,22 +2,22 @@
 
 ### 算法效率评估
 
-- 时间效率和空间效率是算法性能的两个重要的评价维度。
-- 我们可以通过实际测试来评估算法效率，但难以排除测试环境的干扰，并且非常耗费计算资源。
-- 复杂度分析克服了实际测试的弊端，分析结果适用于所有运行平台，并且可以体现不同数据大小下的算法效率。
+- 时间效率和空间效率是评价算法性能的两个关键维度。
+- 我们可以通过实际测试来评估算法效率，但难以消除测试环境的影响，且会耗费大量计算资源。
+- 复杂度分析可以克服实际测试的弊端，分析结果适用于所有运行平台，并且能够揭示算法在不同数据规模下的效率。
 
 ### 时间复杂度
 
-- 时间复杂度统计算法运行时间随着数据量变大时的增长趋势，可以有效评估算法效率，但在某些情况下可能失效，比如在输入数据量较小或时间复杂度相同时，无法精确对比算法效率的优劣性。
-- 最差时间复杂度使用大 $O$ 符号表示，即函数渐近上界，其反映当 $n$ 趋于正无穷时，$T(n)$ 处于何种增长级别。
-- 推算时间复杂度分为两步，首先统计计算操作数量，再判断渐近上界。
-- 常见时间复杂度从小到大排列有 $O(1)$ , $O(\log n)$ , $O(n)$ , $O(n \log n)$ , $O(n^2)$ , $O(2^n)$ , $O(n!)$ 。
-- 某些算法的时间复杂度不是恒定的，而是与输入数据的分布有关。时间复杂度分为最差时间复杂度和最佳时间复杂度，后者几乎不用，因为输入数据需要满足苛刻的条件才能达到最佳情况。
-- 平均时间复杂度可以反映在随机数据输入下的算法效率，最贴合实际使用情况下的算法性能。计算平均时间复杂度需要统计输入数据的分布，以及综合后的数学期望。
+- 时间复杂度用于衡量算法运行时间随数据量增长的趋势，可以有效评估算法效率，但在某些情况下可能失效，如在输入数据量较小或时间复杂度相同时，无法精确对比算法效率的优劣。
+- 最差时间复杂度使用大 $O$ 符号表示，即函数渐进上界，反映当 $n$ 趋向正无穷时，$T(n)$ 的增长级别。
+- 推算时间复杂度分为两步，首先统计计算操作数量，然后判断渐进上界。
+- 常见时间复杂度从小到大排列有 $O(1)$ , $O(\log n)$ , $O(n)$ , $O(n \log n)$ , $O(n^2)$ , $O(2^n)$ , $O(n!)$ 等。
+- 某些算法的时间复杂度非固定，而是与输入数据的分布有关。时间复杂度分为最差、最佳、平均时间复杂度，最佳时间复杂度几乎不用，因为输入数据一般需要满足严格条件才能达到最佳情况。
+- 平均时间复杂度反映算法在随机数据输入下的运行效率，最接近实际应用中的算法性能。计算平均时间复杂度需要统计输入数据分布以及综合后的数学期望。
 
 ### 空间复杂度
 
-- 与时间复杂度的定义类似，空间复杂度统计算法占用空间随着数据量变大时的增长趋势。
-- 算法运行中相关内存空间可分为输入空间、暂存空间、输出空间。通常情况下，输入空间不计入空间复杂度计算。暂存空间可分为指令空间、数据空间、栈帧空间，其中栈帧空间一般在递归函数中才会影响到空间复杂度。
-- 我们一般只关心最差空间复杂度，即统计算法在最差输入数据和最差运行时间点下的空间复杂度。
-- 常见空间复杂度从小到大排列有 $O(1)$ , $O(\log n)$ , $O(n)$ , $O(n^2)$ , $O(2^n)$ 。
+- 类似于时间复杂度，空间复杂度用于衡量算法占用空间随数据量增长的趋势。
+- 算法运行过程中的相关内存空间可分为输入空间、暂存空间、输出空间。通常情况下，输入空间不计入空间复杂度计算。暂存空间可分为指令空间、数据空间、栈帧空间，其中栈帧空间通常仅在递归函数中影响空间复杂度。
+- 我们通常只关注最差空间复杂度，即统计算法在最差输入数据和最差运行时间点下的空间复杂度。
+- 常见空间复杂度从小到大排列有 $O(1)$ , $O(\log n)$ , $O(n)$ , $O(n^2)$ , $O(2^n)$ 等。
diff --git a/docs/chapter_computational_complexity/time_complexity.md b/docs/chapter_computational_complexity/time_complexity.md
index 6bb3e1c9c..eee3867ec 100755
--- a/docs/chapter_computational_complexity/time_complexity.md
+++ b/docs/chapter_computational_complexity/time_complexity.md
@@ -2,11 +2,11 @@
 
 ## 统计算法运行时间
 
-运行时间能够直观且准确地体现出算法的效率水平。如果我们想要 **准确预估一段代码的运行时间** ，该如何做呢？
+运行时间可以直观且准确地反映算法的效率。然而，如果我们想要准确预估一段代码的运行时间，应该如何操作呢？
 
-1. 首先需要 **确定运行平台** ，包括硬件配置、编程语言、系统环境等，这些都会影响到代码的运行效率。
-2. 评估 **各种计算操作的所需运行时间** ，例如加法操作 `+` 需要 1 ns ，乘法操作 `*` 需要 10 ns ，打印操作需要 5 ns 等。
-3. 根据代码 **统计所有计算操作的数量** ，并将所有操作的执行时间求和，即可得到运行时间。
+1. **确定运行平台**，包括硬件配置、编程语言、系统环境等，这些因素都会影响代码的运行效率。
+2. **评估各种计算操作所需的运行时间**，例如加法操作 `+` 需要 1 ns，乘法操作 `*` 需要 10 ns，打印操作需要 5 ns 等。
+3. **统计代码中所有的计算操作**，并将所有操作的执行时间求和，从而得到运行时间。
 
 例如以下代码，输入数据大小为 $n$ ，根据以上方法，可以得到算法运行时间为 $6n + 12$ ns 。
 
@@ -155,16 +155,16 @@ $$
 
     ```
 
-但实际上， **统计算法的运行时间既不合理也不现实**。首先，我们不希望预估时间和运行平台绑定，毕竟算法需要跑在各式各样的平台之上。其次，我们很难获知每一种操作的运行时间，这为预估过程带来了极大的难度。
+然而实际上，**统计算法的运行时间既不合理也不现实**。首先，我们不希望预估时间和运行平台绑定，因为算法需要在各种不同的平台上运行。其次，我们很难获知每种操作的运行时间，这给预估过程带来了极大的难度。
 
 ## 统计时间增长趋势
 
-「时间复杂度分析」采取了不同的做法，其统计的不是算法运行时间，而是 **算法运行时间随着数据量变大时的增长趋势** 。
+「时间复杂度分析」采取了一种不同的方法，其统计的不是算法运行时间，**而是算法运行时间随着数据量变大时的增长趋势**。
 
-“时间增长趋势”这个概念比较抽象，我们借助一个例子来理解。设输入数据大小为 $n$ ，给定三个算法 `A` , `B` , `C` 。
+“时间增长趋势”这个概念较为抽象，我们通过一个例子来加以理解。假设输入数据大小为 $n$，给定三个算法 `A`，`B`，`C` 。
 
 - 算法 `A` 只有 $1$ 个打印操作，算法运行时间不随着 $n$ 增大而增长。我们称此算法的时间复杂度为「常数阶」。
-- 算法 `B` 中的打印操作需要循环 $n$ 次，算法运行时间随着 $n$ 增大成线性增长。此算法的时间复杂度被称为「线性阶」。
+- 算法 `B` 中的打印操作需要循环 $n$ 次，算法运行时间随着 $n$ 增大呈线性增长。此算法的时间复杂度被称为「线性阶」。
 - 算法 `C` 中的打印操作需要循环 $1000000$ 次，但运行时间仍与输入数据大小 $n$ 无关。因此 `C` 的时间复杂度和 `A` 相同，仍为「常数阶」。
 
 === "Java"
@@ -367,17 +367,17 @@ $$
 
 ![算法 A, B, C 的时间增长趋势](time_complexity.assets/time_complexity_simple_example.png)
 
-相比直接统计算法运行时间，时间复杂度分析的做法有什么好处呢？以及有什么不足？
+相较于直接统计算法运行时间，时间复杂度分析有哪些优势和局限性呢？
 
-**时间复杂度可以有效评估算法效率**。算法 `B` 运行时间的增长是线性的，在 $n > 1$ 时慢于算法 `A` ，在 $n > 1000000$ 时慢于算法 `C` 。实质上，只要输入数据大小 $n$ 足够大，复杂度为「常数阶」的算法一定优于「线性阶」的算法，这也正是时间增长趋势的含义。
+**时间复杂度能够有效评估算法效率**。例如，算法 `B` 的运行时间呈线性增长，在 $n > 1$ 时比算法 `A` 慢，在 $n > 1000000$ 时比算法 `C` 慢。事实上，只要输入数据大小 $n$ 足够大，复杂度为「常数阶」的算法一定优于「线性阶」的算法，这正是时间增长趋势所表达的含义。
 
-**时间复杂度的推算方法更加简便**。在时间复杂度分析中，我们可以将统计「计算操作的运行时间」简化为统计「计算操作的数量」，这是因为，无论是运行平台还是计算操作类型，都与算法运行时间的增长趋势无关。因而，我们可以简单地将所有计算操作的执行时间统一看作是相同的“单位时间”，这样的简化做法大大降低了估算难度。
+**时间复杂度的推算方法更简便**。显然，运行平台和计算操作类型都与算法运行时间的增长趋势无关。因此在时间复杂度分析中，我们可以简单地将所有计算操作的执行时间视为相同的“单位时间”，从而将“计算操作的运行时间的统计”简化为“计算操作的数量的统计”，这样的简化方法大大降低了估算难度。
 
-**时间复杂度也存在一定的局限性**。比如，虽然算法 `A` 和 `C` 的时间复杂度相同，但是实际的运行时间有非常大的差别。再比如，虽然算法 `B` 比 `C` 的时间复杂度要更高，但在输入数据大小 $n$ 比较小时，算法 `B` 是要明显优于算法 `C` 的。对于以上情况，我们很难仅凭时间复杂度来判定算法效率高低。然而，即使存在这些问题，复杂度分析仍然是评判算法效率的最有效且常用的方法。
+**时间复杂度也存在一定的局限性**。例如，尽管算法 `A` 和 `C` 的时间复杂度相同，但实际运行时间差别很大。同样，尽管算法 `B` 的时间复杂度比 `C` 高，但在输入数据大小 $n$ 较小时，算法 `B` 明显优于算法 `C` 。在这些情况下，我们很难仅凭时间复杂度判断算法效率高低。当然，尽管存在上述问题，复杂度分析仍然是评判算法效率最有效且常用的方法。
 
 ## 函数渐近上界
 
-设算法「计算操作数量」为 $T(n)$ ，其是一个关于输入数据大小 $n$ 的函数。例如，以下算法的操作数量为
+设算法的计算操作数量是一个关于输入数据大小 $n$ 的函数，记为 $T(n)$ ，则以下算法的操作数量为
 
 $$
 T(n) = 3 + 2n
@@ -515,11 +515,11 @@ $$
 
     ```
 
-$T(n)$ 是个一次函数，说明时间增长趋势是线性的，因此易得时间复杂度是线性阶。
+$T(n)$ 是一次函数，说明时间增长趋势是线性的，因此可以得出时间复杂度是线性阶。
 
-我们将线性阶的时间复杂度记为 $O(n)$ ，这个数学符号被称为「大 $O$ 记号 Big-$O$ Notation」，代表函数 $T(n)$ 的「渐近上界 asymptotic upper bound」。
+我们将线性阶的时间复杂度记为 $O(n)$ ，这个数学符号称为「大 $O$ 记号 Big-$O$ Notation」，表示函数 $T(n)$ 的「渐近上界 Asymptotic Upper Bound」。
 
-我们要推算时间复杂度，本质上是在计算「操作数量函数 $T(n)$ 」的渐近上界。下面我们先来看看函数渐近上界的数学定义。
+推算时间复杂度本质上是计算“操作数量函数 $T(n)$”的渐近上界。接下来，我们来看函数渐近上界的数学定义。
 
 !!! abstract "函数渐近上界"
 
@@ -534,22 +534,20 @@ $T(n)$ 是个一次函数，说明时间增长趋势是线性的，因此易得
 
 ![函数的渐近上界](time_complexity.assets/asymptotic_upper_bound.png)
 
-本质上看，计算渐近上界就是在找一个函数 $f(n)$ ，**使得在 $n$ 趋向于无穷大时，$T(n)$ 和 $f(n)$ 处于相同的增长级别（仅相差一个常数项 $c$ 的倍数）**。
-
-!!! tip
-
-    渐近上界的数学味儿有点重，如果你感觉没有完全理解，无需担心，因为在实际使用中我们只需要会推算即可，数学意义可以慢慢领悟。
+从本质上讲，计算渐近上界就是寻找一个函数 $f(n)$ ，使得当 $n$ 趋向于无穷大时，$T(n)$ 和 $f(n)$ 处于相同的增长级别，仅相差一个常数项 $c$ 的倍数。
 
 ## 推算方法
 
-推算出 $f(n)$ 后，我们就得到时间复杂度 $O(f(n))$ 。那么，如何来确定渐近上界 $f(n)$ 呢？总体分为两步，首先「统计操作数量」，然后「判断渐近上界」。
+渐近上界的数学味儿有点重，如果你感觉没有完全理解，也无需担心。因为在实际使用中，我们只需要掌握推算方法，数学意义可以逐渐领悟。
+
+根据定义，确定 $f(n)$ 之后，我们便可得到时间复杂度 $O(f(n))$ 。那么如何确定渐近上界 $f(n)$ 呢？总体分为两步：首先统计操作数量，然后判断渐近上界。
 
 ### 1) 统计操作数量
 
-对着代码，从上到下一行一行地计数即可。然而，**由于上述 $c \cdot f(n)$ 中的常数项 $c$ 可以取任意大小，因此操作数量 $T(n)$ 中的各种系数、常数项都可以被忽略**。根据此原则，可以总结出以下计数偷懒技巧：
+针对代码，逐行从上到下计算即可。然而，由于上述 $c \cdot f(n)$ 中的常数项 $c$ 可以取任意大小，**因此操作数量 $T(n)$ 中的各种系数、常数项都可以被忽略**。根据此原则，可以总结出以下计数简化技巧：
 
-1. **跳过数量与 $n$ 无关的操作**。因为他们都是 $T(n)$ 中的常数项，对时间复杂度不产生影响。
-2. **省略所有系数**。例如，循环 $2n$ 次、$5n + 1$ 次、……，都可以化简记为 $n$ 次，因为 $n$ 前面的系数对时间复杂度也不产生影响。
+1. **忽略与 $n$ 无关的操作**。因为它们都是 $T(n)$ 中的常数项，对时间复杂度不产生影响。
+2. **省略所有系数**。例如，循环 $2n$ 次、$5n + 1$ 次等，都可以简化记为 $n$ 次，因为 $n$ 前面的系数对时间复杂度没有影响。
 3. **循环嵌套时使用乘法**。总操作数量等于外层循环和内层循环操作数量之积，每一层循环依然可以分别套用上述 `1.` 和 `2.` 技巧。
 
 以下示例展示了使用上述技巧前、后的统计结果。
@@ -743,9 +741,9 @@ $$
 
 ### 2) 判断渐近上界
 
-**时间复杂度由多项式 $T(n)$ 中最高阶的项来决定**。这是因为在 $n$ 趋于无穷大时，最高阶的项将处于主导作用，其它项的影响都可以被忽略。
+**时间复杂度由多项式 $T(n)$ 中最高阶的项来决定**。这是因为在 $n$ 趋于无穷大时，最高阶的项将发挥主导作用，其它项的影响都可以被忽略。
 
-以下表格给出了一些例子，其中有一些夸张的值，是想要向大家强调 **系数无法撼动阶数** 这一结论。在 $n$ 趋于无穷大时，这些常数都是“浮云”。
+以下表格展示了一些例子，其中一些夸张的值是为了强调“系数无法撼动阶数”这一结论。当 $n$ 趋于无穷大时，这些常数变得无足轻重。
 
 <div class="center-table" markdown>
 
@@ -761,7 +759,7 @@ $$
 
 ## 常见类型
 
-设输入数据大小为 $n$ ，常见的时间复杂度类型有（从低到高排列）
+设输入数据大小为 $n$ ，常见的时间复杂度类型包括（按照从低到高的顺序排列）：
 
 $$
 \begin{aligned}
@@ -774,13 +772,13 @@ $$
 
 !!! tip
 
-    部分示例代码需要一些前置知识，包括数组、递归算法等。如果遇到看不懂的地方无需担心，可以在学习完后面章节后再来复习，现阶段先聚焦在理解时间复杂度含义和推算方法上。
+    部分示例代码需要一些预备知识，包括数组、递归算法等。如果遇到不理解的部分，请不要担心，可以在学习完后面章节后再回顾。现阶段，请先专注于理解时间复杂度的含义和推算方法。
 
 ### 常数阶 $O(1)$
 
 常数阶的操作数量与输入数据大小 $n$ 无关，即不随着 $n$ 的变化而变化。
 
-对于以下算法，无论操作数量 `size` 有多大，只要与数据大小 $n$ 无关，时间复杂度就仍为 $O(1)$ 。
+对于以下算法，尽管操作数量 `size` 可能很大，但由于其与数据大小 $n$ 无关，因此时间复杂度仍为 $O(1)$ 。
 
 === "Java"
 
@@ -844,7 +842,7 @@ $$
 
 ### 线性阶 $O(n)$
 
-线性阶的操作数量相对输入数据大小成线性级别增长。线性阶常出现于单层循环。
+线性阶的操作数量相对于输入数据大小以线性级别增长。线性阶通常出现在单层循环中。
 
 === "Java"
 
@@ -906,11 +904,11 @@ $$
     [class]{}-[func]{linear}
     ```
 
-「遍历数组」和「遍历链表」等操作，时间复杂度都为 $O(n)$ ，其中 $n$ 为数组或链表的长度。
+遍历数组和遍历链表等操作的时间复杂度均为 $O(n)$ ，其中 $n$ 为数组或链表的长度。
 
-!!! tip
+!!! question "如何确定输入数据大小 $n$ ？"
 
-    **数据大小 $n$ 是根据输入数据的类型来确定的**。比如，在上述示例中，我们直接将 $n$ 看作输入数据大小；以下遍历数组示例中，数据大小 $n$ 为数组的长度。
+    **数据大小 $n$ 需根据输入数据的类型来具体确定**。例如，在上述示例中，我们直接将 $n$ 视为输入数据大小；在下面遍历数组的示例中，数据大小 $n$ 为数组的长度。
 
 === "Java"
 
@@ -974,7 +972,7 @@ $$
 
 ### 平方阶 $O(n^2)$
 
-平方阶的操作数量相对输入数据大小成平方级别增长。平方阶常出现于嵌套循环，外层循环和内层循环都为 $O(n)$ ，总体为 $O(n^2)$ 。
+平方阶的操作数量相对于输入数据大小以平方级别增长。平方阶通常出现在嵌套循环中，外层循环和内层循环都为 $O(n)$ ，因此总体为 $O(n^2)$ 。
 
 === "Java"
 
@@ -1038,7 +1036,7 @@ $$
 
 ![常数阶、线性阶、平方阶的时间复杂度](time_complexity.assets/time_complexity_constant_linear_quadratic.png)
 
-以「冒泡排序」为例，外层循环 $n - 1$ 次，内层循环 $n-1, n-2, \cdots, 2, 1$ 次，平均为 $\frac{n}{2}$ 次，因此时间复杂度为 $O(n^2)$ 。
+以「冒泡排序」为例，外层循环执行 $n - 1$ 次，内层循环执行 $n-1, n-2, \cdots, 2, 1$ 次，平均为 $\frac{n}{2}$ 次，因此时间复杂度为 $O(n^2)$ 。
 
 $$
 O((n - 1) \frac{n}{2}) = O(n^2)
@@ -1108,9 +1106,9 @@ $$
 
 !!! note
 
-    生物学科中的“细胞分裂”即是指数阶增长：初始状态为 $1$ 个细胞，分裂一轮后为 $2$ 个，分裂两轮后为 $4$ 个，……，分裂 $n$ 轮后有 $2^n$ 个细胞。
+    生物学的“细胞分裂”是指数阶增长的典型例子：初始状态为 $1$ 个细胞，分裂一轮后变为 $2$ 个，分裂两轮后变为 $4$ 个，以此类推，分裂 $n$ 轮后有 $2^n$ 个细胞。
 
-指数阶增长得非常快，在实际应用中一般是不能被接受的。若一个问题使用「暴力枚举」求解的时间复杂度是 $O(2^n)$ ，那么一般都需要使用「动态规划」或「贪心算法」等算法来求解。
+指数阶增长非常迅速，在实际应用中通常是不可接受的。若一个问题使用「暴力枚举」求解的时间复杂度为 $O(2^n)$ ，那么通常需要使用「动态规划」或「贪心算法」等方法来解决。
 
 === "Java"
 
@@ -1174,7 +1172,7 @@ $$
 
 ![指数阶的时间复杂度](time_complexity.assets/time_complexity_exponential.png)
 
-在实际算法中，指数阶常出现于递归函数。例如以下代码，不断地一分为二，分裂 $n$ 次后停止。
+在实际算法中，指数阶常出现于递归函数。例如以下代码，不断地一分为二，经过 $n$ 次分裂后停止。
 
 === "Java"
 
@@ -1238,9 +1236,9 @@ $$
 
 ### 对数阶 $O(\log n)$
 
-对数阶与指数阶正好相反，后者反映“每轮增加到两倍的情况”，而前者反映“每轮缩减到一半的情况”。对数阶仅次于常数阶，时间增长得很慢，是理想的时间复杂度。
+与指数阶相反，对数阶反映了“每轮缩减到一半的情况”。对数阶仅次于常数阶，时间增长缓慢，是理想的时间复杂度。
 
-对数阶常出现于「二分查找」和「分治算法」中，体现“一分为多”、“化繁为简”的算法思想。
+对数阶常出现于「二分查找」和「分治算法」中，体现了“一分为多”和“化繁为简”的算法思想。
 
 设输入数据大小为 $n$ ，由于每轮缩减到一半，因此循环次数是 $\log_2 n$ ，即 $2^n$ 的反函数。
 
@@ -1372,7 +1370,7 @@ $$
 
 线性对数阶常出现于嵌套循环中，两层循环的时间复杂度分别为 $O(\log n)$ 和 $O(n)$ 。
 
-主流排序算法的时间复杂度都是 $O(n \log n )$ ，例如快速排序、归并排序、堆排序等。
+主流排序算法的时间复杂度通常为 $O(n \log n)$ ，例如快速排序、归并排序、堆排序等。
 
 === "Java"
 
@@ -1438,13 +1436,13 @@ $$
 
 ### 阶乘阶 $O(n!)$
 
-阶乘阶对应数学上的「全排列」。即给定 $n$ 个互不重复的元素，求其所有可能的排列方案，则方案数量为
+阶乘阶对应数学上的「全排列」问题。给定 $n$ 个互不重复的元素，求其所有可能的排列方案，方案数量为：
 
 $$
 n! = n \times (n - 1) \times (n - 2) \times \cdots \times 2 \times 1
 $$
 
-阶乘常使用递归实现。例如以下代码，第一层分裂出 $n$ 个，第二层分裂出 $n - 1$ 个，…… ，直至到第 $n$ 层时终止分裂。
+阶乘通常使用递归实现。例如以下代码，第一层分裂出 $n$ 个，第二层分裂出 $n - 1$ 个，以此类推，直至第 $n$ 层时终止分裂。
 
 === "Java"
 
@@ -1510,12 +1508,12 @@ $$
 
 ## 最差、最佳、平均时间复杂度
 
-**某些算法的时间复杂度不是恒定的，而是与输入数据的分布有关**。举一个例子，输入一个长度为 $n$ 数组 `nums` ，其中 `nums` 由从 $1$ 至 $n$ 的数字组成，但元素顺序是随机打乱的；算法的任务是返回元素 $1$ 的索引。我们可以得出以下结论：
+**某些算法的时间复杂度不是固定的，而是与输入数据的分布有关**。例如，假设输入一个长度为 $n$ 的数组 `nums` ，其中 `nums` 由从 $1$ 至 $n$ 的数字组成，但元素顺序是随机打乱的；算法的任务是返回元素 $1$ 的索引。我们可以得出以下结论：
 
-- 当 `nums = [?, ?, ..., 1]`，即当末尾元素是 $1$ 时，则需完整遍历数组，此时达到 **最差时间复杂度 $O(n)$** ；
-- 当 `nums = [1, ?, ?, ...]` ，即当首个数字为 $1$ 时，无论数组多长都不需要继续遍历，此时达到 **最佳时间复杂度 $\Omega(1)$** ；
+- 当 `nums = [?, ?, ..., 1]` ，即当末尾元素是 $1$ 时，需要完整遍历数组，此时达到 **最差时间复杂度 $O(n)$**；
+- 当 `nums = [1, ?, ?, ...]` ，即当首个数字为 $1$ 时，无论数组多长都不需要继续遍历，此时达到 **最佳时间复杂度 $\Omega(1)$**；
 
-「函数渐近上界」使用大 $O$ 记号表示，代表「最差时间复杂度」。与之对应，「函数渐近下界」用 $\Omega$ 记号（Omega Notation）来表示，代表「最佳时间复杂度」。
+“函数渐近上界”使用大 $O$ 记号表示，代表「最差时间复杂度」。相应地，“函数渐近下界”用 $\Omega$ 记号来表示，代表「最佳时间复杂度」。
 
 === "Java"
 
@@ -1618,14 +1616,14 @@ $$
 
 !!! tip
 
-    我们在实际应用中很少使用「最佳时间复杂度」，因为往往只有很小概率下才能达到，会带来一定的误导性。反之，「最差时间复杂度」最为实用，因为它给出了一个“效率安全值”，让我们可以放心地使用算法。
+    实际应用中我们很少使用「最佳时间复杂度」，因为通常只有在很小概率下才能达到，可能会带来一定的误导性。相反，「最差时间复杂度」更为实用，因为它给出了一个“效率安全值”，让我们可以放心地使用算法。
 
-从上述示例可以看出，最差或最佳时间复杂度只出现在“特殊分布的数据”中，这些情况的出现概率往往很小，因此并不能最真实地反映算法运行效率。**相对地，「平均时间复杂度」可以体现算法在随机输入数据下的运行效率，用 $\Theta$ 记号（Theta Notation）来表示**。
+从上述示例可以看出，最差或最佳时间复杂度只出现在“特殊分布的数据”中，这些情况的出现概率可能很小，因此并不能最真实地反映算法运行效率。相较之下，**「平均时间复杂度」可以体现算法在随机输入数据下的运行效率**，用 $\Theta$ 记号来表示。
 
 对于部分算法，我们可以简单地推算出随机数据分布下的平均情况。比如上述示例，由于输入数组是被打乱的，因此元素 $1$ 出现在任意索引的概率都是相等的，那么算法的平均循环次数则是数组长度的一半 $\frac{n}{2}$ ，平均时间复杂度为 $\Theta(\frac{n}{2}) = \Theta(n)$ 。
 
-但在实际应用中，尤其是较为复杂的算法，计算平均时间复杂度比较困难，因为很难简便地分析出在数据分布下的整体数学期望。这种情况下，我们一般使用最差时间复杂度来作为算法效率的评判标准。
+但在实际应用中，尤其是较为复杂的算法，计算平均时间复杂度比较困难，因为很难简便地分析出在数据分布下的整体数学期望。在这种情况下，我们通常使用最差时间复杂度作为算法效率的评判标准。
 
 !!! question "为什么很少看到 $\Theta$ 符号？"
 
-    实际中我们经常使用「大 $O$ 符号」来表示「平均复杂度」，这样严格意义上来说是不规范的。这可能是因为 $O$ 符号实在是太朗朗上口了。</br>如果在本书和其他资料中看到类似 **平均时间复杂度 $O(n)$** 的表述，请你直接理解为 $\Theta(n)$ 即可。
+    可能由于 $O$ 符号过于朗朗上口，我们常常使用它来表示「平均复杂度」，但从严格意义上看，这种做法并不规范。在本书和其他资料中，若遇到类似“平均时间复杂度 $O(n)$”的表述，请将其直接理解为 $\Theta(n)$ 。
diff --git a/docs/chapter_heap/build_heap.md b/docs/chapter_heap/build_heap.md
index 766bf0f60..8f64e189d 100644
--- a/docs/chapter_heap/build_heap.md
+++ b/docs/chapter_heap/build_heap.md
@@ -118,4 +118,4 @@ T(h) & = 2 \frac{1 - 2^h}{1 - 2} - h \newline
 \end{aligned}
 $$
 
-进一步地，高度为 $h$ 的完美二叉树的结点数量为 $n = 2^{h+1} - 1$ ，易得复杂度为 $O(2^h) = O(n)$。以上推算表明，**输入列表并建堆的时间复杂度为 $O(n)$ ，非常高效**。
+进一步地，高度为 $h$ 的完美二叉树的结点数量为 $n = 2^{h+1} - 1$ ，易得复杂度为 $O(2^h) = O(n)$ 。以上推算表明，**输入列表并建堆的时间复杂度为 $O(n)$ ，非常高效**。
diff --git a/docs/chapter_sorting/counting_sort.md b/docs/chapter_sorting/counting_sort.md
index f68ae8cb6..887225370 100644
--- a/docs/chapter_sorting/counting_sort.md
+++ b/docs/chapter_sorting/counting_sort.md
@@ -189,7 +189,7 @@ $$
 
 ## 局限性
 
-看到这里，你也许会觉得计数排序太妙了，咔咔一通操作，时间复杂度就下来了。然而，使用技术排序的前置条件比较苛刻。
+看到这里，你也许会觉得计数排序太妙了，咔咔一通操作，时间复杂度就下来了。然而，使用计数排序的前置条件比较苛刻。
 
 **计数排序只适用于非负整数**。若想要用在其他类型数据上，则要求该数据必须可以被转化为非负整数，并且不能改变各个元素之间的相对大小关系。例如，对于包含负数的整数数组，可以先给所有数字加上一个常数，将全部数字转化为正数，排序完成后再转换回去即可。