该用 HashSet 而不是 List 时：需快速判断存在性、自动去重且不关心顺序；其 Contains() 平均 O(1)，无索引器，不保证遍历顺序，仅支持 Add/Remove/Contains/Clear 四种核心操作。

什么时候该用 HashSet 而不是 List

当你需要快速判断“某个值是否存在”，或者要自动去重，且不关心元素顺序时，HashSet 是更优解。比如：读取上万行日志后筛出所有唯一 IP；校验用户上传的文件名是否已存在；缓存已处理过的任务 ID。

• 查一个元素在不在集合里：HashSet.Contains() 平均是 O(1)；List.Contains() 是 O(n) —— 10 万条数据时，前者几乎瞬时，后者可能卡顿几百毫秒
• 添加重复项：HashSet.Add("a") 返回 false（不报错，也不覆盖）；List.Add("a") 照加不误，哪怕已有 100 个 "a"
• 你不能写 myHashSet[5] —— 它没有索引器；而 myList[5] 是合法且高效的

HashSet 的无序性不是 bug，是设计使然

它底层用哈希表实现，插入顺序和遍历顺序完全无关。你反复运行下面这段代码，输出顺序大概率不同：

var set = new HashSet { "cat", "dog", "bird" };
foreach (var s in set) Console.WriteLine(s); // 可能输出 dog→bird→cat

• 别指望靠 foreach 遍历顺序做业务逻辑（比如“第一个就是默认选项”）
• 需要排序？先转成 List 再调 .OrderBy()，或直接用 SortedSet（但注意它性能略低于 HashSet）
• 需要保持插入顺序 + 去重？List 手动查重（慢）或用 Dictionary 记录出现状态（快但多占内存）

常见误用：把 HashSet 当成“更快的 List”来索引访问

有人看到“HashSet 查找快”，就把它当 List 替代品，结果发现连 [0] 都不能用，或者想用 Find()、IndexOf() 失败 —— 这些方法根本不存在。

• HashSet 没有 Find()、IndexOf()、Insert()、RemoveAt()
• 它只有核心四操作：Add()、Remove()、Contains()、Clear()
• 想按位置删第 3 个？不行 —— 你得先转成数组或列表：set.ToArray()[2]（但失去 O(1) 优势）

内存与初始化的小坑

Hash

var bigSet = new HashSet(100000); // 比默认构造快不少

• List 默认容量是 0 或 4，扩容是倍增（如 4→8→16），适合“边加边用”；HashSet 扩容代价更高，因要重算所有哈希值
• 装箱陷阱：对值类型（如 int）用 HashSet 完全没问题；但若误用非泛型 HashSet（已淘汰），会触发装箱，性能雪崩
• 自定义类型进 HashSet？必须重写 GetHashCode() 和 Equals()，否则所有对象都被视为不重复（或全重复）

实际项目里，最常被忽略的是：“我到底需不需要顺序？”
一旦你写了 foreach 并依赖了顺序，又用了 HashSet，问题往往不会立刻暴露，而是在数据量变大或 .NET 版本升级后才随机出错。