fix: fix errors and typos

zh-cn/overviews/collections/concrete-immutable-collection-classes.md

@@ -42,7 +42,8 @@ List通常被认为是Scala中最重要的数据结构，所以我们在此不
     fibs: scala.collection.immutable.Stream[Int] = Stream(1, ?)
     scala> fibs.toList
     res9: List[Int] = List(1, 1, 2, 3, 5, 8, 13)
-    Vector（向量）
+
+## Vector（向量）
 
 对于只需要处理数据结构头结点的算法来说，List非常高效。可是相对于访问、添加和删除List头结点只需要固定时间，访问和修改头结点之后元素所需要的时间则是与List深度线性相关的。
 
@@ -76,7 +77,8 @@ Vector结构通常被表示成具有高分支因子的树（树或者图的分
 
     scala> collection.immutable.IndexedSeq(1, 2, 3)
     res2: scala.collection.immutable.IndexedSeq[Int] = Vector(1, 2, 3)
-    Immutable stacks（不可变栈）
+
+## Immutable stacks（不可变栈）
 
 如果您想要实现一个后入先出的序列，那您可以使用[Stack](http://www.scala-lang.org/api/2.10.0/scala/collection/immutable/Stack.html)。您可以使用push向栈中压入一个元素，用pop从栈中弹出一个元素，用top查看栈顶元素而不用删除它。所有的这些操作都仅仅耗费固定的运行时间。
 
@@ -176,7 +178,8 @@ BitSet操作的运行时间是非常快的。查找测试仅仅需要固定时
     res26: Boolean = true
     scala> moreBits(0)
     res27: Boolean = false
-    List Maps
+
+## List Maps
 
 [ListMap](http://www.scala-lang.org/api/2.10.0/scala/collection/immutable/ListMap.html)被用来表示一个保存键-值映射的链表。一般情况下，ListMap操作都需要遍历整个列表，所以操作的运行时间也同列表长度成线性关系。实际上ListMap在Scala中很少使用，因为标准的不可变映射通常速度会更快。唯一的例外是，在构造映射时由于某种原因，链表中靠前的元素被访问的频率大大高于其他的元素。
 

zh-cn/overviews/collections/equality.md

@@ -10,7 +10,7 @@ language: zh-cn
 ---
 
 
-容器库有标准的等价性和散列法。首先，这个想法是为了将容器划分为集合，序列。不同范畴的容器总是不相等的。例如，即使包含相同的元素，`Set(1, 2, 3)` 与 `List(1, 2, 3)` 不等价。另一方面，在同一范畴下的容器是相等的，当且仅当它们具有相同的元素（对于序列：元素要相同，顺序要相同）。例如`List(1, 2, 3) == Vector(1, 2, 3)`， `HashSet(1, 2) == TreeSet(2, 1)`。
+容器库有标准的等价性和散列法。这个想法的第一步是将容器划分为集合，映射和序列。不同范畴的容器总是不相等的。例如，即使包含相同的元素，`Set(1, 2, 3)` 与 `List(1, 2, 3)` 不等价。另一方面，在同一范畴下的容器是相等的，当且仅当它们具有相同的元素（对于序列：元素要相同，顺序要相同）。例如`List(1, 2, 3) == Vector(1, 2, 3)`， `HashSet(1, 2) == TreeSet(2, 1)`。
 
 一个容器可变与否对等价性校验没有任何影响。对于一个可变容器，在执行等价性测试的同时，你可以简单地思考下它的当前元素。意思是，一个可变容器可能在不同时间等价于不同容器，这是由增加或移除了哪些元素所决定的。当你使用可变容器作为一个hashmap的键时，这将是一个潜在的陷阱。例如：
 
@@ -29,4 +29,4 @@ language: zh-cn
     java.util.NoSuchElementException: key not found: 
     ArrayBuffer(2, 2, 3) 
 
-在这个例子中，由于从第二行到最后一行的数组散列码xs已经发生了改变，最后一行的选择操作将很有可能失败。因此，基于散列码的查找函数将会查找另一个位置，而不是xs所存储的位置。
+在这个例子中，由于数组xs的散列码已经在倒数第二行发生了改变，最后一行的选择操作将很有可能失败。因此，基于散列码的查找函数将会查找另一个位置，而不是xs所存储的位置。