崩溃直接原因是比较函数违反严格弱序：若comp(a,b)与comp(b,c)为真而comp(a,c)为假，会导致分区错误、越界访问或std::terminate；常见表现是特定输入下出现段错误或断言失败。
std::sort崩溃的直接原因：比较函数返回true的逻辑矛盾
当std::sort在内部做分区或堆调整时，会反复调用你的比较函数（比如comp(a, b)）。如果它发现comp(a, b) == true、comp(b, c) == true，但comp(a, c) == false，就可能把元素放错位置——后续访问越界、迭代器失效、甚至触发std::terminate。这不是“偶尔出错”，而是只要输入数据恰好触发特定交换序列，崩溃就必然发生。
常见错误现象：std::sort在某些输入下正常，换一组数就Segmentation fault或断言失败（如GCC的__glibcxx_requires_valid_range）；MSVC下可能抛std::invalid_argument。
- 别用
a->val val当比较函数——等于关系必须由operator严格定义，不能混进<code>== - 浮点数直接比大小极危险：
abs(a - b) 不满足传递性，<code>a≈b且b≈c不保证a≈c - 涉及指针或可空字段时，未处理
nullptr会导致未定义行为（比如comp(x, y)中x为nullptr但y不是）
怎么写一个安全的自定义比较函数（以struct为例）
核心原则：只用构建逻辑，所有分支最终归结为「a是否严格排在b前面」。哪怕你要按绝对值排序、按字符串长度分组再按字典序，也得拆成明确的层级判断。
使用场景：对std::vector<person></person>按年龄升序、同龄按姓名降序排列。
立即学习“C++免费学习笔记（深入）”；
bool comp(const Person& a, const Person& b) {
if (a.age != b.age) return a.age < b.age;
return a.name > b.name; // 注意：这里用 >，不是 <，因为是“降序”
}- 每个
if分支只检查一个字段，且用!=而非==避免相等时漏判 - 末尾必须有明确的
return，不能靠隐式流程 - 字段类型必须支持
（或你已重载），且该操作本身满足严格弱序（例如<code>std::string的是安全的）
lambda捕获与生命周期陷阱：为什么排序中途访问野指针
如果你在lambda里捕获了局部容器的引用或指针，并在std::sort期间间接访问它们，而这些对象其实在排序前就被析构了——那比较函数调用时就是在读随机内存。这不是弱序问题，但常和它一起出现，且同样导致崩溃。
参数差异：传[&]看似方便，但如果被排序的容器本身是lambda作用域外的，而你又在lambda里用了另一个临时容器的引用，就容易翻车。
- 避免在比较lambda中访问任何可能提前销毁的对象（比如函数内临时
std::vector<int> tmp</int>，然后用[&tmp]） - 若需外部数据，优先用值捕获（
[=]或显式[data = some_value]），确保生命周期覆盖整个排序过程 - 对
std::shared_ptr等智能指针，确认引用计数没在排序中意外归零
调试技巧：快速定位弱序违规点
编译器不会帮你检查比较函数是否满足严格弱序，但你可以加一层防护。在debug模式下，用包装器记录最近几次调用结果，检测矛盾组合。
性能影响：这种检查只应在开发期启用，发布版必须移除——每次比较都多一次哈希/查表，排序从O(n log n)退化到不可控。
- 用
assert(!comp(b, a) || !comp(a, c) || comp(b, c))这类三元断言太重，推荐抽样检测（比如每1000次调用检查一次） - 更实用的方法：把输入数据存下来，用Python写个脚本暴力验证
comp在全部两两组合上是否满足反身性、非对称性、传递性 - Clang的
-D_GLIBCXX_DEBUG能捕获部分问题，但不覆盖所有弱序违规场景
真正麻烦的是那些依赖数据分布才暴露的问题——比如99%的输入都走同一个if分支，只有某个特定时间戳+用户ID组合会让逻辑跳转，进而触发矛盾。这时候光看代码看不出问题，得靠可复现的最小输入集。
