diff --git a/docs/chapter_hashing/summary.md b/docs/chapter_hashing/summary.md
index 435d33e7a..34cff34b8 100644
--- a/docs/chapter_hashing/summary.md
+++ b/docs/chapter_hashing/summary.md
@@ -13,3 +13,33 @@
 - 哈希算法通常采用大质数作为模数，以最大化地保证哈希值的均匀分布，减少哈希冲突。
 - 常见的哈希算法包括 MD5, SHA-1, SHA-2, SHA3 等。MD5 常用语校验文件完整性，SHA-2 常用于安全应用与协议。
 - 编程语言通常会为数据类型提供内置哈希算法，用于计算哈希表中的桶索引。通常情况下，只有不可变对象是可哈希的。
+
+## Q & A
+
+!!! question "哈希表的时间复杂度为什么不是 $O(n)$ ？"
+
+   当哈希冲突比较严重时，哈希表的时间复杂度会退化至 $O(n)$ 。当哈希函数设计的比较好、容量设置比较合理、冲突比较平均时，时间复杂度是 $O(1)$ 。我们使用编程语言内置的哈希表时，通常认为时间复杂度是 $O(1)$ 。
+
+!!! question "为什么不使用哈希函数 $f(x) = x$ 呢？这样就不会有冲突了"
+
+    在 $f(x) = x$ 哈希函数下，每个元素对应唯一的桶索引，这与数组等价。然而，输入空间通常远大于输出空间（数组长度），因此哈希函数的最后一步往往是对数组长度取模。换句话说，哈希表的目标是将一个较大的状态空间映射到一个较小的空间，并提供 $O(1)$ 的查询效率。
+
+!!! question "哈希表底层实现是数组、链表、二叉树，但为什么效率可以比他们更高呢？"
+    
+    首先，哈希表的时间效率变高，但空间效率变低了。哈希表有相当一部分的内存是未使用的，
+    
+    其次，只是在特定使用场景下时间效率变高了。如果一个功能能够在相同的时间复杂度下使用数组或链表实现，那么通常比哈希表更快。这是因为哈希函数计算需要开销，时间复杂度的常数项更大。
+    
+    最后，哈希表的时间复杂度可能发生劣化。例如在链式地址中，我们采取在链表或红黑树中执行查找操作，仍然有退化至 $O(n)$ 时间的风险。
+
+!!! question "多次哈希有不能直接删除元素的缺陷吗？对于标记已删除的空间，这个空间还能再次使用吗？"
+    
+    多次哈希是开放寻址的一种，开放寻址法都有不能直接删除元素的缺陷，需要通过标记删除。被标记为已删除的空间是可以再次被使用的。当将新元素插入哈希表，并且通过哈希函数找到了被标记为已删除的位置时，该位置可以被新的元素使用。这样做既能保持哈希表的探测序列不变，又能保证哈希表的空间使用率。
+
+!!! question "为什么在线性探测中，查找元素的时候会出现哈希冲突呢？"
+
+    查找的时候通过哈希函数找到对应的桶和键值对，发现 `key` 不匹配，这就代表有哈希冲突。因此，线性探测法会根据预先设定的步长依次向下查找，直至找到正确的键值对或无法找到跳出为止。
+
+!!! question "为什么哈希表扩容能够缓解哈希冲突？"
+
+    哈希函数的最后一步往往是对数组长度 $n$ 取余，让输出值落入在数组索引范围；在扩容后，数组长度 $n$ 发生变化，而 `key` 对应的索引也可能发生变化。原先落在同一个桶的多个 `key` ，在扩容后可能会被分配到多个桶中，从而实现哈希冲突的缓解。
diff --git a/docs/chapter_heap/summary.md b/docs/chapter_heap/summary.md
index b291db603..4a6f46f18 100644
--- a/docs/chapter_heap/summary.md
+++ b/docs/chapter_heap/summary.md
@@ -6,3 +6,9 @@
 - 完全二叉树非常适合用数组表示，因此我们通常使用数组来存储堆。
 - 堆化操作用于维护堆的性质，在入堆和出堆操作中都会用到。
 - 输入 $n$ 个元素并建堆的时间复杂度可以优化至 $O(n)$ ，非常高效。
+
+## Q & A
+
+!!! question "数据结构的“堆”与内存管理的“堆”是同一个概念吗？"
+    
+    两者不是同一个概念，只是碰巧都叫堆。计算机系统内存中的堆是动态内存分配的一部分，程序在运行时可以使用它来存储数据。程序可以请求一定量的堆内存，用于存储如对象和数组等复杂结构。当这些数据不再需要时，程序需要释放这些内存，以防止内存泄露。相较于栈内存，堆内存的管理和使用需要更谨慎，不恰当的使用可能会导致内存泄露和野指针等问题。
diff --git a/docs/chapter_sorting/summary.md b/docs/chapter_sorting/summary.md
index bd7732522..e91ef431a 100644
--- a/docs/chapter_sorting/summary.md
+++ b/docs/chapter_sorting/summary.md
@@ -14,6 +14,14 @@
 
 ## Q & A
 
