unordered_set查找比set快在平均时间复杂度为O(1)，而set为稳定O(log n)；关键前提是哈希函数合理且负载因子不过高，且不依赖有序性。
unordered_set 查找比 set 快在哪？
关键不是“快”，而是“平均 O(1)”，前提是哈希函数合理、负载因子不过高。它不排序，只管存和查；而 set 是红黑树，稳定 O(log n)，但每次查找都要比较键大小。如果你只关心“这个值在不在”，且不依赖顺序，unordered_set 就是更优解。
- 插入/查找/删除的平均时间复杂度是 O(1)，最坏退化到 O(n)（全哈希碰撞）
- 不支持
lower_bound或按序遍历——它没“顺序”概念 - 默认用
std::hash<T>，对int、string等内置类型开箱即用；自定义类型必须提供哈希和相等判断
怎么写一个能放进 unordered_set 的自定义结构体？
不能直接塞 struct 进去——编译器不知道怎么算哈希、怎么判相等。得显式告诉它。
- 必须定义哈希函数对象（重载
operator()），返回size_t - 必须定义相等比较函数对象（
operator==或独立仿函数），返回bool - 两者逻辑必须一致：如果
a == b，那hash(a) == hash(b)必须成立
struct Point {
int x, y;
bool operator==(const Point& other) const {
return x == other.x && y == other.y;
}
};
<p>struct PointHash {
size_t operator()(const Point& p) const {
// 避免简单异或（如 x ^ y），易碰撞；用 std::hash 混合
return std::hash<int>{}(p.x) ^ (std::hash<int>{}(p.y) << 16);
}
};</p><p>std::unordered_set<Point, PointHash> points;
查找操作怎么写才不踩坑？
别用 find 后再解引用——先确认是否找到，否则解引用 end() 是未定义行为。
-
正确写法：
auto it = s.find(val); if (it != s.end()) { /<em> found </em>/ }立即学习“C++免费学习笔记（深入）”；
错误写法：
if (s.find(val) != s.end()) use(*s.find(val));—— 调了两次find，白费性能更简洁：用
s.count(val)判断存在性（返回 0 或 1），但不返回迭代器；需要迭代器时必须用findcount()对unordered_set是 O(1) 平均，但内部仍要哈希+查桶，别以为它比find轻量很多如果只是判断存在性且不需要元素本身，
count可读性更好；如果后续要修改或访问，必须用find
为什么有时 unordered_set 比 vector.find 还慢？
小数据量（比如几十个元素）下，哈希计算+桶索引+内存跳转的开销，可能超过线性扫描的 cache 友好性。
- 元素少于 ~20–50 个时，
std::vector+std::find常常更快，尤其当数据局部性好 -
unordered_set内存占用更大（有空桶、指针、哈希值存储），cache 行利用率低 - 如果插入后只查一次，或者查完就丢，别为了“理论上快”强行套用——profile 才是唯一依据
真正影响性能的往往是哈希函数质量、桶数量（max_load_factor）、以及 key 类型的复制成本。字符串越长，哈希越重；频繁 rehash（insert 触发扩容）也会打断性能。
哈希表不是银弹，它把“查找快”押在了哈希质量和数据规模上。写完记得用实际数据测，而不是凭直觉选容器。
