std::ranges::sort要求自定义类必须支持operator
std::ranges::sort要求自定义类必须支持比较操作
直接调用 std::ranges::sort 对自定义类容器（如 std::vector<myclass></myclass>）排序会编译失败，除非该类型满足 std::totally_ordered 约束——本质是必须能用 比较，或显式提供比较器。它不像老式 <code>std::sort 那样允许只传函数对象就绕过类型约束；std::ranges::sort 在编译期就检查可比性。
常见错误现象：error: no match for 'operator 或更长的 SFINAE 失败提示，指向 <code>std::ranges::less 实例化失败。
- 最简方案：为类重载
operator，且声明为 <code>constexpr和noexcept（推荐，兼容性最好） - 次选方案：不改类定义，改用带谓词的重载：
std::ranges::sort(vec, [](const auto& a, const auto& b) { return a.value - 注意：不能只靠
operator==或operator>，std::ranges::sort明确依赖的语义
使用 lambda 作为谓词时捕获变量要小心生命周期
如果排序逻辑依赖外部状态（比如按某个运行时决定的字段名动态排序），你会写类似 [field_name](const auto& a, const auto& b) { ... } 的 lambda。这时必须确保 field_name 的生命周期覆盖整个 sort 调用——尤其是当 field_name 是函数局部 std::string 或临时量时，lambda 捕获引用会导致未定义行为。
- 安全做法：值捕获（
[=]或[field_name]），前提是捕获的对象可复制且开销可接受 - 避免引用捕获（
[&field_name]）除非你能 100% 确保其生存期长于sort执行时间 - 性能影响：值捕获增加一次复制，但对小对象（如
int、std::string_view）几乎无感；大对象建议改用静态分发（如if-else分支选择不同 lambda）
std::ranges::sort 不接受自定义迭代器类型（除非完全符合 C++20 range 要求）
如果你封装了自定义容器并提供了自己的迭代器，别想当然地认为 std::ranges::sort(my_container) 能工作。它要求该类型满足 std::ranges::random_access_range 且其迭代器满足 std::random_access_iterator，包括支持 iter + n、iter[n]、iter1 - iter2 等操作，并有正确的 difference_type 和 value_type。
- 常见坑：迭代器缺少
operator->()或operator*()返回类型不是value_type&，导致std::indirectly_readable检查失败 - 快速验证：在调用前加
static_assert(std::ranges::random_access_range<decltype>);</decltype> - 救急办法：退回到
std::sort(my_container.begin(), my_container.end(), comp)，它对迭代器要求更低
排序稳定性与 std::ranges::stable_sort 的区别
std::ranges::sort 不保证稳定——相等元素的相对顺序可能改变。如果你需要稳定排序（比如先按分数排、再按插入顺序排），必须用 std::ranges::stable_sort，它接口一致但语义不同。
- 性能差异：稳定版本通常比非稳定版慢（尤其数据量大时），因为要维护额外的顺序信息
- 没有“半稳定”选项：不能通过换比较器让
sort变稳定，这是算法层面的约束 - 容易忽略的点：即使你的比较器把两个对象判为“相等”，只要它们实际内存布局不同，
sort就可能打乱原始位置——别依赖“看起来没变”来判断是否稳定
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