+!!! question "排序算法稳定性在什么情况下是必须的？"
+
+    在现实中，我们有可能是在对象的某个属性上进行排序。例如，学生有姓名和身高两个属性，我们希望实现一个多级排序/
+
+    先按照姓名进行排序，得到 `(A, 180) (B, 185) (C, 170) (D, 170)` ；接下来对身高进行排序。由于排序算法不稳定，我们可能得到 `(D, 170) (C, 170) (A, 180) (B, 185)` 。
+
+    可以发现，学生 D 和 C 的位置发生了交换，姓名的有序性被破坏了，而这是我们不希望看到的。
+
 !!! question "哨兵划分中“从右往左查找”与“从左往右查找”的顺序可以交换吗？"
 
     不行，当我们以最左端元素为基准数时，必须先“从右往左查找”再“从左往右查找”。这个结论有些反直觉，我们来剖析一下原因。
@@ -23,3 +31,13 @@
     举个例子，给定数组 `[0, 0, 0, 0, 1]` ，如果先“从左向右查找”，哨兵划分后数组为 `[1, 0, 0, 0, 0]` ，这个结果是不正确的。
 
     再深入思考一下，如果我们选择 `nums[right]` 为基准数，那么正好反过来，必须先“从左往右查找”。
+
+!!! question "关于尾递归优化，为什么选短的数组能保证递归深度不超过 $log n$ ？"
+
+    递归深度就是当前未返回的递归方法的数量。每轮哨兵划分我们将原数组划分为两个子数组。在尾递归优化后，向下递归的子数组长度最大为原数组的一半长度。假设最差情况，一直为一半长度，那么最终的递归深度就是 $log n$ 。
+    
+    回顾原始的快速排序，我们有可能会连续地递归长度较大的数组，最差情况下为 $n, n - 1, n - 2, ..., 2, 1$ ，从而递归深度为 $n$ 。尾递归优化可以避免这种情况的出现。
+
+!!! question "桶排序的最差时间复杂度为什么是 $O(n^2)$ ？"
+
+    最差情况下，所有元素被分至同一个桶中。如果我们采用一个 $O(n^2)$ 算法来排序这些元素，则时间复杂度为 $O(n^2)$ 。
diff --git a/docs/chapter_tree/summary.md b/docs/chapter_tree/summary.md
index af7dd4460..344ad456f 100644
--- a/docs/chapter_tree/summary.md
+++ b/docs/chapter_tree/summary.md
@@ -11,3 +11,25 @@
 - 二叉搜索树是一种高效的元素查找数据结构，其查找、插入和删除操作的时间复杂度均为 $O(\log n)$ 。当二叉搜索树退化为链表时，各项时间复杂度会劣化至 $O(n)$ 。
 - AVL 树，也称为平衡二叉搜索树，它通过旋转操作，确保在不断插入和删除节点后，树仍然保持平衡。
 - AVL 树的旋转操作包括右旋、左旋、先右旋再左旋、先左旋再右旋。在插入或删除节点后，AVL 树会从底向顶执行旋转操作，使树重新恢复平衡。
+
+## Q & A
+
+!!! question "对于只有一个节点的二叉树，树的高度和根节点的深度都是 $0$ 吗？"
+
+    是的，因为高度和深度通常定义为“走过边的数量”。
+
+!!! question "二叉树中的插入与删除一般都是由一套操作配合完成的，这里的“一套操作”指什么呢？可以理解为资源的子节点的资源释放吗？"
+    
+    拿二叉搜索树来举例，删除节点操作要分为三种情况处理，其中每种情况都需要进行多个步骤的节点操作。
+
+!!! question "为什么 DFS 遍历二叉树有前、中、后三种顺序，分别有什么用呢？"
+
+    DFS 的前、中、后序遍历和访问数组的顺序类似，是遍历二叉树的基本方法，利用这三种遍历方法，我们可以得到一个特定顺序的遍历结果。例如在二叉搜索树中，由于结点大小满足 `左子结点值 < 根结点值 < 右子结点值` ，因此我们只要按照 `左->根->右` 的优先级遍历树，就可以获得有序的节点序列。
+
+!!! question "右旋操作是处理失衡节点 `node` , `child` , `grand_child` 之间的关系，那 `node` 的父节点和 `node` 原来的连接不需要维护吗？右旋操作后岂不是断掉了？"
+
+    我们需要从递归的视角来看这个问题。右旋操作 `right_rotate(root)` 传入的是子树的根节点，最终 `return child` 返回旋转之后的子树的根节点。子树的根节点和其父节点的连接是在该函数返回后完成的，不属于右旋操作的维护范围。
+
+!!! question "在 C++ 中，函数被划分到 `private` 和 `public` 中，这方面有什么考量吗？为什么要将 `height()` 函数和 `updateHeight()` 函数分别放在 `public` 和 `private` 中呢？"
+
+    主要看方法的使用范围，如果方法只在类内部使用，那么就设计为 `private` 。例如，用户单独调用 `updateHeight()` 是没有意义的，它只是插入、删除操作中的一步。而 `height()` 是访问结点高度，类似于 `vector.size()` ，因此设置成 `public` 以便使用。