std::ranges::sort要求自定义类必须支持比较操作，即需定义operator<或提供自定义比较器，否则编译失败。
std::ranges::sort要求自定义类必须支持比较操作
直接调用 std::ranges::sort 会对迭代器解引用得到的元素类型进行比较，因此自定义类必须能参与 operator 或提供可调用的比较对象。如果没定义 <code>operator，编译会报错类似：<code>no match for 'operator。
推荐做法是为类显式定义三路比较运算符 operator（C++20），它能自动导出所有关系运算符，且比手写多个 operator 更安全、更高效：
struct Person {
std::string name;
int age;
auto operator<=>(const Person&) const = default;
};注意：使用 = default 要求所有成员都支持 <=>（std::string 和 int 都满足）。若需自定义排序逻辑（如按年龄升序、同龄按姓名降序），则应手动实现 operator<=> 或传入自定义比较器。
传入自定义比较器时要注意函数对象的值类别和捕获行为
当需要非常规排序逻辑（比如按字符串长度排序、或依赖外部变量）时，必须显式传入比较器。常见错误是用 lambda 捕获局部变量但忽略生命周期——尤其在异步或延迟执行场景中容易引发悬垂引用。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 优先使用无捕获 lambda（即不带
[&]或[=]），编译器可将其优化为函数指针，避免额外开销 - 若需捕获，确保被捕获对象的生命周期覆盖整个
std::ranges::sort调用及后续使用；临时容器排序时，避免捕获栈上局部容器的引用 - 对性能敏感场景，可将比较器声明为
constexpr函数对象，帮助编译器内联
例如按姓名长度排序：
std::vector<Person> people = {/* ... */};
std::ranges::sort(people, [](const auto& a, const auto& b) {
return a.name.length() < b.name.length();
});std::ranges::sort比std::sort更快吗？关键看迭代器类别和分配器
性能差异不来自算法本身（两者都用 introsort），而在于 std::ranges::sort 能通过 std::ranges::iterator_t 和 std::ranges::sentinel_t 更早获取容器信息，对某些容器（如 std::deque 或自定义范围）可能减少边界检查。但对 std::vector 这类随机访问容器，二者生成的汇编几乎一致。
真正影响性能的往往是以下几点：
- 自定义比较器是否
noexcept且constexpr—— 影响编译器能否内联和向量化 - 是否启用了
-O2或更高优化等级；未开启优化时std::ranges::sort可能因 ADL 查找和概念检查略慢 - 容器的分配器类型：若使用自定义分配器且未特化
std::ranges::swap，可能导致非最优交换路径
验证方式：用 std::chrono 在相同数据集、相同编译选项下对比两者的耗时，而非依赖直觉。
std::ranges::sort不接受原始指针范围，必须包装成范围对象
这是最容易被忽略的陷阱：传入裸指针（如 std::ranges::sort(arr, arr + n)）会编译失败，因为 std::ranges::sort 要求第一个参数是符合 std::ranges::random_access_range 概念的类型，而裸指针对不是范围。
正确做法有三种：
- 用
std::span包装：std::ranges::sort(std::span{arr, n}) - 用
std::ranges::subrange：std::ranges::sort(std::ranges::subrange(arr, arr + n)) - 改用传统接口：
std::sort(arr, arr + n)（此时不享受 ranges 的概念约束优势，但语义明确）
注意：即使数组是栈上 C 风格数组（如 int arr[100]），也不能直接传 arr —— 必须显式构造范围。否则编译器报错类似：no matching function for call to 'sort(int*&, int*&)'。
实际项目中，最常被低估的是比较器的 noexcept 属性和范围类型的精确匹配；这两点一旦出错，要么编译不过，要么在特定数据分布下触发退化性能。写完记得用 -std=c++20 -Wall -Wextra 编译并检查警告。
