1. 结构体排序为什么不能直接套sort()先说个我早些年踩过的坑。当时在公司做一个比赛成绩统计的模块选手信息存在结构体里里面有姓名、编号、分数、用时四个字段。需求是先按分数从高到低排分数相同按用时从少到多排用时还相同就按编号从小到大排。我第一反应是排序嘛直接sort()一把梭不就完了结果编译都过不了报错信息还特别长看半天才明白——sort()默认用运算符比较元素而普通结构体根本没有定义编译器不知道该拿哪几个字段去做比较。这事其实暴露了一个很多人容易忽略的核心认知sort()只是帮你做“排列”这个动作但“谁在前谁在后”这个规则必须由你自己告诉它。对于int、double、string这些内置类型规则是现成的数字按大小、字符串按字典序所以直接用没问题。可一旦轮到结构体排序规则就变成了业务规则——同一批学生数据按学号排是一种顺序按成绩排又是另一种顺序按姓名拼音排又是完全不同的结果。你让编译器自己猜它当然只能罢工。所以结构体排序这件事本质上分两步第一步定义一个数据结构第二步给sort()提供一个“我该怎么比较两个结构体”的答案。第二步的写法有好几种合适的选择能让你代码更好维护、性能上也更稳。这篇就把这些情况一次讲透。另外结构体排序用到的场景远不止比赛计分。我搜了一圈发现热度高的相关搜索里还有fscanf结构体、结构体内存对齐、字符串排序、Excel按照IP地址排序、排序查询接口这类词它们其实都指向同一个问题把一批不规则的数据整理成可读、可比较的形式然后按某种业务规则排好序。这篇文章会从sort()的工作机制讲起一直讲到实际工程里怎么处理多字段、大数据量、结构体内存对齐这些容易被忽略的细节最后给一个完整的实战流程。2. 先搭好基础结构体定义与sort()函数本身的边界2.1 结构体最常见的三种定义方式结构体是C和C里组织一组相关字段的基础工具。三种常见写法新手经常弄混这里统一说清楚。第一种最朴素的C风格写法struct Student { char name[32]; int score; int time_used; int id; }; struct Student stu1;第二种用typedef起别名这是C语言里最常见的风格不用每次写struct关键字typedef struct { int id; char name[32]; int score; int time_used; } Student; Student stu1;第三种C风格其实跟第一种差不多但C里直接就用Student当类型名不用加structstruct Student { int id; std::string name; int score; int time_used; }; Student stu1;三种写法各有适用场景。char name[32]这种定长字符数组的好处是嵌入式和C混编时兼容性好缺点是长度固定名字长一点就要截断。std::string则灵活得多缺点是它在结构体里会引入一个隐式的指针字段这一点后面讲内存对齐的时候还会提到。2.2 sort()函数族的实际使用边界std::sort是C标准库algorithm里的函数模板。它的核心设计意图是接受一个随机访问迭代器区间按你提供的规则把区间内的元素重新排列。它用到的排序算法是内省排序introspective sort一种混合策略——数据量大的时候用快速排序递归深度过深时切换成堆排序数据量小的时候用插入排序收尾。所以它的平均复杂度是O(n log n)最坏情况也不会退化到O(n²)这是它比手写快速排序更让人放心的原因。用之前必须包含头文件#include algorithm如果你用的是std::vectorStudent这种容器正好能用begin()和end()做迭代器。如果用的是Student arr[100]这种C风格数组就传arr 0和arr 100也就是首元素指针和尾后指针。这里有一个必须记住的边界sort()是不稳定排序元素相等时它们的相对顺序不保证维持原样。如果你需要相等的元素保持原来的先后顺序请用std::stable_sort()。stable_sort一般用归并排序的思路实现平均复杂度同样是O(n log n)但通常会多消耗一些额外内存。这个差别在下一章工程实践里会详细展开。还有一个更细的边界sort()要求接收的是随机访问迭代器。这意味着std::list这种双向链表天生用不了sort()链表得用自己成员函数std::list::sort()。真要给链表数据排序要么老老实实转成vector再排。2.3 排序比较器的结构不只是“返回bool”这么简单比较器是sort()的第二个参数它必须以“严格弱序”strict weak ordering的规则来工作。解释一下这个词比较器接受两个元素a和b返回true表示a应该排在b前面返回false不表示b一定排在a前面只表示“a不确定在b之前”两者相等也可能返回false。严格弱序有三个核心要求违反任何一个都会导致未定义行为排序结果可能直接就是乱的非自反性comp(a, a)必须返回false。不对称性comp(a, b)为true时comp(b, a)必须为false。传递性comp(a, b)为true且comp(b, c)为true时comp(a, c)必须为true。最常见的反例就是比较函数里混用了。comp(a, b)返回a b那么comp(a, a)会返回true直接违反非自反性。排序算法内部的交换逻辑一旦基于这种错误比较器结果就是一堆乱序而且这问题几乎不会报错只在结果上看不出来排查起来很头疼。理解这个之后再去看代码里别人的比较函数再也不觉得那只是一个“返回bool的工具”了它直接决定了排序结果的正确性。3. 自定义比较器的四种写法与取舍3.1 方法一直接在结构体里重载运算符C风格的惯用做法把排序规则内聚到结构体类型本身。给结构体重载operatorsort()不传第三个参数时就会自动使用这个规则#include algorithm #include vector #include string struct Student { int id; std::string name; int score; int time_used; bool operator(const Student other) const { // 分数高排前面 if (score ! other.score) return score other.score; // 用时少排前面 if (time_used ! other.time_used) return time_used other.time_used; // 编号小排前面 return id other.id; } }; int main() { std::vectorStudent students { {1, Alice, 85, 100}, {2, Bob, 92, 90}, {3, Carol, 92, 85}, {4, Dave, 85, 95} }; std::sort(students.begin(), students.end()); return 0; }这种写法的好处是调用方代码简洁排序规则跟数据结构绑定只要看到这个结构体就能知道它的默认排序逻辑适合那种“一个结构体在项目里只有一种排序需求”的场景。坏处也很明显如果哪天产品经理告诉你“成绩页用刚才那个规则但名单页要按学号升序排”你重载了就只能两种选择——要么再写个比较函数传给sort()要么临时改结构体里的operator改来改去极其难受。所以这个写法适合规则稳定、全局唯一的场景。3.2 方法二全局比较函数C语言里没有重载所以最正统的做法就是写一个普通的比较函数然后作为第三个参数传进去bool compareByScore(const Student a, const Student b) { if (a.score ! b.score) return a.score b.score; if (a.time_used ! b.time_used) return a.time_used b.time_used; return a.id b.id; } std::sort(students.begin(), students.end(), compareByScore);这里传的是函数指针sort()每次比较时都会通过函数指针调用这个函数。写法直白任何C程序员都能看懂也方便在其他地方复用。面试的时候我经常让候选人手写这一点目的就是看你能不能把规则从数据里抽离出来。但函数指针在性能上存在一个隐患编译器做内联优化时函数指针往往拦了一道。虽然现代编译器在编译期能根据模板参数推断出函数指针的具体值并做内联处理但实际效果有时候不如直接传函数对象functor或lambda来得好。如果排序的是几十万、上百万条结构体数据这个差距会被放大后面专门讨论性能时会提到。3.3 方法三仿函数函数对象所谓仿函数就是一个重载了operator()的类或结构体。因为它是一个对象所以可以在内部持有状态从外面往里传参数灵活性比函数指针高出不少struct CompareByScore { bool ascending; // 控制升序还是降序 explicit CompareByScore(bool asc false) : ascending(asc) {} bool operator()(const Student a, const Student b) const { if (ascending) return a.score b.score; return a.score b.score; } }; std::sort(students.begin(), students.end(), CompareByScore(true));仿函数最大的好处是可以携带配置信息。比如排序规则里有一个“权重大小”或者“是否倒序”的开关直接通过构造参数传入。STL的std::greaterint、std::lessint本质就是内置的仿函数用起来不用自己写std::sort(nums.begin(), nums.end(), std::greaterint()); // 降序在C11之前仿函数是“可配置比较规则”的最主流方案。后来有了lambda它更简洁但你在老项目或者自己实现的模板库里还是会经常碰到仿函数所以必须认识它。3.4 方法四lambda表达式C11起最推荐C11引入了lambda写比较规则变得非常轻快。上面的多字段排序可以写成这样std::sort(students.begin(), students.end(), [](const Student a, const Student b) { if (a.score ! b.score) return a.score b.score; if (a.time_used ! b.time_used) return a.time_used b.time_used; return a.id b.id; });不需要单独定义函数或结构体比较逻辑就地放置读代码的时候上下文连贯一眼就能看出来排序规则。这也是我目前在实际项目里最常推荐的做法。lambda还能捕获外部变量实现动态排序规则bool ascending false; // 可以来自用户输入或配置 std::sort(students.begin(), students.end(), [ascending](const Student a, const Student b) { return ascending ? a.score b.score : a.score b.score; });注意lambda在C20之前默认是const的即捕获的变量在lambda体内不能修改。如果一定要改要加mutable关键字但排序比较器里基本用不到这个老老实实保持const逻辑就够了。3.5 四种写法的选型对比写法代码简洁度可配置性性能适用场景重载operator最高差全局唯一规则好结构体只有一种天然排序规则的场景全局比较函数中等一般好C风格老代码、面试手写仿函数中等强可传参好可内联需要携带配置、复用性强的库代码lambda高高捕获外边变量好现代编译器可内联C11之后几乎都能用我最推荐一句话总结新代码优先lambda规则单一且封装性强时重载operator写库给别人用时仿函数更规范。没有绝对最优的写法只有当前场景下最合适的。4. 多字段排序与稳定性工程里真正要命的细节4.1 二级、三级排序怎么做不绕弯回到开头那个比赛成绩的例子需求是“分数降序分数相同用时升序用时相同编号升序”。这是典型的多键值排序写法上有个通用套路我管它叫“逐字段撇开”std::sort(students.begin(), students.end(), [](const Student a, const Student b) { if (a.score ! b.score) return a.score b.score; // 第一键 if (a.time_used ! b.time_used) return a.time_used b.time_used; // 第二键 return a.id b.id; // 第三键 });核心思想是从排序需求里第一个提到的字段开始哪个字段有差异就拿哪个字段决定大小只有在当前字段相等时才继续拿下一个字段比较。这个嵌套判断结构就是把业务规则翻译成严格弱序的最直接方式。还有一种写法是“组合排序键”把多个字段拼成一个字符串或一个复合值然后按这个值的字典序排。比如按用户所在部门职级入职时间排序且字段都是字符串或定长数字那么可以拼成RD-03-20200101这种格式然后整体一次排序。这种方法写起来短但前提是所有字段可以无歧义地拼起来否则很容易出现拼接后顺序错乱的情况我见过不止一次因为日期格式没补零导致排序错的BUG。4.2 稳定排序等值元素的命运抉择std::sort是不稳定的。如果要排的数据里键值相等的两个元素按插入顺序排列就符合业务预期那必须用std::stable_sortstd::stable_sort(students.begin(), students.end(), [](const Student a, const Student b) { return a.score b.score; });举一个真实场景一个在线教育网站的学生列表先按“是否已报名”分组然后再按“报名时间”排序。如果用sort()相同报名时间的两个学生顺序会被打乱如果先按报名时间排一次再用sort()按“是否已报名”分组第二轮的sort()很可能把所有同组学生顺序重新洗一遍。这时稳定排序的价值就体现出来了——先按次要条件排一次再用稳定排序按主要条件排一次得到的序列在主要条件相同的情况下自动保留了次要条件的顺序。这个二级排序技巧非常实用可以省掉复杂的多字段比较器。不过stable_sort也不是没有代价。它在归并过程中可能需要分配临时缓冲区内存开销通常比sort更大性能在有些数据分布下也稍慢。数据量小的时候无感几百万条时差距就能测出来。我很早以前踩过这个坑对一个大表做稳定排序结果内存暴涨程序差点把服务器内存打满。所以判断依据很简单——没明确要求“相同键值保持原始顺序”就别用stable_sort。4.3 字符串、IP、浮点数排序要特别注意热搜词里出现了字符串排序、excel如何按照ip地址排序这两个词。字符串排序表面上直接用std::string的运算符就行但每次比较都走字符串字典序性能上是有开销的。而且字符串默认排序是大小写敏感的ASCII码里大写字母全部排在小写字母前面Apple会排在banana前面。要按字母顺序且忽略大小写的话比较器里要用std::tolower转换后再比或者用C的std::lexicographical_compare加上自定义字符比较函数。IP地址排序更是个经典坑。字符串字典序排出来是192.168.1.10排在192.168.1.2前面因为1比2小。但按实际的IP数值语义1.10应该排在1.2后面。工程里公会犯这种问题的Excel里也一样。对这种数据要么把IP拆成四段分别比较要么每段转成整数后拼接出一个整数键来排。常见的做法是写一个结构体把IP字符串存起来排序比较器里做拆分struct IpAddress { std::string ip; }; int ipPart(const std::string ip, int index) { // 找第 index 段0开始用stringstream或手动split解析 } bool operator(const IpAddress a, const IpAddress b) { for (int i 0; i 4; i) { int pa ipPart(a.ip, i); int pb ipPart(b.ip, i); if (pa ! pb) return pa pb; } return false; }浮点数排序也有讲究。结构体字段是double或float时直接用比较通常没问题但要小心NaN。NaN比任何值都“不小不大于”出现comp(a, b)和comp(b, a)都为false的情况严格弱序直接崩坏排序结果随机。如果你的数据源里浮点字段可能包含NaN比如传感器读数、无效值标记比较器里一定要先处理一下。5. 性能与内存结构体排序背后的两个隐藏杀手5.1 排序大量结构体时别让拷贝拖垮你在讲比较器写法时我曾经提过关于函数指针和lambda内联的性能差异。真正拖慢排序的往往不是比较器本身而是排序过程中交换元素时的拷贝开销。sort()在排序时会对元素做大量的swap操作如果结构体很大每次swap都要完整拷贝整个结构体的所有字段。一个包含多个字符串、数组、甚至嵌套结构体的Student对象可能动辄几十上百字节几十万次交换就会产生巨大的内存搬运量程序慢得让人怀疑是不是死循环了。有三种常见的解决办法排序指针或索引而不是直接排序结构体本身。排完之后按顺序输出指针指向的内容。std::vectorStudent* ptrs; for (auto s : students) ptrs.push_back(s); std::sort(ptrs.begin(), ptrs.end(), [](const Student* a, const Student* b) { if (a-score ! b-score) return a-score b-score; return a-id b-id; });结构体内部用std::string这类自动管理内存的类型避免定长大数组增加拷贝量。使用C11的移动语义把重结构体的拷贝成本降下来。但注意要给结构体定义合适的移动构造函数和移动赋值运算符否则编译器默认还是走拷贝。顺带提一句排序指针的方案不但能减少拷贝有时还能改善缓存局部性——前提是结构体本身在内存中的分布比较连续。这个优化在数据量百万级以上时效果非常明显我曾经把一个排序耗时从7秒降到1.8秒就是靠排序索引数组实现的。5.2 结构体内存对齐为什么会白占空间还会影响排序性能搜热词里结构体内存对齐、结构体字节对齐占了很大比例可见这个坑覆盖面有多广。先看一个结构体struct Example1 { char c; // 1字节 int i; // 4字节 char d; // 1字节 };直觉上它的大小是6字节但sizeof(Example1)在很多平台上结果是12字节。原因是编译器默认做了内存对齐结构体成员的偏移量必须是对齐系数的整数倍整个结构体的大小也得是对齐系数的整数倍。把成员按大小从大到小排列能有效减少填充字节struct Example2 { int i; // 4字节 char c; // 1字节 char d; // 1字节 };sizeof(Example2)就变成8字节少了4个字节的填充。如果结构体是几百万条数据的元素每条省4字节总内存就能省十几兆排序时内存带宽压力也跟着降。对齐不仅影响内存占用还影响排序性能。结构体元素越大每次比较和交换搬运的数据就越多。所以在设计结构体字段顺序时养成“大字段在前、小字段在后”的习惯顺带把对齐也考虑进去是资深工程师和普通程序员的一个明显区别。还有一种场景是网络协议、文件格式解析时需要精确控制内存布局不希望编译器自动填充字节。这时要用#pragma pack(push, 1)或者C11的alignas来手动控制对齐。但用#pragma pack(1)压缩对齐后有时候CPU访问未对齐数据会有额外开销或者崩溃风险所以别一上来就pack能自然对齐就自然对齐。5.3 fscanf结构体从文件批量读入再排序的完整思路热搜词fscanf结构体提醒了我一个很典型的工程场景从配置文件或日志文件批量读取记录然后排序处理。比如一个比赛成绩文件每行格式是id name score time要读到一个结构体数组里再排序。fscanf是C标准库里的格式化输入函数它和结构体配合时一定要保证占位符跟结构体字段类型完全匹配。一个典型的错误是读取字符串时缓冲区不够大或者用%d读float字段导致数据错乱。#include cstdio #include vector struct Record { int id; char name[64]; float score; }; std::vectorRecord records; FILE* fp fopen(scores.txt, r); if (fp) { Record r; while (fscanf(fp, %d %63s %f, r.id, r.name, r.score) 3) { records.push_back(r); } fclose(fp); }注意%63s限制了name最多读63个字符留一个给结尾的\0防止缓冲区溢出。这在安全上很重要不能省略。读完之后用前面讲的任何一种比较器调用sort()整个“读取—解析—排序—输出”流程就串起来了。如果文件很大一次性全读到内存会撑不住那就需要用到外部排序的思路分块读入、每块排序后写到临时文件最后做多路归并。这是另一个话题但结构体排序的核心比较器逻辑是完全一样的。6. 排序结果的验证与调试你以为排对了很可能并没有6.1 用std::is_sorted快速自检写完排序代码怎么能确认结果真的满足需求肉眼盯几行数据在数据量小的时候可以但几百条以后就力不从心了。C标准库提供了一个现成的工具std::is_sorted。它接受一个迭代器区间和比较器返回bool检查序列是否已经按该规则排好序。#include algorithm bool ok std::is_sorted(students.begin(), students.end(), [](const Student a, const Student b) { if (a.score ! b.score) return a.score b.score; return a.id b.id; }); if (!ok) { // 排序有问题进调试 }这个检查通常放在排序完成后、正式使用数据前。它本身也是O(n)的扫描不会对性能造成明显影响。在单元测试里这几乎是我必写的断言。但要注意is_sorted验证的只是“按给定比较器判断的有序性”不能证明比较器本身符合业务语义。比如比较器写反了is_sorted依然返回true。所以第一步应该先写几条肉眼能验证的数据排完了打印出来看一眼再上大量数据。6.2 大型数据的抽查策略大数据量排序的验证我常用的方法是“抽样断点检查”排序完成后每隔1000条取一条相邻的pair用比较器判断这两条是否有序。这样扫描一遍O(n)但没有额外的存储开销。还有一个更容易踩雷的地方排序结果还要和原始数据对应上。比如你用排序索引数组的方式排了指针最后输出时如果忘了通过指针还原原始内容很可能出现“排序看起来对但字段内容对不上”的诡异现象。每次输出前检查一下索引数组和结构体数组是不是一一对应。另外绕不开的边界条件是空数组、只有一个元素的数组、所有字段全部相等的数组。这三个场景下任何排序算法都不该崩溃但很多比较器写得不严谨遇到comp(a, a)时返回了true空跑一遍没出错全等数据上就暴露出乱序或断言的失败。写单元测试时这三个用例务必加进去。6.3 调试模式下的可视化排查如果排序结果就是不对怎么定位我的习惯是在排序前和排序后各打印一次完整数组输出时多打几个字段而不是只打印排序键。Alice 92 100 1和Bob 92 85 2这种输出能让你直接看到“分数相等时到底比没比第二键”。如果数据量太大不能全打就把排序前和排序后同时打印前五十条观察是否有元素“跨段乱入”。像std::sort不稳定导致的乱序往往表现为跨段元素的相对位置变了。还有一个调试技巧给结构体临时加一个自增序号字段从0开始编排完序后多打印这个序号。稳定排序和快速排序在不稳定场景下的差异一眼就能看出来也方便你判断是不是必须换stable_sort。7. 两个实战扩展从结构体排序延伸到更广的排序场景7.1 对比选择排序、希尔排序为什么工程里很少手写它们搜热词里有选择排序、希尔排序、数据结构排序算法、拓扑排序、计数排序这些。很多初学者会纠结我会写五种排序手写实现是不是就比只会sort()的人强我自己的看法是手写排序的核心价值在于理解算法思想工程上直接调库通常是更优解。选择排序O(n²)数据量一大就完蛋冒泡排序在几乎有序的数组上表现还行但平均性能依然差希尔排序比前两者好但它的步长序列选择影响很大调优成本高。std::sort的内部是内省排序插入排序的混合从设计上就考虑到了最坏情况、平均性能和缓存友好性几乎没有理由在正式项目里拒绝它而去手写一个快排。唯一需要手写的场景是嵌入式环境不能依赖标准库、面试时考察算法掌握程度以及处理数据有特殊内存约束的场合。比如一个内存只有几千字节的MCUstd::sort未必能跑起来这时候手写一个简单插入排序反而更合适。7.2 二维数组、结构体数组、数组的数组排序时别把维度搞混热搜词里还有二维数组排序sort。二维数组排序的核心问题是你要排的是“第一维方向”还是“第二维方向”对每行内部的元素排序把二维数组看成多个一维数组逐个sort。按每行的某个特征比如行首元素对行做排序这时候可以构造一个“行索引数组”对所有行索引排序比较器里通过索引访问二维数组的行内容。能不能直接把二维数组整个用sort排要看数组的内存布局。如果是C的vectorvectorint每一行是一个对象里面存储的是指向各自堆内存的指针sort默认比较的是这些vectorint对象本身如果不提供比较器会编译失败。所以还是得提供自定义比较器比较器可以按行长度、行内最大值等规则来定。结构体数组本质上和一维数组没区别你传给sort的是begin()和end()元素是结构体规则用比较器指定。掌握了这一点上面这些变体都逃不脱同一个模式“给定两个元素告诉我谁该在前”。7.3 结构体与信号槽、数据库排序的关联热搜词里有一条qt5信号槽传递结构体看着和排序没关系其实是另一个维度的结构体操作。Qt5里信号槽要传递自定义结构体需要先用qRegisterMetaTypeStudent(Student)注册元类型才能在connect时通过队列连接传递。这提醒我们结构体不是只能存在数组里排序它还可能通过网络、事件、数据库各种途径流转。sequelize别名排序、mysql排序、排序查询接口这些搜索词对应的是数据库后端排序。数据库里对结果集排序用ORDER BY它跟C结构体排序的思想是完全一致的指定多个键、每个键升序降序、组合排。实际上很多服务端排序接口的排序规则也是多字段的JSON配置解析以后最终还是要交给数据库或内存排序来做。这里有个工程建议如果在内存里要排序的数据本身来自数据库尽量让数据库排序它能利用索引网络传输量也更小。只有当数据必须全部拉回内存做二次加工时才考虑在C层面对结构体数组排序。这也是一种“把活交给最擅长的人”的思路。7.4 结构体排序在串口/调试器场景的一个坑热搜词里有keil调试助手里面的debug模式如何显示结构体变量。这说明不少做嵌入式的朋友会遇到“结构体排序排完了但调试器里没法直接看排序结果”的困惑。Keil等调试器的Watch窗口通常能展开结构体变量但数组显示受限于编译器的调试信息格式。我遇到过的真实情况是结构体数组太大调试器只显示前几个元素根本看不到后面排序变化。解决思路有两种一是在排序完成后把数组的首地址、元素个数、元素大小拷到一个for循环里通过串口打印出来二是写一个简单的验证函数在代码里直接比较相邻元素确认顺序之后就置一个标志位在调试器里只观察这个标志位的变化。这其实又回到了“验证比观察更重要”的主题——调试器只是工具真正可靠的验证还得靠代码里的自动检查。8. 个人经验调试结构体排序时的几个真实教训最后把这几年在结构体排序上踩过的最有价值的坑集中列一下每条都代表一次真实事故。第一比较器写成或是隐含崩溃源。有个项目用写比较器排序结果偶尔错乱本地跑一百次可能只出现一次客户那边一发版就出问题。因为comp(a, a)返回truesort内部的某些实现会在特定数据分布时触发死循环或越界访问。排查两天最后用is_sorted加缩小数据规模的办法才定位出来。从此之后我写比较器只允许和绝不写等号。第二结构体字段顺序影响内存占用间接影响排序速度。一个数据表里有几百万条记录结构体里有三个char字段分散在几个大字段中间导致每条记录多了6字节填充。几百万条就是十几MB的差距排序时的内存带宽压力明显增加。重新排列字段顺序后内存占用下降排序时间也跟着降了大约20%。第三别忽略fscanf读取失败的情况。文件多一行空行fscanf返回的不是预期的3循环就提前退出漏掉数据。排序结果看着“对”但少了一条数据。后来我在读取循环里分别统计成功条数和总行数解析完对不上发现是空行问题。这件事以后我养成了习惯文件数据读入结构体后先输出总条数给人眼确认一下再继续后续处理。第四排序前先拷贝一份原数据用于对比。尤其是在做性能调优和算法替换的时候如果你改了比较器逻辑排序结果跟原来不一样但你又不敢确定哪个是对的那就麻烦了。提前保存一份原始数据必要时可以还原回去检查。这些教训看着不大但每一个都可能在数据量一大、条件一复杂的时候变成线上事故。结构体排序本身很简单难就难在“排序规则是不是准确表达了业务”以及“数据边界是不是都cover住了”。我把这套方法论沉淀成了一套检查清单明确排序键、检查比较器的严格弱序性质、小数据量肉眼验证、大数据的顺序抽检、内存和拷贝开销评估。做完这五步结构体排序基本就不会出幺蛾子了。