std::lexicographical_compare按字典序严格比较两序列元素，不依赖容器类型；逐对比较，首遇不等则返回，等长前缀时较短者更小；空范围恒小于非空，双空范围返回false；谓词须满足严格弱序，推荐用std::greater{}而非手写lambda。
std::lexicographical_compare 比较的是元素序列，不是容器类型本身
它只关心两个迭代器范围内的元素是否按字典序严格小于另一个范围，完全不感知 std::vector、std::string 或 std::array 是什么容器——只要能提供前向迭代器（甚至输入迭代器），就能用。
实际行为是：逐对比较 *first1 和 *first2，遇到第一个不等的元素就返回结果；若一个范围先结束，则更短的那个“更小”（前提是前面全相等）。
- 空容器
std::vector{}总是字典序小于非空容器（如std::vector{0}） - 比较
std::string{"ab"}和std::string{"abc"}时，前两个字符相等，但前者先到尾，所以返回true - 若传入两个
end()迭代器（即空范围），结果恒为false（因为“空 vs 空”不满足“严格小于”）
自定义比较函数必须满足 strict weak ordering
传给 std::lexicographical_compare 的第三个参数（谓词）不能随便写。比如用 != 或 >= 会触发未定义行为——标准明确要求它必须是严格弱序关系。
常见错误是把 std::greater<int>()</int> 直接塞进去想“倒序比较”，这没问题；但若写成 [](int a, int b) { return a > b; }，表面看一样，实则可能因编译器优化或内联方式导致不符合规范（尤其在跨平台或不同 STL 实现下）。
立即学习“C++免费学习笔记（深入）”；
- 安全做法：始终用标准函数对象，如
std::greater{}（C++14 起支持透明比较） - 手写 lambda 时，确保逻辑等价于
a 的某种可逆变换，且对所有输入组合满足反身性、反对称性、传递性 - 调试时若结果异常，优先检查谓词是否在
a==b时返回false，且从不返回true当a==b
性能上它不跳过已知相等前缀，也不做短路优化
std::lexicographical_compare 是朴素线性扫描：即使你刚调用过 std::equal 确认前 N 个元素相同，它仍会从头比起。没有内置缓存，也不识别连续内存布局优势（比如对 std::string 不会调用 memcmp）。
这意味着：在 hot path 中反复比较长且前缀高度重复的序列（如路径字符串、协议字段），它可能成为瓶颈。
- 若确定数据是 POD 且连续，可先用
std::memcmp手动优化前缀（但需注意std::string的 small string optimization 可能使 data() 不连续） - 对
std::vector<uint8_t></uint8_t>等，可考虑用std::mismatch先找差异点，再单独比较该位置 - 别依赖它自动内联或向量化——GCC/Clang 在 O2 下可能展开小循环，但不会向量化比较逻辑
常见误用：传错迭代器范围导致越界或静默错误
最典型的坑是把 vec.begin() 和 vec.size() 混在一起用，比如：std::lexicographical_compare(a.begin(), a.size(), b.begin(), b.end()) —— 第二个参数必须是迭代器，a.size() 是整数，这段代码根本无法编译。
另一个隐蔽问题是传入悬垂迭代器：容器被移动、销毁或 reserve 后，原 begin()/end() 失效，但函数不会报错，只会读垃圾内存。
- 永远配对使用
begin()/end()，不要混用data()+size()（除非显式转换为指针） - 对临时容器取迭代器要格外小心，例如
std::lexicographical_compare(v1.begin(), v1.end(), std::vector{1,2,3}.begin(), ...)中右容器临时对象在表达式结束即析构 - 启用 ASan 或 UBSan 编译能捕获大部分越界访问，但对悬垂迭代器检测有限——得靠静态分析或手动生命周期检查
字典序比较真正复杂的地方不在算法逻辑，而在于迭代器有效性、谓词语义一致性、以及和底层内存模型的耦合。这些地方一松懈，问题就藏得深。
