std::ranges::sort要求自定义类必须支持operator<或显式比较器，否则编译失败；需满足std::totally_ordered约束，且不保证稳定性，稳定排序须用std::ranges::stable_sort。
std::ranges::sort要求自定义类必须支持比较操作
直接调用 std::ranges::sort 对自定义类容器（如 std::vector<MyClass>）排序会编译失败，除非该类型满足 std::totally_ordered 约束——本质是必须能用 < 比较，或显式提供比较器。它不像老式 std::sort 那样允许只传函数对象就绕过类型约束；std::ranges::sort 在编译期就检查可比性。
常见错误现象：error: no match for 'operator<' (operand types are 'MyClass' and 'MyClass') 或更长的 SFINAE 失败提示，指向 std::ranges::less 实例化失败。
- 最简方案：为类重载
operator<，且声明为constexpr和noexcept（推荐，兼容性最好） - 次选方案：不改类定义，改用带谓词的重载：
std::ranges::sort(vec, [](const auto& a, const auto& b) { return a.value < b.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。
立即学习“C++免费学习笔记（深入）”；
- 常见坑：迭代器缺少
operator->()或operator*()返回类型不是value_type&，导致std::indirectly_readable检查失败 - 快速验证：在调用前加
static_assert(std::ranges::random_access_range<decltype(my_container)>); - 救急办法：退回到
std::sort(my_container.begin(), my_container.end(), comp)，它对迭代器要求更低
排序稳定性与 std::ranges::stable_sort 的区别
std::ranges::sort 不保证稳定——相等元素的相对顺序可能改变。如果你需要稳定排序（比如先按分数排、再按插入顺序排），必须用 std::ranges::stable_sort，它接口一致但语义不同。
- 性能差异：稳定版本通常比非稳定版慢（尤其数据量大时），因为要维护额外的顺序信息
- 没有“半稳定”选项：不能通过换比较器让
sort变稳定，这是算法层面的约束 - 容易忽略的点：即使你的比较器把两个对象判为“相等”，只要它们实际内存布局不同，
sort就可能打乱原始位置——别依赖“看起来没变”来判断是否稳定
