该用 HashSet<T> 而不是 List<T> 时：需快速判断存在性、自动去重且不关心顺序；其 Contains() 平均 O(1)，无索引器，不保证遍历顺序，仅支持 Add/Remove/Contains/Clear 四种核心操作。
什么时候该用 HashSet<T> 而不是 List<T>
当你需要快速判断“某个值是否存在”，或者要自动去重，且不关心元素顺序时，HashSet<T> 是更优解。比如：读取上万行日志后筛出所有唯一 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<string> { "cat", "dog", "bird" };
foreach (var s in set) Console.WriteLine(s); // 可能输出 dog→bird→cat- 别指望靠
foreach遍历顺序做业务逻辑（比如“第一个就是默认选项”） - 需要排序？先转成
List再调.OrderBy()，或直接用SortedSet<T>（但注意它性能略低于HashSet） - 需要保持插入顺序 + 去重？
List手动查重（慢）或用Dictionary<T, bool>记录出现状态（快但多占内存）
常见误用：把 HashSet 当成“更快的 List”来索引访问
有人看到“HashSet 查找快”，就把它当 List 替代品，结果发现连 [0] 都不能用，或者想用 Find()、IndexOf() 失败 —— 这些方法根本不存在。
-
HashSet没有Find()、IndexOf()、Insert()、RemoveAt() - 它只有核心四操作：
Add()、Remove()、Contains()、Clear() - 想按位置删第 3 个？不行 —— 你得先转成数组或列表：
set.ToArray()[2]（但失去 O(1) 优势）
内存与初始化的小坑
HashSet 初始容量小（默认约 7），如果提前知道要塞几万条，建议指定容量，避免多次 rehash：
var bigSet = new HashSet<string>(100000); // 比默认构造快不少
-
List默认容量是 0 或 4，扩容是倍增（如 4→8→16），适合“边加边用”；HashSet扩容代价更高，因要重算所有哈希值 - 装箱陷阱：对值类型（如
int）用HashSet<int>完全没问题；但若误用非泛型HashSet（已淘汰），会触发装箱，性能雪崩 - 自定义类型进
HashSet？必须重写GetHashCode()和Equals()，否则所有对象都被视为不重复（或全重复）
实际项目里，最常被忽略的是：“我到底需不需要顺序？”
一旦你写了 foreach 并依赖了顺序，又用了 HashSet，问题往往不会立刻暴露，而是在数据量变大或 .NET 版本升级后才随机出错。
