std::unique不能单独删除重复元素，因为它仅将相邻重复项移至容器末尾并返回新逻辑结尾迭代器，不改变容器大小，必须配合erase才能真正删除；且前提是先sort，否则无法处理非相邻重复。
为什么 std::unique 不能单独删除重复元素
std::unique 并不真正“删除”元素，它只是把重复项移到容器末尾，并返回一个指向新逻辑结尾的迭代器。原 vector 大小不变，内存里那些“被移走”的重复值依然存在——如果你不配合 erase，后续遍历时还会看到它们。
常见错误现象：vector 调用 unique 后打印长度没变、重复值还在输出里、甚至出现未定义行为（比如越界访问旧 end 迭代器）。
- 必须先
sort：因为unique只能去除**相邻重复项**，无序数据中相同值分散在各处，unique完全无效 -
unique返回的是新逻辑终点，不是原end()，必须用这个返回值配合erase - 对
vector<int></int>等基础类型安全；但自定义类型需重载operator==，否则比较行为不可控
正确写法：三步组合拳 sort + unique + erase
这是最常用、最稳妥的去重方式，适用于需要保留原始顺序以外所有重复项（即只留第一次出现的）且允许排序的场景。
vector<int> v = {3, 1, 4, 1, 5, 9, 2, 6, 5};
sort(v.begin(), v.end()); // → {1,1,2,3,4,5,5,6,9}
auto new_end = unique(v.begin(), v.end()); // → {1,2,3,4,5,6,9,6,9}，返回指向第7个元素的迭代器
v.erase(new_end, v.end()); // 真正删掉后面两个残留
注意：unique 不改变容器 size，erase 才触发内存收缩。
立即学习“C++免费学习笔记（深入）”；
- 不要写成
v.erase(unique(...), v.end())而不接sort——结果完全不可预测 - 不要漏掉
auto new_end =这一步，直接传unique(...)给erase语法虽对，但可读性差且难调试 - 如果 vector 很大，
sort的O(n log n)开销显著，此时要考虑是否真需要排序
不想排序？用 unordered_set 辅助去重
当必须保持原始顺序（比如去重后还要按输入顺序处理），就不能依赖 sort+unique。这时用哈希集合记录已见元素，边遍历边过滤。
vector<int> v = {3, 1, 4, 1, 5, 9, 2, 6, 5};
unordered_set<int> seen;
vector<int> result;
for (int x : v) {
if (seen.insert(x).second) { // insert 返回 pair<iter, bool>，second 为 true 表示新插入
result.push_back(x);
}
}
优点是稳定保持顺序、平均 O(n) 时间；缺点是额外 O(n) 空间，且不支持重复值较多时的内存优化（比如原地操作）。
-
seen.insert(x).second比先find再insert更高效，避免两次哈希查找 - 若 vector 元素类型不可哈希（如自定义 struct），需提供
hash特化和operator== - 该方法无法原地修改原 vector，必须新建容器或手动移动——若内存敏感，得权衡
容易忽略的边界与性能坑
实际项目里，几个细节常导致 bug 或性能骤降：
- 空 vector 或单元素 vector 调用
sort+unique没问题，但若用unordered_set方式，别忘了seen初始化开销虽小，高频调用下也值得测 - 对
vector<string></string>去重，sort比较开销大，且unique按字典序去重，不是按长度或内容哈希——这点常被误以为“去重失败” - 多线程环境下，
vector和unordered_set都非线程安全，若需并发去重，得加锁或改用无锁结构（如tbb::concurrent_unordered_set） - 如果只是检测是否有重复，不用真去重，用
set插入时检查insert返回值就够了，别白跑一遍sort
真正麻烦的从来不是语法怎么写，而是想清楚：要不要保序？重复值分布特征如何？内存和时间哪个更紧？这些判断比敲几行代码花的时间多得多。
