C++ STL中相等与等价：set为何不用operator==判断重复

1. 从一次面试翻车说起：两个值明明"相等"，set却放着两个元素

先讲一个我面试别人时经常抛出的问题：一个std::set<std::string>里能不能同时存在"abc"和另一个"abc"？大多数人都能答对，不能。但当我追问"set是用什么判断两个值重复的"时，很多人的回答是operator==。继续追问"If the set is sorted，它凭什么用operator==就能高效查重"，能答上来的就少了一半。如果再补一刀："那std::set<double>里，1.0和1.00算不算重复？"基本就沉默了。

这个问题的核心，就是C++ STL里最容易被忽略、但几乎所有容器和算法背后都在用的一个概念：相等（equality）与等价（equivalence）。

很多人写了好几年C++，能熟练使用set、map、sort、lower_bound，但从来没想过：有序容器从不用operator==判断重复，它用的是比较器（默认是std::less，也就是<）推导出的"等价"关系。而这个设计不是偶然，它直接决定了STL的排序算法、二分查找、关联容器的行为，也决定了你为什么能在自定义类型上只写一个operator<就能放进set里跑得飞快。

这篇文章就把这件事彻底讲透：什么是等价、什么是相等、两者怎么用、在哪些场景下它们会分道扬镳、以及你写自定义类型进STL时最容易踩的坑。

2. 严格弱排序是等价的真正地基，operator==只是选配

2.1 一个operator<如何定义"重复"

先看一个最直观的例子。

cpp复制#include <set>
#include <iostream>

struct Person {
    std::string name;
    int id;
};

bool operator<(const Person& a, const Person& b) {
    return a.id < b.id;
}

int main() {
    std::set<Person> people;
    people.insert({"Alice", 1001});
    people.insert({"Alice", 1001});  // id相同
    people.insert({"Bob", 1001});    // id相同，name不同
    std::cout << people.size() << std::endl; // 输出1
}

这里Person没有定义operator==，但set照样能判断两个元素"重复"。它是怎么做到的？

关键在于：std::set内部维护的是一个有序结构，插入新元素时，它会沿着搜索树走一遍，判断新元素应该落在哪个位置。判断的标准只有一个：comp(a, b)是否为true——即a是否排在b前面。

当插入一个新值x时，set会找到某个已存在的y，然后问两个问题：

• comp(x, y) 是否为 true？
• comp(y, x) 是否为 true？

如果两个问题的答案都是false，说明x既不小于y，y也不小于x，这时候STL就认为x和y在排序意义上是"不可区分"的，也就是等价的。既然是等价，那就按重复处理。

这个逻辑写成伪代码就是：

cpp复制bool equivalent(const T& a, const T& b, Compare comp) {
    return !comp(a, b) && !comp(b, a);
}

所以上面的例子里，第二个{"Alice", 1001}和第一个等价，插不进去；第三个{"Bob", 1001}虽然name不同，但比较器只看id，所以它和第一个也等价，同样插不进去。

2.2 为什么这里不能用operator==

有人会问：直接定义operator==，判断a == b为true就拒绝插入，不是更直观吗？

问题在于：**对一个有序容器来说，"判断相等"不是它的核心操作，"这也是STL设计者没有走的路。

3. 有序容器的三角关系：lower_bound、upper_bound与equal_range

当你真正理解了"等价"这个判定逻辑，再看有序容器提供的查询接口，很多困惑会迎刃而解。先看一个最常见的例子：

cpp复制#include <set>
#include <iostream>

int main() {
    std::multiset<int> ms = {1, 2, 2, 2, 3, 4, 5};

    auto lb = ms.lower_bound(2);   // 第一个 >= 2 的元素
    auto ub = ms.upper_bound(2);   // 第一个 > 2 的元素
    auto range = ms.equal_range(2);

    std::cout << "lower_bound: " << *lb << std::endl;                    // 2
    std::cout << "upper_bound: " << *ub << std::endl;                    // 3
    std::cout << "distance: " << std::distance(range.first, range.second) << std::endl; // 3
}

如果你只从"数学大小"的角度去理解这三个函数，很容易觉得它们是根据值2来划分的。但STL真正的语义是按比较器位置划分的。

