Fix a typo.

docs/chapter_searching/replace_linear_by_hashing.md

@@ -79,7 +79,7 @@
 考虑借助一个哈希表，键值对分别为数组元素和元素索引。循环遍历数组，每轮执行：
 
 1. 判断数字 `target - nums[i]` 是否在哈希表中，若是则直接返回这两个元素的索引；
-2. 将键值对 `num[i]` 和索引 `i` 添加进哈希表；
+2. 将键值对 `nums[i]` 和索引 `i` 添加进哈希表；
 
 === "<1>"
     ![辅助哈希表求解两数之和](replace_linear_by_hashing.assets/two_sum_hashtable_step1.png)

docs/chapter_sorting/quick_sort.md

@@ -354,13 +354,3 @@
     ```zig title="quick_sort.zig"
     [class]{QuickSortTailCall}-[func]{quickSort}
     ```
-
-!!! question "哨兵划分中“从右往左查找”与“从左往右查找”的顺序可以交换吗？"
-
-    不行，当我们以最左端元素为基准数时，必须先“从右往左查找”再“从左往右查找”。这个结论有些反直觉，我们来剖析一下原因。
-
-    哨兵划分 `partition()` 的最后一步是交换 `nums[left]` 和 `nums[i]` 。完成交换后，基准数左边的元素都 `<=` 基准数，**这就要求最后一步交换前 `nums[left] >= nums[i]` 必须成立**。假设我们先“从左往右查找”，那么如果找不到比基准数更小的元素，**则会在 `i == j` 时跳出循环，此时可能 `nums[j] == nums[i] > nums[left]`**。也就是说，此时最后一步交换操作会把一个比基准数更大的元素交换至数组最左端，导致哨兵划分失败。
-
-    举个例子，给定数组 `[0, 0, 0, 0, 1]` ，如果先“从左向右查找”，哨兵划分后数组为 `[1, 0, 0, 0, 0]` ，这个结果是不正确的。
-
-    再深入思考一下，如果我们选择 `nums[right]` 为基准数，那么正好反过来，必须先“从左往右查找”。

docs/chapter_sorting/summary.md

@@ -10,5 +10,16 @@
 
 ![排序算法对比](summary.assets/sorting_algorithms_comparison.png)
 
-- 总体来看，我们追求运行快、稳定、原地、正向自适应性的排序。显然，如同其他数据结构与算法一样，同时满足这些条件的排序算法并不存在，我们需要根据问题特点来选择排序算法。
 - 总的来说，我们希望找到一种排序算法，具有高效率、稳定、原地以及正向自适应性等优点。然而，正如其他数据结构和算法一样，没有一种排序算法能够同时满足所有这些条件。在实际应用中，我们需要根据数据的特性来选择合适的排序算法。
+
+## Q & A
+
+!!! question "哨兵划分中“从右往左查找”与“从左往右查找”的顺序可以交换吗？"
+
+    不行，当我们以最左端元素为基准数时，必须先“从右往左查找”再“从左往右查找”。这个结论有些反直觉，我们来剖析一下原因。
+
+    哨兵划分 `partition()` 的最后一步是交换 `nums[left]` 和 `nums[i]` 。完成交换后，基准数左边的元素都 `<=` 基准数，**这就要求最后一步交换前 `nums[left] >= nums[i]` 必须成立**。假设我们先“从左往右查找”，那么如果找不到比基准数更小的元素，**则会在 `i == j` 时跳出循环，此时可能 `nums[j] == nums[i] > nums[left]`**。也就是说，此时最后一步交换操作会把一个比基准数更大的元素交换至数组最左端，导致哨兵划分失败。
+
+    举个例子，给定数组 `[0, 0, 0, 0, 1]` ，如果先“从左向右查找”，哨兵划分后数组为 `[1, 0, 0, 0, 0]` ，这个结果是不正确的。
+
+    再深入思考一下，如果我们选择 `nums[right]` 为基准数，那么正好反过来，必须先“从左往右查找”。