diff --git a/docs/chapter_hashing/hash_collision.assets/hash_collision_chaining.png b/docs/chapter_hashing/hash_collision.assets/hash_collision_chaining.png
deleted file mode 100644
index 6653bfa12..000000000
Binary files a/docs/chapter_hashing/hash_collision.assets/hash_collision_chaining.png and /dev/null differ
diff --git a/docs/chapter_hashing/hash_collision.assets/hash_collision_linear_probing.png b/docs/chapter_hashing/hash_collision.assets/hash_collision_linear_probing.png
deleted file mode 100644
index 31263aabe..000000000
Binary files a/docs/chapter_hashing/hash_collision.assets/hash_collision_linear_probing.png and /dev/null differ
diff --git a/docs/chapter_hashing/hash_collision.assets/hash_table_chaining.png b/docs/chapter_hashing/hash_collision.assets/hash_table_chaining.png
new file mode 100644
index 000000000..4b0cdf46e
Binary files /dev/null and b/docs/chapter_hashing/hash_collision.assets/hash_table_chaining.png differ
diff --git a/docs/chapter_hashing/hash_collision.assets/hash_table_linear_probing.png b/docs/chapter_hashing/hash_collision.assets/hash_table_linear_probing.png
new file mode 100644
index 000000000..80f78dec1
Binary files /dev/null and b/docs/chapter_hashing/hash_collision.assets/hash_table_linear_probing.png differ
diff --git a/docs/chapter_hashing/hash_collision.md b/docs/chapter_hashing/hash_collision.md
index 6963b113e..bd2fdf559 100644
--- a/docs/chapter_hashing/hash_collision.md
+++ b/docs/chapter_hashing/hash_collision.md
@@ -2,16 +2,14 @@
 
 在理想情况下，哈希函数为每个输入生成唯一的输出，实现 key 和数组索引的一一对应。但实际上，**哈希函数的输入空间通常远大于输出空间**，因此多个输入产生相同输出的情况是不可避免的。例如，输入空间为全体整数，输出空间为数组容量大小，则必然有多个整数映射至同一数组索引。
 
-这种多个输入对应同一输出索引的现象被称为「哈希冲突 Hash Collision」。哈希冲突会导致查询结果错误，严重影响哈希表的可用性。哈希冲突的解决方法主要有两种：
+这种多个输入对应同一输出索引的现象被称为「哈希冲突 Hash Collision」。哈希冲突会导致查询结果错误，严重影响哈希表的可用性。哈希冲突的处理方法主要有两种：
 
 - **扩大哈希表容量**：哈希表容量越大，键值对聚集的概率就越低。极端情况下，当输入空间和输出空间大小相等时，哈希表等同于数组，每个 key 都对应唯一的数组索引。
-- **优化哈希表结构**：常用方法包括链式地址和开放寻址。
+- **优化哈希表结构**：常用方法包括链式地址和开放寻址。这类方法的思路是通过改良数据结构，使得哈希表可以在发生哈希冲突时仍然可以正常工作。当然，这些优化往往是以牺牲时间效率为代价的。
 
 ## 哈希表扩容
 
-哈希函数的最后一步通常是对桶数量 $n$ 取余，作用是将哈希值映射到桶索引范围，从而将 key 放入对应的桶中。当哈希表容量越大（即 $n$ 越大）时，多个 key 被分配到同一个桶中的概率就越低，冲突就越少。
-
-因此，**当哈希表内的冲突总体较为严重时，编程语言通常通过扩容哈希表来缓解冲突**。类似于数组扩容，哈希表扩容需将所有键值对从原哈希表迁移至新哈希表，开销较大。
+哈希函数的最后一步通常是对桶数量 $n$ 取余，作用是将哈希值映射到桶索引范围，从而将 key 放入对应的桶中。当哈希表容量越大（即 $n$ 越大）时，多个 key 被分配到同一个桶中的概率就越低，冲突就越少。因此，**当哈希表内的冲突总体较为严重时，编程语言通常通过扩容哈希表来缓解冲突**。类似于数组扩容，哈希表扩容需将所有键值对从原哈希表迁移至新哈希表，开销较大。
 
 编程语言通常使用「负载因子 Load Factor」来衡量哈希冲突的严重程度，**定义为哈希表中元素数量除以桶数量**，常作为哈希表扩容的触发条件。在 Java 中，当负载因子超过 $0.75$ 时，系统会将 HashMap 容量扩展为原先的 $2$ 倍。
 
@@ -19,7 +17,7 @@
 
 在原始哈希表中，每个桶仅能存储一个键值对。「链式地址 Separate Chaining」将单个元素转换为链表，将键值对作为链表节点，将所有发生冲突的键值对都存储在同一链表中。
 
-![链式地址哈希表](hash_collision.assets/hash_collision_chaining.png)
+![链式地址哈希表](hash_collision.assets/hash_table_chaining.png)
 
 链式地址下，哈希表的操作方法包括：
 