• lower_bound(k)：找到第一个不小于k的位置，即comp(element, k)为false的第一个位置。
• upper_bound(k)：找到第一个大于k的位置，即comp(k, element)为true的第一个位置。
• equal_range(k)：同时返回这两个位置，构成一个区间。

这里最微妙的地方在于：multiset里存的可能不是int，而是自定义类型。比如你存的是"商品按价格排序"，你想查所有价格等于100的商品，lower_bound和upper_bound接受的参数严格来说应该是同一个类型、用同一个比较器。如果你手滑用了一个不同的比较方式，或者构造了一个"看起来相似但内容不同"的查询键，整个二分查找的逻辑就会跑偏。

我在一个项目里碰到过这样的问题：某个类同时有id和timestamp两个字段，比较器只按timestamp排序。结果有人用lower_bound去查找某个特定id的记录，明明库里没有这个id，却返回了一个时间戳恰好相同的其他记录——因为按timestamp这两个记录是等价的。这不是bug，是语义上的错配。lower_bound从来不保证你找到的元素"等于"你想要的元素，它只保证"排序位置不比你要找的小"。

3.1 用set查找元素时，不要在脑子里把它翻译成"找那个等于k的值"

一个让我印象很深的翻车现场是这样的：

cpp复制struct Item {
    int price;
    std::string sku;
};

struct PriceLess {
    bool operator()(const Item& a, const Item& b) const {
        return a.price < b.price;
    }
};

std::set<Item, PriceLess> items = {
    {10, "A001"},
    {20, "B002"},
    {30, "C003"}
};

这时你想找"sku为B002的商品"，很自然会想到items.find({"B002", 0})——但如果你随便给个price=0，find会认为它小于所有商品，等价比较全部失败，返回end()。你真正该做的是也让查询参数带上正确的price值，因为find的比较依靠的是price，不是sku。

但你可能会问：为什么设计得这么不友好？为什么find不能像我写一个lambda条件那样去匹配？

答案是：有序容器的查找必须利用排序结构才能做到O(log n)。如果你想按sku查找，那应该给容器换一个按sku排序的比较器，或者换一个以sku为键的std::map<std::string, Item>。如果你在一个按price排序的容器里按sku去find，本质上就是在乱用数据结构。

3.2 比较器必须始终如一：find和insert用的是同一把尺子

这句话值得单独拎出来：同一个容器在整个生命周期里，必须始终使用同一种比较语义。这在set刚创建时你当然会做到，但容易出问题的是临时构造的"查询对象"。

举例：一个std::set<std::string, std::less<>>用了透明比较器（transparent comparator），允许你用const char*去查找，不需要构造临时std::string对象。这种用法本身没问题，它的查找逻辑依然是用std::less<>去比较const char*和std::string。但如果你自己写了一个"不透明"的比较器，它强制要求两个参数都是std::string，那么你传const char*进去就会编译错误。这不是什么高深知识，但它提醒我们：查询键和容器键必须在比较器的"眼"里是同一类东西。

更隐蔽的问题在于：如果你定义的比较器是一个不对称的逻辑，比如：

cpp复制struct WeirdLess {
    bool operator()(const Item& a, const Item& b) const {
        return a.price < b.price || (a.price == b.price && a.sku < b.sku);
    }
};

单独看，这个比较器是对的，它是一个字典序（先价比再比sku）。但如果容器内部某处逻辑依赖于"等价就是两个比较都不成立"，那只要这个比较器不是严格弱排序，整个容器的树结构就会坏掉。轻则find找不到已插入的元素，重则直接崩溃。这一点我在第5章会专门讲。

4. 无序容器的另一条线：哈希 + 相等才是C++ STL的另一半

聊完有序容器，我们把目光转向std::unordered_set和std::unordered_map。这个容器家族走的是另一条技术路线：哈希表。它的查找、插入、删除都建立在两个操作之上：哈希（算桶下标）和相等（解决哈希冲突时判断是否为同一个元素）。

4.1 哈希相等判定，unordered_set的重复判断靠operator==

cpp复制#include <unordered_set>
#include <iostream>

int main() {
    std::unordered_set<int> s;
    s.insert(1);
    s.insert(1);
    std::cout << s.size() << std::endl; // 1
}

