什么时候该用 HashSet<t></t>
而不是 List<t></t>
当你需要快速判断“某个值是否存在”，或者要自动去重，且不关心元素顺序时，
HashSet<t></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></t>（但注意它性能略低于
HashSet） 需要保持插入顺序 + 去重？
List手动查重（慢）或用
Dictionary<t bool></t>记录出现状态（快但多占内存）
常见误用：把 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></int>完全没问题；但若误用非泛型
HashSet（已淘汰），会触发装箱，性能雪崩 自定义类型进
HashSet？必须重写
GetHashCode()和
Equals()，否则所有对象都被视为不重复（或全重复）
实际项目里，最常被忽略的是：“我到底需不需要顺序？”
一旦你写了
foreach并依赖了顺序，又用了
HashSet，问题往往不会立刻暴露，而是在数据量变大或 .NET 版本升级后才随机出错。