@@ -27,7 +25,7 @@
 - **添加元素**：先通过哈希函数访问链表头节点，然后将节点（即键值对）添加到链表中。
 - **删除元素**：根据哈希函数的结果访问链表头部，接着遍历链表以查找目标节点，并将其删除。
 
-尽管链式地址法解决了哈希冲突问题，但仍存在一些局限性，包括：
+该方法存在一些局限性，包括：
 
 - **占用空间增大**，由于链表或二叉树包含节点指针，相比数组更加耗费内存空间；
 - **查询效率降低**，因为需要线性遍历链表来查找对应元素；
@@ -131,16 +129,16 @@
 
 ## 开放寻址
 
-「开放寻址 Open Addressing」不引入额外的数据结构，而是通过“多次探测”来解决哈希冲突，探测方式主要包括线性探测、平方探测、多次哈希。
+「开放寻址 Open Addressing」不引入额外的数据结构，而是通过“多次探测”来处理哈希冲突，探测方式主要包括线性探测、平方探测、多次哈希。
 
 ### 线性探测
 
-线性探测采用固定步长的线性查找来解决哈希冲突。
+线性探测采用固定步长的线性查找来进行探测，对应的哈希表操作方法为：
 
 - **插入元素**：通过哈希函数计算数组索引，若发现桶内已有元素，则从冲突位置向后线性遍历（步长通常为 $1$ ），直至找到空位，将元素插入其中。
 - **查找元素**：若发现哈希冲突，则使用相同步长向后线性遍历，直到找到对应元素，返回 value 即可；或者若遇到空位，说明目标键值对不在哈希表中，返回 $\text{None}$ 。
 
-![线性探测](hash_collision.assets/hash_collision_linear_probing.png)
+![线性探测](hash_collision.assets/hash_table_linear_probing.png)
 
 然而，线性探测存在以下缺陷：
 
diff --git a/docs/chapter_hashing/hash_map.assets/hash_collision.png b/docs/chapter_hashing/hash_map.assets/hash_collision.png
index 2d5d91e1d..ac2aa60c9 100644
Binary files a/docs/chapter_hashing/hash_map.assets/hash_collision.png and b/docs/chapter_hashing/hash_map.assets/hash_collision.png differ
diff --git a/docs/chapter_hashing/hash_map.assets/hash_function.png b/docs/chapter_hashing/hash_map.assets/hash_function.png
index 18e0f0110..dbe54a25d 100644
Binary files a/docs/chapter_hashing/hash_map.assets/hash_function.png and b/docs/chapter_hashing/hash_map.assets/hash_function.png differ
diff --git a/docs/chapter_hashing/hash_map.assets/hash_map.png b/docs/chapter_hashing/hash_map.assets/hash_map.png
deleted file mode 100644
index 124dacd3a..000000000
Binary files a/docs/chapter_hashing/hash_map.assets/hash_map.png and /dev/null differ
diff --git a/docs/chapter_hashing/hash_map.assets/hash_table_lookup.png b/docs/chapter_hashing/hash_map.assets/hash_table_lookup.png
new file mode 100644
index 000000000..c234da571
Binary files /dev/null and b/docs/chapter_hashing/hash_map.assets/hash_table_lookup.png differ
diff --git a/docs/chapter_hashing/hash_map.md b/docs/chapter_hashing/hash_map.md
index d2dc3e3c4..670cb6999 100755
--- a/docs/chapter_hashing/hash_map.md
+++ b/docs/chapter_hashing/hash_map.md
@@ -1,10 +1,10 @@
 # 哈希表
 
-哈希表通过建立「键 key」与「值 value」之间的映射，实现高效的元素查询。具体而言，我们向哈希表输入一个 key，则可以在 $O(1)$ 时间内获取对应的 value 。
+「哈希表 Hash Table」通过建立键 `key` 与值 `value` 之间的映射，实现高效的元素查询。具体而言，我们向哈希表输入一个 `key` ，则可以在 $O(1)$ 时间内获取对应的 `value` 。
 
 以一个包含 $n$ 个学生的数据库为例，每个学生都有“姓名 `name`”和“学号 `id`”两项数据。假如我们希望实现查询功能，例如“输入一个学号，返回对应的姓名”，则可以采用哈希表来实现。
 
-![哈希表的抽象表示](hash_map.assets/hash_map.png)
+![哈希表的抽象表示](hash_map.assets/hash_table_lookup.png)
 
 除哈希表外，我们还可以使用数组或链表实现元素查询，其中：
 
@@ -12,8 +12,6 @@
 - 添加元素仅需添加至尾部即可，使用 $O(1)$ 时间；
 - 删除元素需要先查询再删除，使用 $O(n)$ 时间；
 
-然而，在哈希表中进行增删查的时间复杂度都是 $O(1)$ 。哈希表全面胜出！因此，哈希表常用于对查找效率要求较高的场景。
-
 <div class="center-table" markdown>
 
 |          | 数组   | 链表   | 哈希表 |
@@ -24,6 +22,8 @@
 
 </div>
 