这个例子里，unordered_set去重靠的就是operator==。它先算出1的哈希值，找到对应的桶，遍历桶里的元素，用==逐一比较。哈希值相同不代表相等，但==相等一定保证哈希值相同（否则就是你的hash函数写错了）。

这就是和有序容器最大的分野：有序容器用comp推导等价，不需要operator==；无序容器用operator==直接判相等，哈希函数只负责分桶。

4.2 自定义类型放入unordered_set的两大纪律

自定义类型想进unordered_set，需要两个东西：一个std::hash<T>的特化或自定义哈希函数对象，一个operator==。这两个必须满足一个最基本的约束：如果a == b为true，那么hash(a)必须等于hash(b)。否则你会遇到"明明相等的对象，却因为哈希值不同跑进两个桶里"的灵异现象，容器里留下两份重复数据，而且你大概率找不出来。

有人可能会问：那如果我两个对象是"等价但不等"的（比如按id相等但name不同），放进unordered_set会怎样？答案是：unordered_set看不到这层关系，它只认operator==。如果name不同导致==为false，那么这两个对象就合法地同时存在。无序容器没有"等价"这个概念，它的世界只有"相等"和"不相等"。

这一点经常被搞混。我见过有人写一个类，定义了operator==按id判等，又把对象放进unordered_set，然后困惑"为什么插不进去"或"为什么插进去两个"。其实逻辑很简单：往哈希表里插入时，它先找桶，再桶内逐个==；==为true才拒绝。你的==按什么逻辑写的，容器的行为就是什么，它不会替你做更多推导。

4.3 哈希函数和相等语义的耦合，最容易被忽视

再挖一层：当你写了一个hash函数和一个operator==，它们之间不是独立的，而是强耦合的。多数项目的自定义类长这样：

cpp复制struct User {
    int id;
    std::string name;
    bool operator==(const User& other) const {
        return id == other.id;   // 只看id
    }
};

struct UserHash {
    size_t operator()(const User& u) const {
        return std::hash<int>()(u.id);
    }
};

这里一切正常，因为operator==只看id，hash也只算id，两者天然一致。但如果你把operator==改成id && name都相等，却忘了同步改hash函数，那么id相同但name不同的两个对象哈希值相同（都在一个桶），但==判false，它们可以共存。这其实还是符合规范（相等必同哈希）。反过来，如果你让hash同时掺入name，而operator==只看id，就违反基本约束了：两个id相同、name不同的对象，==为true，哈希却不相等，分到了不同桶，后插入的那个会直接成为第二个元素，容器里出现"重复"。

排查这类bug非常恶心，因为哈希表的装载、扩容、桶内遍历顺序都会影响重现，它不像逻辑错误那样稳定复现。我的经验是：自定义类型做unordered_*容器的键时，先把"相等"和"哈希"两段代码并排写在一起，保证它们比较/计算的是同一组字段。如果以后改字段，两处必须同步。

5. 自定义类型进出STL：一份实战避坑清单

这一章不聊理论，只聊我在真实代码里见过、踩过的坑。每一个坑背后，都是对"相等/等价"理解不到位导致的。

5.1 比较器破坏严格弱排序，set就变成一个神秘的"能插进重复元素"的容器

严格弱排序的四条性质：非自反性（comp(a,a)为false）、非对称性（comp(a,b)为true则comp(b,a)为false）、传递性、以及等价的传递性。写比较器时最容易违反的是传递性。

举个实际例子：

cpp复制struct BadLess {
    bool operator()(const Item& a, const Item& b) const {
        return a.price < b.price;
    }
};

如果Item的price字段本身是double，而且可能出现NaN，那NaN < x永远为false，x < NaN也永远是false。结果就是：NaN与任何值都"等价"，插入NaN后，你再也找不到它，count结果也可能是错的。这个例子比较极端，但现实里更常见的是：用浮点计算出的排序键，因为精度误差出现"a等于b、b等于c、但a不等于c"的不可传递情况，导致set的树结构彻底错乱。

怎么检查？ 一个简单方法是：插入大量随机数据后，用std::is_sorted验证从begin()到end()按比较器确实有序，同时用std::adjacent_find配合等价的否定逻辑找找有没有"等价但相邻"的异常。更彻底的方法是把比较器抽出来做单元测试，专门验证传递性。

