Dart中HashSet是否比Set性能更优？

首先得明确核心事实：Dart里的Set是抽象接口，HashSet是它的默认具体实现类。当你写var mySet = <String>{};或者Set<int> numbers = Set.from([1,2,3]);时，底层创建的都是HashSet实例。

为什么有人直接用HashSet而非Set？ #

• 显式指定实现类：有些开发者习惯明确写出具体实现，避免依赖语言默认行为——虽然Dart官方基本不会变更Set的默认实现，但显式声明能让代码意图更清晰，团队协作时其他人一眼就能知道这是基于哈希表的集合。
• 使用HashSet专属构造参数：HashSet的构造函数支持自定义元素的相等判断（equals回调）和哈希计算（hashCode回调）。比如处理自定义类时，如果默认的==运算符和hashCode方法不符合业务需求，可直接在初始化HashSet时传入自定义逻辑：

  class User {
    final String id;
    User(this.id);
  }
  
  var userSet = HashSet<User>(
    equals: (a, b) => a.id == b.id,
    hashCode: (user) => user.id.hashCode,
  );
  

  这种场景下，用抽象的Set接口声明的话，没法直接通过构造函数传入这些参数，必须先实例化HashSet再赋值给Set变量。

性能差异？ #

如果都是基于HashSet的实例——不管是用Set声明还是直接用HashSet声明——性能完全一致，因为它们本质是同一个对象。

只有对比HashSet和其他Set实现（比如LinkedHashSet、SplayTreeSet）时，才会有性能差异：

• LinkedHashSet会维护元素的插入顺序，插入、查询的性能比HashSet略低一点；
• SplayTreeSet是有序集合（基于红黑树），查询、插入的时间复杂度是O(log n)，而HashSet是O(1)（平均情况）。

适用场景 #

• 优先用Set接口声明变量：抽象接口更灵活，如果后续需要替换成其他Set实现（比如从HashSet换成LinkedHashSet），只需要修改初始化代码，不用改动所有变量的类型声明，符合面向接口编程的原则。
• 直接用HashSet的情况：
  1. 需要自定义元素的相等性或哈希逻辑时；
  2. 想要明确告知代码维护者，这个集合是基于哈希表实现，不关心元素顺序，只关心唯一性时；
  3. 极端性能敏感场景，虽然性能和Set声明的HashSet一致，但显式声明能避免任何潜在的默认实现变更风险（概率极低）。

内容的提问来源于stack exchange，提问作者Ουιλιαμ Αρκευα