Map为什么不扩展Collection？ 这是设计使然。我们认为映射不是集合，集合也不是映射。因此，Map扩展Collection接口几乎没有意义（反之亦然）。
如果地图是集合，则元素是什么？唯一合理的答案是“键值对”，但这提供了非常有限的（不是特别有用的）映射抽象。你既不能询问给定键所映射的值，也不能在不知道给定键所映射的值的情况下删除给定键的条目。
可以进行收集以扩展Map，但这引发了一个问题：密钥是什么？没有真正令人满意的答案，强迫一个导致不自然的界面。
可以将地图视为键（值，值或对的集合）的集合，这一事实反映在地图上的三个“集合视图操作”（键集，入口集和值）中。虽然原则上可以将列表视为映射到元素的索引的列表，但它具有讨厌的属性，即从列表中删除元素会更改与删除的元素之前的每个元素关联的键。这就是为什么我们在列表上没有地图视图操作的原因。
更新：我认为报价可以回答大多数问题。值得强调的是有关条目集合的部分不是特别有用的抽象。例如：
Set<Map.Entry<String,String>>
将允许：
set.add(entry("hello", "world"));
set.add(entry("hello", "world 2");
（假设有一个entry()创建Map.Entry实例的方法）
Map要求唯一的键，因此会违反此要求。或者，如果你在Set条目上加上唯一键，那么Set从一般意义上说，它实际上不是一个。这是一个Set进一步的限制。
可以说，equals()/的hashCode()关系Map.Entry纯粹是关键，但即使这样也有问题。更重要的是，它真的增加了任何价值吗？一旦开始研究极端情况，你可能会发现这种抽象方法崩溃了。
值得注意的HashSet是，实际上将实现为HashMap，而不是相反。这纯粹是实现细节，但仍然很有趣。
entrySet()存在的主要原因是简化遍历，因此你不必遍历键，然后查找键。不要将其作为a Map应该是Set条目（imho）的初步证据。
602392714
清零编程群