5.2 重载了operator<却没写operator==，结果两个都进了set

注意这个小标题，它描述的是另一类bug：不是set坏了，是你对"set需要什么"的理解错了。set只需要operator<（或比较器）。我见过一位同事的代码：

cpp复制struct Point {
    int x, y;
    bool operator<(const Point& other) const {
        if (x != other.x) return x < other.x;
        return y < other.y;
    }
    bool operator==(const Point& other) const {
        return x == other.x && y == other.y;
    }
};

这个类同时定义了<和==，看起来没什么问题。但他后来又加了一个operator>和一个operator<=，然后某处写了这样一段：

cpp复制std::set<Point> pts;
if (a < b) { ... }
else if (a > b) { ... }
else { /* 认为a和b相等 */ }

问题来了：这里else分支判断的是"既非小于也非大于"，看起来和等价等价，但如果a和b是同一个对象，或者它们的x、y恰好满足某种排序关系，这个分支里的元素确实等价。但如果a和b在比较器意义下等价、但operator==为false呢？那就出现"代码认为它俩相等、实际不相等"的隐蔽bug。换句话说：当你同时拥有<和==时，必须自己保证! (a < b) && ! (b < a)与a == b高度一致。否则代码在逻辑上就会自相矛盾。写工具类时一定要想清楚：这个类型的"排序等价"和"值相等"是否是同一个概念。它们经常不是。

5.3 multiset下用count还是equal_range？语义决定了性能

很多人在std::multiset里统计某个值的出现次数，第一反应是count。count的实现没什么问题，它内部就是equal_range再求距离，或者直接把两端迭代器相减。但要注意区分语义：count返回的是"与参数等价的元素个数"，不是"==为true的元素个数"。

如果一个multiset用的比较器是"只看id"，而你传进去一个Item，它的price和库里元素不同但id相同，count照样把它们算作一组。这听着没问题，但反过来，如果比较器同时看id和price，那么完全相同的一批数据，count结果就和刚才不一样了。同样的数据，同样的语义问题，换一个比较器，count的结果可能变。

更实际的问题是性能。当multiset的元素很大、比较代价很高时，count要遍历整个等价区间；如果你只想知道"有没有"，用find检查!= end()会更合适；如果你需要区间操作，直接equal_range拿到迭代器对再处理，避免重复查找。

5.4 排序后二分查找：sort和lower_bound必须用同一个比较器

这是一条纪律：std::sort和std::lower_bound（以及binary_search）必须使用等价（相同）的比较器。 如果sort用std::less，lower_bound却用一个反序比较器，整个二分查找的区间划分就全反了，结果可能是未定义行为，也可能返回错误的迭代器。

我见过一个案例：某人自定义了一个结构体，排序时按score降序，所以sort传入了greater<>。后来想在一个已排序的vector里找某个score对应的元素，他用了lower_bound，但忘了传入greater<>，结果默认的less和排序方向相反，lower_bound返回了end()。这种问题排查起来特别浪费时间，因为代码表面上完全合法，编译器不会报任何错，只有运行结果不对。凡是排序和查找出现在同一段逻辑里，我建议把比较器定义成一个类型别名，两边直接引用，不许手写两份。

5.5 透明比较器：省临时对象，但别滥用

C++14开始，关联容器支持透明比较器（比如std::less<>），允许find、lower_bound直接用const char*去查std::set<std::string>，省掉构造临时std::string的开销。这个特性用起来很爽，但前提是：比较器必须能正确处理你传入的所有类型组合。换句话说，你写的operator()必须是一个模板，能同时接受std::string和const char*，否则编译会报错。

更危险的是：如果你用透明比较器，查询键的类型和容器元素类型不一致时，lower_bound返回的迭代器指向的依然是容器元素，但位置判断完全依赖比较器的跨类型比较逻辑。如果这个跨类型比较写得不严谨（比如把const char*当字符串比较、却忘了处理nullptr），轻则二分查找失败，重则解引用空指针。透明比较器不是免费的，它把类型安全的一部分责任转移给了你。

6. 把这个概念用透：算法库里的"等价"哲学

