★ FEATURED ARTICLE 1. 从一次业务需求说起为什么 Go 的排序这么“麻烦”先说我最近遇到的一件事。后台管理系统要导出一张订单列表排序规则大概是这样的先按订单状态分组状态相同就按金额降序金额也一样就按创建时间升序最后再用订单号兜底保证分页稳定不乱跳。你写代码的时候大概也发现了Go 的sort包跟很多语言的排序不太一样。Java 里有Comparator链式调用Python 有key参数能传sorted甚至 JavaScript 的array.sort((a,b)a.foo - b.foo || a.bar - b.bar)一行就搞定了。但 Go 里最简单的方式是实现sort.Interface把Len、Less、Swap三个方法写出来。很多新手第一次接触会觉得很别扭明明那么简单的排序需求怎么要写这么多代码。但我想说的是这个“麻烦”恰恰是 Go 设计上的亮点。sort.Interface让你把排序的规则和数据结构彻底解耦排序算法在sort包里是通用的你只需要告诉它“什么叫做一个元素在另一个元素之前”。一旦想通了这个模型复杂排序不但不难写反而比那种链式 Comparator 更容易排查问题、更容易扩展规则、也更容易写测试。这篇文章我要聊的就是这件事用sort.Interface实现复杂多级排序的完整套路。包括基础姿势、多种多级排序的实现思路、稳定排序的重要性、性能问题以及一些我在实际项目中踩过的坑。先说结论多级排序的核心就一句话——在Less方法里按优先级逐级比较每一级要么返回结果要么继续比下一级。2. 先把基础打牢sort.Interface 是什么以及它为什么这么设计2.1 三个方法背后是“三件事”sort.Interface长这样type Interface interface { Len() int Less(i, j int) bool Swap(i, j int) }它只规定了三件事集合有多大、两个元素谁更“小”、以及怎么交换两个元素的位置。至于用的是什么排序算法——那是sort.Sort的事情你完全不关心。sort.Sort在压缩最近临被调用时可能看不出来但实际上它内部用的是快速排序、堆排序和插入排序的混合方案专门为这个接口优化的。一个最普通的例子给整数切片排序type IntSlice []int func (s IntSlice) Len() int { return len(s) } func (s IntSlice) Less(i, j int) bool { return s[i] s[j] } func (s IntSlice) Swap(i, j int) { s[i], s[j] s[j], s[i] } func main() { nums : IntSlice{3, 1, 4, 1, 5, 9, 2, 6} sort.Sort(nums) fmt.Println(nums) // [1 1 2 3 4 5 6 9] }你可能会问标准库不是已经提供了sort.Ints和sort.Slice吗为什么还要自己写IntSlice没错简单场景确实用不上sort.Slice一个函数就解决了sort.Slice(nums, func(i, j int) bool { return nums[i] nums[j] })但Interface的价值不在简单场景而在复杂场景。当你需要可复用的排序规则、需要多级比较、需要在不同数据结构之间共享同一套排序逻辑的时候Interface的优势才会完全体现出来。2.2 理解 Less 是理解一切的关键Less(i, j int) bool的语义是i位置的元素是否应该排在j位置的元素前面。这个“前面”不一定是数值小而是你业务上定义的前后关系。有个很重要的细节Less隐含了严格弱序的要求。什么意思你自己定义的比较规则必须满足几个数学上的性质比如不存在“自己比自己小”的情况比如Less(a, b)和Less(b, a)不能同时为 true。如果你写反了或者没写全排序结果会非常诡异。还有一条容易被忽略的规则当两个元素完全相等时Less必须返回false。如果相等还返回true排序算法会认为“前者必须在后者前面”导致两个相等的元素不断交换位置轻则顺序不稳定重则影响性能甚至导致异常。2.3 一个关键认知Less 的三个返回值拆解这里给你一个我常用的思考框架写比较逻辑的时候把Less当成一个“比较函数”来写。这个思想来源于 C 语言的三方比较但是 Go 里Less的返回值只有 true 和 false。按照惯例比较函数会做三件事a b返回 true表示 a 排在 b 前。a b返回 false表示 b 排在 a 前。a b返回 false表示两者等价顺序无所谓。如果只有一个比较字段这就是全部逻辑。但多级排序就复杂在这里——副比较字段只有在主比较字段全相等的情况下才“说得上话”。所以你的代码逻辑应该是if a.Primary ! b.Primary { return a.Primary b.Primary } return a.Secondary b.Secondary先做主字段比较能分出高低就直接返回分不出来再去做次字段比较。这正是多级排序的本质。注意相等情况Primary相等不能简单返回false就结束你需要接着比较二级字段。很多新手在这里栽跟头——一级字段相等时直接 return 了导致相等的元素不再根据二级字段排序。3. 多级排序的三种实现思路从“最笨”到“最优雅”3.1 思路一Less 里嵌套多层级比较这是最直觉的写法。一个订单结构体我们按“状态升序、金额降序、时间升序、ID升序”四级排序代码长这样type Order struct { ID int64 Status int Amount float64 CreatedAt time.Time } type OrderSlice []Order func (s OrderSlice) Len() int { return len(s) } func (s OrderSlice) Less(i, j int) bool { // 第一级状态升序 if s[i].Status ! s[j].Status { return s[i].Status s[j].Status } // 第二级金额降序 if s[i].Amount ! s[j].Amount { return s[i].Amount s[j].Amount } // 第三级创建时间升序 if !s[i].CreatedAt.Equal(s[j].CreatedAt) { return s[i].CreatedAt.Before(s[j].CreatedAt) } // 第四级ID 升序作为最终兜底 return s[i].ID s[j].ID } func (s OrderSlice) Swap(i, j int) { s[i], s[j] s[j], s[i] }这种写法有两个好处。第一逻辑直白维护的人一眼就能看出排序优先级。第二每一级都不需要什么花哨技巧就是基础的比较判断。但它的缺点也很明显当排序维度很多、条件逻辑很长的时候这个Less方法会迅速膨胀。比如你有五个字段要排序每个字段还有升降序和空值处理规则这个函数很快就会写到一百多行。而且不同实体之间的公共比较逻辑无法复用。3.2 思路二把比较器拆成独立的函数既然一级一级的比较本质上是一个“按照优先级依次判断”的过程我们可以把每一级的判断逻辑抽出来让代码更清晰。先定义一个比较函数类型返回值用 int 表示三态负数表示小于0 表示等于正数表示大于。type CmpFunc func(i, j int) int然后写一个通用骨架把一组比较器串起来type MultiSorter struct { len int swap func(i, j int) cmps []CmpFunc } func (m *MultiSorter) Len() int { return m.len } func (m *MultiSorter) Swap(i, j int) { m.swap(i, j) } func (m *MultiSorter) Less(i, j int) bool { for _, cmp : range m.cmps { if r : cmp(i, j); r ! 0 { return r 0 } } return false }接下来每一个比较器都是独立的函数职责单一func cmpStatusAsc(s []Order) CmpFunc { return func(i, j int) int { return s[i].Status - s[j].Status } } func cmpAmountDesc(s []Order) CmpFunc { return func(i, j int) int { if s[i].Amount s[j].Amount { return -1 } if s[i].Amount s[j].Amount { return 1 } return 0 } } func cmpTimeAsc(s []Order) CmpFunc { return func(i, j int) int { if s[i].CreatedAt.Before(s[j].CreatedAt) { return -1 } if s[i].CreatedAt.After(s[j].CreatedAt) { return 1 } return 0 } }使用的时候按优先级传入ms : MultiSorter{ len: len(orders), swap: func(i, j int) { orders[i], orders[j] orders[j], orders[i] }, cmps: []CmpFunc{ cmpStatusAsc(orders), cmpAmountDesc(orders), cmpTimeAsc(orders), }, } sort.Sort(ms)这种方案好在哪里每个比较器可以单独测试。你可以为cmpAmountDesc写单测而不需要构造整个排序场景。它还让排序规则的增删变得非常直观——加一个规则往cmps里塞一个函数就行。但每次都要自己构造MultiSorter仍然繁琐而且len、swap要从具体类型提取代码还是有些重复。更好的方式是泛型化把骨架固定下来。3.3 思路三泛型 链式调用写在项目里最舒服的版本Go 1.18 之后有了泛型终于可以把上面这套骨架包装得无比丝滑。先封装一个Sorter[T]type Sorter[T any] struct { data []T cmps []CmpFunc[T] } type CmpFunc[T any] func(a, b T) int func NewSorter[T any](data []T) *Sorter[T] { return Sorter[T]{data: data} } func (s *Sorter[T]) Then(fn CmpFunc[T]) *Sorter[T] { s.cmps append(s.cmps, fn) return s } func (s *Sorter[T]) Len() int { return len(s.data) } func (s *Sorter[T]) Swap(i, j int) { s.data[i], s.data[j] s.data[j], s.data[i] } func (s *Sorter[T]) Less(i, j int) bool { a, b : s.data[i], s.data[j] for _, cmp : range s.cmps { if r : cmp(a, b); r ! 0 { return r 0 } } return false } func (s *Sorter[T]) Sort() { sort.Sort(s) }使用时NewSorter(orders). Then(func(a, b Order) int { return cmpInt(a.Status, b.Status) }). Then(func(a, b Order) int { return cmpFloat64Desc(a.Amount, b.Amount) }). Then(func(a, b Order) int { return cmpTimeAsc(a.CreatedAt, b.CreatedAt) }). Sort()需要配套一些通用的“比较原语”func cmpInt(a, b int) int { if a b { return -1 } if a b { return 1 } return 0 } func cmpFloat64Desc(a, b float64) int { if a b { return -1 } if a b { return 1 } return 0 } func cmpTimeAsc(a, b time.Time) int { if a.Before(b) { return -1 } if a.After(b) { return 1 } return 0 }这样写清晰、可复用、易测试而且链式调用读起来就像声明式排序规则团队协作时别人看调用代码就能明白排序优先级。现在很多项目里我会优先用这个方案不完全是因为“高级”而是它把业务逻辑和算法结构彻底分开后续想加一个排序维度不用碰排序算法那一层。4. 稳定排序多级排序最容易忽略的“地基”4.1 为什么 sort.Sort 的结果会“闪跳”接着说一个我在线 BUG 排查中遇到的真实问题。当时一个列表是双层排序先按用户等级降序再按注册时间降序。理论上如果两个用户等级相同就应该按注册时间排。但我们当时没有写注册时间的比较逻辑等于说等级相同的用户顺序是“随机的”。当时的现象是接口每次返回的数据顺序都不一样有时候用户 A 在 B 前面刷新一下 B 又跑到 A 前面了。原因很简单——sort.Sort不是一个稳定排序算法它不保证相等元素的原始顺序。Go 里有一个专门的稳定排序sort.Stable它用的是归并排序会尽量保持相等元素的原始顺序。但注意这里的“原始顺序”是多级排序中的陷阱如果主排序字段相同的元素你想保留的“原始顺序”是次要字段的有序状态那必须让这个状态在排序前就已经存在。4.2 稳定排序的正确姿势先排次级字段再排主级字段假设我们要实现“状态升序、金额降序”。稳定排序的做法是这样的sort.Stable(OrderSlice, byAmountDesc) // 先按金额降序 sort.Stable(OrderSlice, byStatusAsc) // 再按状态升序这种做法背后的原理是稳定排序保证“相等”的元素保持之前的样子。第一轮按金额排好序后所有金额有序。第二轮按状态排序时如果状态相同归并排序不会去动它们的相对位置于是金额的顺序被保留下来了——相当于自动实现了次级排序。用代码说就是type byAmountDesc []Order func (s byAmountDesc) Len() int { return len(s) } func (s byAmountDesc) Less(i, j int) bool { return s[i].Amount s[j].Amount } func (s byAmountDesc) Swap(i, j int) { s[i], s[j] s[j], s[i] } type byStatusAsc []Order func (s byStatusAsc) Len() int { return len(s) } func (s byStatusAsc) Less(i, j int) bool { return s[i].Status s[j].Status } func (s byStatusAsc) Swap(i, j int) { s[i], s[j] s[j], s[i] }执行顺序很重要sort.Stable(byAmountDesc(orders)) sort.Stable(byStatusAsc(orders))几次实际操作后我的体会是稳定的多级排序实现上少写一个字段的比较逻辑而是反着实现——先排最不重要的字段最后排最重要的字段。这个方法在很多语言中都适用但 Go 程序员反而容易忽略因为 Go 的sort.Sort默认不稳定很多人没养成用sort.Stable的习惯。4.3 什么时候用稳定排序什么时候不用稳定排序是好东西但它不是万能的。sort.Stable的时间复杂度在最坏情况下比sort.Sort差一些空间复杂度也更差。对于业务数据几十万条以内的排序几乎感觉不到差别随便用但对于上千万的数据量可能就需要评估一下了。另一个极端是如果你在Less里已经写全了所有的比较字段也就是说任何两个“不等价”的元素你都能定出前后那稳定不稳定对你来说没有区别——因为压根就没有“相等元素”需要保序。这也是我在写基础排序规则时用的策略兜底字段一定要写通常用一个唯一 ID 兜底彻底杜绝随机顺序。这样即使未来有人改了排序规则也不会发生顺序忽变的问题。5. 升降序混排、空值处理、浮点数比较——容易被坑的三个细节5.1 升序降序混排不要用取反按金额升序是a.Amount b.Amount直观的降序写法是a.Amount b.Amount。但有些偷懒的写法是!cmp(a, b)这个是大忌。!cmp(a,b)的逻辑等价于“a 不小于 b”意味着a b时也会返回 true。这破坏了 Less 的严格弱序性质排序结果会错严重时还会导致交换逻辑陷入死循环。正确做法是写清楚比较关系升序a b降序a b5.2 空值、零值一定要有明确的排序规则业务里经常遇到字段为空的情况。比如订单可选优惠券、部分商品没有折扣价。如果你不给空值定义一个明确位置那么排序结果会因为字段比较的不完整而随机化。这种事在测试里很难发现因为测试数据一般都完整上线后用户数据就露馅了。我的做法是空值统一排在后面。判断先做空值处理再做人比较func cmpNullableString(a, b string, desc bool) int { aEmpty : a bEmpty : b if aEmpty bEmpty { return 0 } if aEmpty { return 1 } // a 是空排后面 if bEmpty { return -1 } // b 是空排后面 if a b { return -1 } if a b { return 1 } return 0 }注意即使排序方向是降序空值逻辑也应该单独处理不要因为整体降序就让空值跑到最前面。5.3 浮点数比较要慎用但排序里没有关系很多新手在Less里写浮点数比较时都习惯用判断相等然后就开始纠结浮点精度问题“0.10.2 ! 0.3 怎么办”但在排序场景里这个担忧是多余的。排序比较只需要一个全序关系浮点数的直接比较就是全序关系。a.Amount b.Amount告诉你某个值是否排在另一个前面不需要你去判断两个浮点数“在数学上是否相等”。你不需要纠结“相差 0.0000001 算不算相等”的哲学问题因为排序要求的是两个值必须能分出前后或者等价。Go 的、本身就是严格的、确定性的比较用它们做排序完全没问题。唯一要注意的是NaN的存在。如果字段里可能出现 NaN它跟任何数比都是 false这会导致排序不稳定。你要么提前清洗数据要么在比较函数里显式处理 NaN。5.4 通用比较原语参考表类型升序写法降序写法int/int64a - b转三态b - a转三态float64if a b return -1等if a b return -1等stringstrings.Compare(a, b)取反时注意处理相等time.Timea.Before(b)a.After(b)bool!a ba !b6. sort.Slice 能替代 Interface 吗说说我的选型标准现在很多人写 Go 都用sort.Slice一句话就把 Less 写完了比如sort.Slice(orders, func(i, j int) bool { if orders[i].Status ! orders[j].Status { return orders[i].Status orders[j].Status } return orders[i].Amount orders[j].Amount })这代码简单、直观对于一次性排序需求完全够用。那sort.Interface的价值在哪我分享一下自己的选型标准。用sort.Slice的场景排序逻辑只用一次不需要复用。代码量少局部看能得到很清晰的理解。项目的 Go 版本较低或者团队风格就是偏好函数式写法。用sort.Interface或者自封装排序器的场景排序规则会在多个地方复用避免复制粘贴后改漏一处。需要仔细测试排序逻辑希望每个级别单独测。排序规则是动态的依赖外部配置或参数。想在排序前后加埋点、日志、统计集中在Swap里做反而更省事。有个实际体验有次我们需要根据用户所在地不同的排序规则动态生成组合比如 A 地区按“价格优先”B 地区按“时间优先”。用sort.Slice写了一个巨大的闭包看起来头都大了。后来改成封装一个MultiSorter每个地区只需要配置自己的cmps列表规则一目了然。另外提醒一下sort.Slice的实现本质上仍然是把闭包包装成Interface它并没有在性能上比特地手写 Interface 有额外优势。它们都经过sort.Sort或sort.Stable的快路径性能几乎没差别。7. 实战真实项目中如何落地一套可扩展的排序层7.1 定义排序方向的枚举和可配置结构实际项目中排序规则往往不是写死在代码里的而是来自 API 请求参数。客户端传来“status,asc;amount,desc;created_at,desc”这样的规则后端要能解析并动态构造成排序器。我建议设计一个排序配置结构体type SortField struct { Field string Desc bool } type SortConfig []SortField排序器和具体结构体解耦之后配置驱动就很自然了func BuildOrderSorter(data []Order) *Sorter[Order] { s : NewSorter(data) for _, field : range config.SortConfig { // config 来自请求或配置中心 switch field.Field { case status: s.Then(cmpIntByFieldStatus(field.Desc)) case amount: s.Then(cmpFloatByFieldAmount(field.Desc)) case created_at: s.Then(cmpTimeByFieldCreatedAt(field.Desc)) default: continue } } s.Then(cmpIntByFieldID(false)) // 防止排序规则不足导致随机顺序 return s }这里兜底字段的重要性再次体现用户传了一个很随意的排序规则哪怕只指定了一个字段ID 兜底也能保证顺序稳定。7.2 结合 context 实现可取消的排序排序本身很快但如果数据量极大比如百万级我们希望排序过程能响应 context 取消信号避免占用资源。不过 Go 标准库的sort.Sort不感知 context你只能在排序前判断一次。如果真的要持续响应取消信号需要自己实现带取消检查的排序算法这比较罕见一般不建议你这么做。对于绝大多数业务场景排序就是毫秒级或者几十毫秒级不需要打断。真的遇到超大集合更应该考虑的是是不是可以把排序下推到数据库毕竟数据库的索引排序更划算不要等数据加载到内存再排序。7.3 排序性能调优实测记录我对三种实现做过一个不怎么严谨的基准测试数据量 10 万条 Order方案耗时ns/op说明sort.Slice手写全字段 Less约 80ms最快无额外分配sort.Stable两次排序约 120ms额外内存分配较多MultiSorter泛型方案约 90ms与手写基本持平略有闭包调用开销结论是泛型封装的 MultiSorter 不会带来明显性能损失可以放心在日常项目中使用。如果数据规模不大几千条这三种方案根本没有肉眼可见的差别。真正影响性能的不是排序方案而是Less里的字段访问和数据分配。比如在比较函数中反复做字符串拼接、上级函数调用、取指针等操作都会拖慢排序速度。7.4 自定义数据结构的排序特殊场景sort.Interface不止适用于结构体切片。它的Len、Less、Swap可以映射到任意数据结构上。比如链表排序。标准库的sort.Sort要求随机访问链表不满足但你可以实现一个适配器type ListSorter struct { list *LinkedList } func (s *ListSorter) Len() int { return s.list.Len() } func (s *ListSorter) Less(i, j int) bool { a, _ : s.list.Get(i) b, _ : s.list.Get(j) return a.(int) b.(int) } func (s *ListSorter) Swap(i, j int) { a, _ : s.list.Get(i) b, _ : s.list.Get(j) s.list.Set(i, b) s.list.Set(j, a) }不过这依然是 O(n^2) 的获取和赋值不如直接转切片排序再重建链表。这里只是说明Interface的抽象能力它不关心你的底层容器是什么只要你能实现三个方法就行。7.5 多字段排序与索引排序的取舍最后说一个设计层面的问题。如果数据经常需要按多种不同的字段组合排序你会面临一个选择在内存里每次动态排序还是在维护数据时就按多个索引维护顺序前者灵活但每次 O(n log n)后者高效但实现复杂。我的建议是业务量在几十万条以内直接内存排序就好百万级以上且排序频繁、实时性要求高就要考虑数据库层面的多字段索引或引入专门的搜索引擎。不要用 Go 程序硬扛大规模全量排序这不合理。如果你发现排序成了系统瓶颈先想想有没有办法减少数据量或者能不能把排序下推而不是一味优化Less函数。8. 踩坑实录我见过的 sort.Interface 五大经典问题结合我自己和其他同事的实际经历整理几个典型的坑你对照着排查肯定能少走弯路。8.1 Less 返回规则自相矛盾有人会把Less这么写func (s Orders) Less(i, j int) bool { if s[i].Status ! s[j].Status { return s[i].Status s[j].Status } if s[i].Amount ! s[j].Amount { return s[i].Amount s[j].Amount } return true // 错误 }当两个元素所有字段都相等时返回 true破坏严格弱序。排序可能在数据量大时出现异常或者结果不稳定。正确法则完全相等的元素Less 必须返回 false。8.2 忘了处理相等导致后续字段不生效最常见的问题func (s Orders) Less(i, j int) bool { if s[i].Status ! s[j].Status { return s[i].Status s[j].Status } // 这里直接返回了后面的字段比较永远走不到 return s[i].Amount s[j].Amount }这种写法其实是对的。但有另一种错法if s[i].Status ! s[j].Status { return s[i].Status s[j].Status } else { return false // 这里 else 分支提前结束了比较 }一旦状态字段相等后面字段根本没机会参与排序。排查技巧如果你发现排序结果只对第一个字段有效多半就是 Less 的逻辑提前返回了。8.3 Swap 写错了位置导致数据被覆盖func (s Orders) Swap(i, j int) { s[i] s[j] // 错误直接覆盖 }正确写法是同时赋值func (s Orders) Swap(i, j int) { s[i], s[j] s[j], s[i] }这个看起来太基础了但我真见过有人把Swap当成“把数据搬过去”而不是“交换”。这种错误通常不会报错只是排序结果完全不对排查半天。8.4 Len 返回常量排序不完整func (s Orders) Len() int { return 10 // 错误写死了 }这个错误极少发生在业务代码中但一些自动生成的代码或者带有缓存的实现中可能出现。检查技巧排序后如果发现数据只排了一部分先看 Len 是不是真实的集合长度。8.5 指针切片和值切片搞混如果你持有的是[]*Order实现Less时就要用s[i].Amount而不是s[i].Amount后者根本编译不过。这倒不是编译错误的问题真正的问题是——如果你在Less里直接修改了指针指向的对象的值排序过程中可能引发难以追踪的数据竞态。比如func (s OrderPtrSlice) Less(i, j int) bool { if s[i].Amount 0 { s[i].Amount 999 // 绝对不能这么写 } return s[i].Amount s[j].Amount }排序算法会反复调用Less在比较过程中副作用修改数据会导致不可预测的结果。Less 必须是纯函数只读不写。9. 面试与八股之外Go 排序真正值得深挖的点最近 Go 面试题里很流行考排序但很多人都在背 sort 的底层算法细节比如“sort.Sort 什么时候用快排、什么时候用堆排、什么时候切到插入排序”。这些确实值得知道但如果面试官深问一句“它们的切换阈值是多少”大多数人就答不上来了。我自己的经验是八股记不住很正常重要的是理解设计模型。我来帮你梳理一下 Go 的sort包内部机制sort.Sort适用于大多数情况使用快速排序pdqsort 变体Go 1.19 之后切换为 pdqsort在数据基本有序或长度小于阈值时切换到插入排序当分区递归深度过大时切换到堆排序保证最坏情况 O(n log n)。sort.Stable使用归并排序稳定的开销是额外的内存分配。对于已经有序或者长度很小的切片它也会走插入排序快路径。sort.Slice内部其实就是把闭包转换成Interface再交给Sort。知道这些的好处是你能解释清楚“为什么大多数业务排序直接用sort.Slice就够了”同时也能解释“什么时候你自己实现Interface会更好”。面试官更看重的往往是后者——你的工程判断力。提示Go 1.19 之后的各种排序算法切换阈值并非常量在不同规模的切片上表现略有不同。如果你在写底层库且追求极致性能不要依赖于这些内部阈值直接用sort.Sort就好。10. 把这些经验收进工具箱多级排序用sort.Interface实现归根结底就是三句话在Less里按字段优先级逐个比较能比较出结果就直接返回不能就继续下一级。要善用稳定的两次排序方案——先排次级字段再排主级字段能得到同样的多级效果而且代码更简洁。无论如何都要加一个唯一字段兜底确保任何情况下排序结果都是确定性的。我个人在实际项目里的体会是多级排序的难点从来不是“怎么调用 sort 包”而是“你的业务规则是否被准确地表达成了严格弱序”。写排序代码的时候把字段的相等、空值、升降序处理想清楚比背诵任何排序算法的细节都有价值。如果你正被多级排序折磨建议先把你所有的排序字段列成一个表一行一个字段标上优先级和升降序方向。然后从上到下把表翻译成Less代码或者翻译成一行行Then(...)调用。这块表写清楚了代码基本不会错。最后别忘了一个好东西给排序逻辑写测试把每个字段单独出测试用例特别是“字段值相等”的情况——这是最容易出错、又最容易被漏掉的地方。最后再分享一个小技巧我在团队里一直提倡排序规则涉及业务语义时不要直接在Less里写裸的比较符号而是给比较逻辑起一个有意义的名字比如isHigherPriority、shouldComeBefore。这样过了一个月再回头改代码你不需要重新揣摩那几行if想表达什么直接看方法名就明白了。这个习惯帮我省了数不清的排查时间。
阅读完成 · 觉得有帮助？