+观察发现，在哈希表中进行增删查改的时间复杂度都是 $O(1)$ ，非常高效。因此，哈希表常用于对查找效率要求较高的场景。
+
 ## 哈希表常用操作
 
 哈希表的基本操作包括 **初始化、查询操作、添加与删除键值对**。
@@ -428,29 +428,26 @@
     });
     ```
 
-## 哈希函数
-
-哈希表的底层实现为数组，同时可能包含链表、二叉树（红黑树）等数据结构，以提高查询性能（将在下节讨论）。
-
-首先考虑最简单的情况，**仅使用一个数组来实现哈希表**。通常，我们将数组中的每个空位称为「桶 Bucket」，用于存储键值对。
-
-我们将键值对 key, value 封装成一个类 `Pair` ，并将所有 `Pair` 放入数组中。这样，数组中的每个 `Pair` 都具有唯一的索引。为了建立 key 和索引之间的映射关系，我们需要使用「哈希函数 Hash Function」。
+## 哈希表简单实现
 
-设哈希表的数组为 `buckets` ，哈希函数为 `f(x)` ，那么查询操作的步骤如下：
+我们先考虑最简单的情况，**仅用一个数组来实现哈希表**。在哈希表中，我们通常将数组中的每个空位称为「桶 Bucket」，每个桶可存储一个键值对。因此，查询操作就是定位输入的 `key` 对应的桶，从而得到 `value` 。
 
-1. 输入 `key` ，通过哈希函数计算出索引 `index` ，即 `index = f(key)` ；
-2. 通过索引在数组中访问到键值对 `pair` ，即 `pair = buckets[index]` ，然后从 `pair` 中获取对应的 `value` ；
+那么，如何基于 `key` 来定位对应的桶呢？这是通过「哈希函数 Hash Function」实现的。哈希函数的作用是将一个较大的输入空间映射到一个较小的输出空间。在哈希表中，输入空间是所有 `key` ，输出空间是所有桶（数组索引）。换句话说，**输入一个 `key` ，我们可以通过哈希函数得到该 `key` 对应的键值对存储在数组中的位置**。
 
-以学生数据 `key 学号 -> value 姓名` 为例，我们可以设计如下哈希函数：
+哈希函数的计算过程分为两步：输入一个 `key` ，首先通过函数 `hash(key)` 计算得到哈希值，接下来将哈希值对桶数量（数组长度）取模，从而获取该 `key` 对应的数组索引 `index` 。计算公式如下
 
 $$
-f(x) = x \bmod {100}
+index = \text{hash}(key) \bmod {c}
 $$
 
-其中 $\bmod$ 表示取余运算。
+其中， $\bmod$ 表示取余运算， $c$ 为桶数量（数组长度）。随后，我们就可以利用 `index` 在哈希表中访问对应的桶，从而获取 `value` 。
+
+设数组长度 $c = 100$ , $\text{hash}(key) = key$ ，易得哈希函数为 $key \bmod 100$ 。下图以 `key` 学号和 `value` 姓名为例，展示了哈希函数的工作原理。
 
 ![哈希函数工作原理](hash_map.assets/hash_function.png)
 
+以下代码给出了一个简单哈希表实现。其中，我们将 `key` 和 `value` 封装成一个类 `Pair` ，以表示键值对。
+
 === "Java"
 
     ```java title="array_hash_map.java"
@@ -541,18 +538,14 @@ $$
 
 ## 哈希冲突
 
-细心的你可能已经注意到，**在某些情况下，哈希函数 $f(x) = x \bmod 100$ 可能无法正常工作**。具体来说，当输入的 key 后两位相同时，哈希函数的计算结果也会相同，从而指向同一个 value 。例如，查询学号为 $12836$ 和 $20336$ 的两个学生时，我们得到：
+本质上看，哈希函数的是将一个庞大的输入空间（`key` 范围）映射到一个较小的输出空间（数组索引范围）。因此，**理论上一定存在”多个输入对应相同输出”的情况**。
+
+对于上述示例中的哈希函数，当输入的 `key` 后两位相同时，哈希函数的输出结果也相同。例如，查询学号为 $12836$ 和 $20336$ 的两个学生时，我们得到：
 
 $$
-f(12836) = f(20336) = 36
+12836 \bmod 100 = 20336 \bmod 100 = 36
 $$
 
-这两个学号指向了同一个姓名，这显然是错误的。我们把这种情况称为「哈希冲突 Hash Collision」。在后续章节中，我们将讨论如何解决哈希冲突的问题。
+两个学号指向了同一个姓名，这显然是不对的。我们把这种情况称为“哈希冲突”。在下节中，我们将重点讨论如何解决冲突问题。
 
 ![哈希冲突示例](hash_map.assets/hash_collision.png)
-
-综上所述，一个优秀的哈希函数应具备以下特性：
-
-- 尽可能减少哈希冲突的发生；
-- 查询效率高且稳定，能够在绝大多数情况下达到 $O(1)$ 时间复杂度；
-- 较高的空间利用率，即使“键值对占用空间 / 哈希表总占用空间”比例最大化；