理解了相等与等价的差异后，再看STL算法库里的某些函数，会豁然开朗。

6.1 std::unique 的精确定义

std::unique是一个很典型的例子。它删除的是连续且等价的元素。默认比较器是operator==，但unique有一个重载，允许你传入自定义谓词。很多人不知道：unique处理的是"相邻重复"，不是全局去重。如果你给unique传入一个"只看首字母"的谓词，那么"Apple"、"Banana"、"Avocado"按首字母排序后，unique会把"Apple"和"Avocado"视为重复？不一定，取决于它们是否相邻。所以用unique去重前，要么先排序让重复元素聚到一起，要么你明确知道相邻语义就是你要的。

这里又回到相等vs等价：unique默认用==判断，但如果你想让它对"排序等价"的元素去重，必须先sort（按同一判据），再unique。很多人在一个未排序的vector上直接unique，然后发现"重复元素没删干净"，这就是没有把"等价"的连续性前提想清楚。

6.2 std::sort 的稳定性：为什么相等元素保序需要stable_sort

std::sort不保证相等元素的相对顺序，std::stable_sort才保证。这里的"相等"指什么？在C++标准里，std::sort的复杂度、行为都基于比较器；如果两个元素等价（!comp(a,b) && !comp(b,a)），它们的相对顺序在sort里不受保证。stable_sort用的也是同一个等价定义，只不过它额外保证等价元素的原始相对顺序不变。

所以如果你的序列里存在大量"排序等价但值不同"的元素，而你又需要保持它们的原始先后，那你必须用stable_sort。一个典型的例子：按优先级排序任务，但相同优先级的任务要保持提交顺序。如果你用sort，一旦比较器把两个任务判为等价，它们的先后就可能变，任务执行顺序和提交顺序就对不上了。排序稳定性的需求，本质上就是"等价不等于相等"的需求。

6.3 自定义比较器统一传入algorithm和容器

最后一个建议：把比较器定义成别名，并在所有需要它的地方引用同一份。 比如有一个struct ScoreLess，你既把它传给std::set<Player, ScoreLess>，又把它传给std::sort(players.begin(), players.end(), ScoreLess{})，再拿它去调std::lower_bound。这样做的好处是：整个管线里只有一种排序语义，不会出现"容器内有序、但你拿着另一把尺子去查"的错位。

7. 我的实际体会：什么时候该用哪种容器，以及如何测试比较器

最后聊一点工程经验。选容器的时候，很多人只看"要不要有序"这一条，实际上判断逻辑应该是：

• 如果你需要按序迭代、做区间查询、做lower_bound/upper_bound这类二分操作，选set/map/multiset。它们的世界是等价的，你要接受"等价即可重复"这个规则，并且保证比较器正确。
• 如果你只需要快速查找，不在乎顺序，选unordered_set/unordered_map。它们的世界是相等的，你要真正重载好operator==和哈希函数，并且保证两者的判定粒度一致。
• 如果一个类型两种容器都要存，务必想清楚两个问题：它的"排序键"是什么？它的"相等键"是什么？两者可能完全不同。如果不同，两种容器的行为也会完全不同，这是特性而不是bug。

至于测试比较器，我推荐一个非常土但有效的方法：写一个测试函数，生成大量随机对象插进set，然后遍历全容器验证两件事：

1. 按比较器相邻元素确实有序（用std::is_sorted）。
2. 对每个元素，lower_bound找到的位置就是它自己，或者至少find能找到它。

这能发现大部分破坏严格弱排序的比较器。另一个方法是把所有比较操作集中到一个类里，加断言日志，跑一遍核心路径，观察有没有出现comp(a,b)和comp(b,a)同时为true或同时为false的怪异情况。

个人经验是，开发期多花十分钟验证比较器，能省掉上线后好几个小时的排查时间。相等和等价这个概念，一旦想清楚了，再回头看set的插入、lower_bound的边界、unordered_set的哈希相等约束，都会变得非常自然。它不是什么高深理论，就是STL设计者为了让"排好序的结构"能高效运转而选择的一套语言规则。你顺着这套规则用，一切顺滑；你要是非用operator==的直觉去套有序容器，迟早会在某个深夜被一个查找不到的迭代器折磨到怀疑人生。