std::sort 传 lambda 有时不工作，因其要求比较函数满足严格弱序，而随意编写的 lambda（如用
std::sort 里传 lambda 为什么有时候不工作？
因为 std::sort 要求比较函数必须满足严格弱序（strict weak ordering），而随手写的 lambda 容易违反这条规则。比如用 替代 <code>，或者在浮点数比较中没处理 NaN，都会导致未定义行为——程序可能崩溃、排序错乱，甚至在不同 STL 实现上表现不一致。
实操建议：
- 始终用
实现比较逻辑，不要用 <code> 或 <code>!= - 对浮点字段比较，先用
std::isnan排除 NaN，再用std::less<double>()</double>或自定义安全比较 - lambda 捕获外部变量时注意生命周期：如果
std::sort跨线程或延迟执行（实际不会，但容易惯性脑补），需确保捕获的对象仍有效
示例（正确）：
std::sort(v.begin(), v.end(), [](const auto& a, const auto& b) { return a.id < b.id; });
functor 比 lambda 多出来的控制点在哪？
functor 是个带 operator() 的类，它能持有状态、支持模板特化、可显式命名，还能被 SFINAE 或概念约束识别。lambda 本质是匿名 functor，但编译器生成的类型名不可写，没法做类型匹配或偏特化。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 需要复用同一套比较逻辑多次（比如多个容器、多个算法调用），定义 functor 更清晰，避免重复写 lambda
- 要给比较逻辑加调试日志或计数器，functor 的成员变量天然支持；lambda 只能靠 mutable + 静态变量，难维护
- 泛型代码中若需对比较器做 trait 判断（如
is_nothrow_invocable_v），functor 类型更可控
示例（functor 支持状态）：
struct ByNameThenId {<br> int call_count = 0;<br> bool operator()(const Person& a, const Person& b) const {<br> ++call_count; // 这里会报错：mutable 才能改，但通常不该改状态<br> return a.name < b.name || (a.name == b.name && a.id < b.id);<br> }<br>};（注意：实际中 operator() 应为 const，状态记录建议用外部计数器）
自定义比较器和 std::vector::sort 的兼容性问题
std::vector::sort 并不存在——这是常见误解。C++20 前只有全局 std::sort；C++23 才引入 std::vector::sort，且仅接受零参数调用（即只按 operator 排），不支持传自定义比较器。所以你写的 <code>v.sort([]{...}) 在 C++23 之前根本编译不过。
实操建议：
- 坚持用
std::sort(v.begin(), v.end(), comp)，兼容所有标准版本 - C++23 下若真要用
v.sort()，得先重载Person::operator，不能绕过 - 别依赖 IDE 自动补全的
.sort(...)提示——很多编辑器对 C++23 支持滞后，补全内容可能是错的
性能差异：lambda、function、functor 谁更快？
lambda 和 functor 都是零开销抽象：编译器能内联，最终汇编和手写循环差不多。但若把 lambda 赋给 std::function 再传给 std::sort，就会触发类型擦除，带来间接调用开销（虚函数表查表 + 可能的堆分配）。
实操建议：
- 永远直接把 lambda 或 functor 传给
std::sort，不要中间塞一层std::function - functor 类名太长影响可读？用
using别名，比如using Cmp = ByNameThenId; - 怀疑性能瓶颈时，看编译后汇编：gcc/clang 加
-O2 -S，确认比较逻辑是否被内联
错误写法：
std::function<bool(int,int)> cmp = [](int a, int b) { return a < b; };<br>std::sort(v.begin(), v.end(), cmp); // 不必要开销
事情说清了就结束。真正麻烦的从来不是语法，而是把“想当然的比较”变成满足数学公理的严格弱序——这点连很多老手也会在重构时悄悄踩坑。 
