diff --git a/docs/chapter_computational_complexity/summary.md b/docs/chapter_computational_complexity/summary.md
index 4beb14adf6..22e3395bb4 100644
--- a/docs/chapter_computational_complexity/summary.md
+++ b/docs/chapter_computational_complexity/summary.md
@@ -47,3 +47,9 @@
 假设取 $n = 8$ ，你可能会发现每条曲线的值与函数对应不上。这是因为每条曲线都包含一个常数项，用于将取值范围压缩到一个视觉舒适的范围内。
 
 在实际中，因为我们通常不知道每个方法的“常数项”复杂度是多少，所以一般无法仅凭复杂度来选择 $n = 8$ 之下的最优解法。但对于 $n = 8^5$ 就很好选了，这时增长趋势已经占主导了。
+
+**Q** 是否存在根据实际使用场景，选择牺牲时间（或空间）来设计算法的情况？
+
+在实际应用中，大部分情况会选择牺牲空间换时间。例如数据库索引，我们通常选择建立 B+ 树或哈希索引，占用大量内存空间，以换取 $O(\log n)$ 甚至 $O(1)$ 的高效查询。
+
+在空间资源宝贵的场景，也会选择牺牲时间换空间。例如在嵌入式开发中，设备内存很宝贵，工程师可能会放弃使用哈希表，选择使用数组顺序查找，以节省内存占用，代价是查找变慢。
diff --git a/docs/chapter_hashing/summary.md b/docs/chapter_hashing/summary.md
index 2e8d6ca7f7..0fa9e38455 100644
--- a/docs/chapter_hashing/summary.md
+++ b/docs/chapter_hashing/summary.md
@@ -45,3 +45,7 @@
 **Q**：为什么哈希表扩容能够缓解哈希冲突？
 
 哈希函数的最后一步往往是对数组长度 $n$ 取模（取余），让输出值落在数组索引范围内；在扩容后，数组长度 $n$ 发生变化，而 `key` 对应的索引也可能发生变化。原先落在同一个桶的多个 `key` ，在扩容后可能会被分配到多个桶中，从而实现哈希冲突的缓解。
+
+**Q**：如果为了高效的存取，那么直接使用数组不就好了吗？
+
+当数据的 `key` 是连续的小范围整数时，直接用数组即可，简单高效。但当 `key` 是其他类型（例如字符串）时，就需要借助哈希函数将 `key` 映射为数组索引，再通过桶数组存储元素，这样的结构就是哈希表。