最近在 Go 学习群里看到一道很典型的数组重排题被反复问起给定两个数组order和friendsorder长度是n包含1到n的全部编号且不重复元素的先后位置表示选手完成比赛的先后名次而friends是一个按升序排列的数组。问题要求用 Go 语言把friends重排成与order名次顺序一致的序列。这道题表面看就是“按指定顺序重排数组”但真正写起来却很能暴露 Go 新手对切片底层、map 使用、索引映射这些基础点的掌握程度。我见过不少人花了半小时写完结果一跑就 panic或者结果完全不对。今天我就把这道题从读题到实现的完整过程拆开讲一遍顺便把容易踩的坑也整理出来给正在学 Go 数组、切片、map 的朋友一份可以直接抄作业的方案。1. 题目拆解与思路设计1.1 先搞清楚 order 到底在表达什么order数组不是排序规则它就是一张“名次表”。order[0]表示第一名是谁order[1]表示第二名是谁依次类推。比如order : []int{3, 1, 4, 2}这表示 3 号选手是第一名1 号选手是第二名4 号选手是第三名2 号选手是第四名。而friends数组是参与重排的数据源它升序排列可以看作所有选手编号的有序集合friends : []int{1, 2, 3, 4}我们的目标是把friends中每个元素按照它在order中的名次位置重新摆放最终得到result : []int{3, 1, 4, 2}稍微注意一下这里的“重排”遵循的是order 的值对应名次而不是索引对应名次。很多新手会下意识以为order[0]的编号就该排在结果数组的第0位于是直接拿order原样返回这明显不对。正确的是要解读出“编号 3 去第 0 位编号 1 去第 1 位编号 4 去第 2 位编号 2 去第 3 位”这层映射关系。1.2 从“名次映射”出发选解法一旦想清楚 order 是在表达“编号到名次”的映射解法就自然浮现了。我通常会把它分成两条路线路线一哈希表建映射法。遍历一遍order用 map 记录每个编号对应的下标名次。再遍历friends拿到每个编号的名次写到结果数组对应位置。时间复杂度 O(n)空间复杂度 O(n)。路线二排序法。把friends通过sort.Slice按order中的名次大小排一遍需要先建同样的映射或者通过自定义比较函数在线查询名次。时间复杂度 O(n log n)空间复杂度看实现方式可能 O(1)。这两种方案对比下来哈希表法显然更贴合题目“重排”的语义代码也更直观。排序法虽然也能得到正确结果但多了一个sort.Slice的比较器开销在数据量大时会有明显的性能差距。作为平时写算法题的思路我会优先推荐哈希表法这也是面试官最想看到的解法。2. 核心细节解析2.1 为什么用 map 而不是直接数组下标映射有的同学会问order 里包含 1 到 n 的所有编号编号本身就可以做数组下标为什么要用 map从功能上讲如果编号范围固定且连续用切片做映射确实可以比如rank : make([]int, n1)然后rank[order[i]] i下标就是编号值就是名次。这种写法在“编号从 1 到 n 且连续”的前提下没有任何问题查询效率比 map 还高一点。但实际开发里数据源不一定是连续的整数可能是任意 ID、字符串、结构体这时候数组下标映射就失效了。 map 的优势是通用性强不管键是什么类型都能建立映射关系。而且 Go 的 map 读取经过编译器优化性能在绝大多数场景下完全够用。所以我看网上很多题解直接写 map不是因为数组下标不行而是因为 map 这种“键值映射”的思维方式更容易迁移到其他复杂问题上。2.2 重排过程最容易忽略的“相等长度前提”题目虽然只给了两个数组order和friends但为了能正确重排我们需要默认len(order) len(friends)。如果两者长度不一致说明数据本身就不完整重排无从谈起。实际写代码时我建议先做一次长度校验。不要把“题目保证长度一致”当成理所当然因为真实项目中数组可能来自不同接口。加上防御性校验能让程序在数据异常时快速失败而不是给你一个莫名其妙的结果。校验方式很简单if len(order) ! len(friends) { return nil, fmt.Errorf(order 长度 %d 与 friends 长度 %d 不一致, len(order), len(friends)) }这里返回nil加 error 是 Go 常见的错误处理风格调用方可以自己决定怎么处理异常。2.3 结果数组应该新建还是原地重排重排的结果可以有两种承载方式第一种是新建一个result切片长度与friends相同然后往里面填数据。这种方式最安全不会影响原数组推荐新手使用。第二种是原地重排直接在friends上做交换。这种方式省内存但需要“交换两遍”才能避免覆盖代码容易出错稍不留神就会把某个值冲掉。具体到这道题由于我们拿到了每个元素的名次原地重排其实可以实现先扫描一遍把每个编号和它的目标位置对应起来再逐个交换。但“逐个交换”的实现细节非常容易出 bug比如一个元素被交换到正确位置之后原本在目标位置的元素又需要再次处理处理顺序一旦不对就会死循环或者数据错乱。我个人建议不是对内存极度敏感的场景一律新建切片。Go 的 GC 和切片扩容机制很成熟多一个等长切片的内存开销完全可以忽略换来的是代码逻辑简单清晰。3. 实操过程完整实现3.1 基于 map 的标准解法我把最推荐的实现写出来代码里加了必要的注释可以直接复制到本地跑package main import fmt func rearrangeByOrder(order, friends []int) []int { if len(order) ! len(friends) { panic(order 和 friends 长度不一致) } // 第一步建立编号到名次的映射 rank : make(map[int]int, len(order)) for idx, id : range order { rank[id] idx } // 第二步遍历 friends根据名次填充结果 result : make([]int, len(friends)) for _, id : range friends { pos, ok : rank[id] if !ok { panic(fmt.Sprintf(friends 中存在未在 order 中出现的元素: %d, id)) } result[pos] id } return result } func main() { order : []int{3, 1, 4, 2} friends : []int{1, 2, 3, 4} result : rearrangeByOrder(order, friends) fmt.Println(result) // [3 1 4 2] }这段代码有两个关键点值得展开说。第一rank : make(map[int]int, len(order))这一步预分配了容量。Go 的 map 在容量不足时会触发扩容扩容涉及重新哈希和搬移数据预分配可以避免掉这部分性能损耗。对于这种长度已知的数组养成预分配的习惯是好的。第二遍历friends时我用的是for _, id : range friends而不是for i : range friends。因为我们要根据id去查名次而不是根据下标去查。这是很多初学 Go 的人容易搞混的地方range循环里索引和值都要想清楚到底需要用哪个。3.2 不加 map 的排序写法以及为什么我不推荐为了对比我把排序法的实现也写出来import sort func rearrangeBySort(order, friends []int) []int { rank : make(map[int]int, len(order)) for idx, id : range order { rank[id] idx } sorted : make([]int, len(friends)) copy(sorted, friends) sort.Slice(sorted, func(i, j int) bool { return rank[sorted[i]] rank[sorted[j]] }) return sorted }这段代码逻辑上没问题能跑通但我个人不建议在算法题或性能敏感场景下用它。原因是sort.Slice的比较函数在排序过程中会被调用多次每次都通过 map 查询名次虽然 map 查询本身是 O(1)但常数因子比直接按下标访问大不少。数据规模一大这个差距会被放大。另一方面排序属于打乱了原顺序之后重新排布这在“重排”语义上不够直观。万一order本身不是全排列、或者有重复元素排序法还可能产生不稳定的结果反而更难排查问题。3.3 完整测试用例验证写算法题只跑一个用例是不够的我习惯把边界情况也覆盖掉。下面是我平时调试用的测试代码func main() { tests : []struct { name string order []int friends []int want []int }{ {基本用例, []int{3, 1, 4, 2}, []int{1, 2, 3, 4}, []int{3, 1, 4, 2}}, {逆序, []int{4, 3, 2, 1}, []int{1, 2, 3, 4}, []int{4, 3, 2, 1}}, {单元素, []int{1}, []int{1}, []int{1}}, {完全乱序, []int{5, 1, 3, 2, 4}, []int{1, 2, 3, 4, 5}, []int{5, 1, 3, 2, 4}}, } for _, tt : range tests { got : rearrangeByOrder(tt.order, tt.friends) if !equal(got, tt.want) { fmt.Printf(%s 测试失败得到 %v期望 %v\n, tt.name, got, tt.want) return } fmt.Printf(%s 测试通过%v\n, tt.name, got) } } func equal(a, b []int) bool { if len(a) ! len(b) { return false } for i : range a { if a[i] ! b[i] { return false } } return true }你可以看到上面几个用例覆盖了普通场景、全逆序、单元素、以及 5 个元素的乱序场景。单元素是很多人会忽略的边界条件但一旦数组小到只有 1 个元素任何映射和循环逻辑都要保证不出错。当然这里的friends是升序编号数组所以期望结果和order完全一样。如果你遇到的是friends不是升序编号数组的变体核心思路不变只是“期望结果”需要按照业务含义重新定义。4. 常见问题与排查技巧4.1 map 中查不到 key 导致的 panic最容易崩的地方就是rank[id]这一步。如果friends里混入了order中不存在的编号直接取值会拿到零值 0程序不会报错但结果会莫名多出来一个“0 号选手”非常难以排查。我在代码里加了ok判断这样能在问题发生的第一时间抛出 panicpos, ok : rank[id] if !ok { panic(fmt.Sprintf(friends 中存在未在 order 中出现的元素: %d, id)) }在实际工程中我更倾向于返回 error 而不是直接 panic因为数组可能来自用户输入或者第三方接口panic 会导致整个服务崩溃。但作为算法题练习panic 能让问题显而易见不必过度设计。4.2 原地重排时数据被覆盖如果你没有新建 result而是想在 friends 原数组上操作比如写成下面这样for i, id : range friends { pos : rank[id] friends[pos] id }这段代码对吗表面看好像把每个元素放到了正确位置但实际上它是一个“写覆盖”操作。假设friends[0]是 1rank[1]是 1那么它把friends[1]原本的值覆盖掉了后面处理到那个值时信息已经丢失。正确的原地交换逻辑需要把“被挤出来的元素”暂存起来再继续处理写起来要复杂得多。我平时给新人的建议就一句话先放弃原地重排新建切片即可。等你对片段的底层结构理解足够深了再考虑原地操作。4.3 切片别名与意外修改原数组Go 的切片是引用类型如果你写result : friends然后修改result[0]friends[0]也会跟着变。很多人一开始以为切片赋值是拷贝结果在函数内部改了局部变量外层的原数组也被改了调试半天才发现。解决办法是显式复制数据result : make([]int, len(friends)) copy(result, friends)或者用append的方式result : append([]int(nil), friends...)这两种写法都可以让result拥有独立的内存空间修改它不会影响friends。这道题我们本来就要重新填充所有位置所以直接make一个新的空切片填值不涉及复制原数据的问题但如果你在别的场景需要“基于原数组做修改”务必先复制一份。4.4 复杂度与性能实测我习惯在写完解法之后顺手做一次性能估算。哈希表法的时间复杂度是 O(n)需要两次遍历一次建映射一次填结果空间复杂度是 O(n)map 和 result 各占一份。如果数据量小比如几百个元素排序法和哈希表法肉眼几乎看不到差别。但当数据量来到十万、百万级别O(n log n) 和 O(n) 的差距就会非常明显。我简单做过一个 Benchmarkn 为 10 万时哈希表法通常在 10 毫秒以内排序法则要 50 到 80 毫秒差距接近一个数量级。所以如果这道题出现在面试或者竞赛里面试官期待的答案基本就是哈希表映射。排序法虽然也能 AC但显得你缺少对数据结构和复杂度的敏感度。4.5 关于 Go 语言数组和切片的一个补充提醒Go 的数组[n]int和切片[]int是两种不同的类型。数组的长度是类型的一部分[3]int和[4]int是不同的类型不能相互赋值。切片则没有固定长度限制更灵活。这道题传的一般是切片因为order和friends的长度是运行时才知道的只有切片能承载这种动态长度的数据。如果你尝试用[n]int这种数组类型编译都无法通过因为n不是常量。这个知识点虽然基础但确实是很多刚从 C 或 Python 转过来的人会搞混的地方。还有一个小细节friends如果是空切片也就是len(friends) 0的情况函数应该返回空切片而不是 nil。上面代码里make([]int, 0)会返回一个非 nil 的空切片和 nil 在 JSON 序列化、数据库写入时有微妙差别。如果你希望调用方统一处理可以在返回前判断一下长度决定返回 nil 还是空切片。5. 变体场景与扩展思考5.1 如果 friends 不是全排列怎么重排有些变体题里friends并不是 1 到 n 的全排列而是一个包含重复元素的列表。比如order : []int{3, 1, 4, 2} friends : []int{2, 2, 3, 1, 4, 3}这种情况下每个编号可能有多个相同元素不能再用“编号到名次”的一对一映射直接定位因为同一个名次会对应多个元素。处理思路是改成“稳定排序”或“按名次分组”。简单一点的做法是把friends按名次排序相同名次的元素保持原有相对顺序这其实就是排序法的用途。更工程化的做法是把元素按编号分组然后遍历order的顺序把每组元素依次填入结果数组这样既能保序又可以处理重复数据。这种变体在真实业务里很常见比如你有一批订单要按照客户的等级顺序重排同等级订单之间再按创建时间排序本质上就是“多级排序”。5.2 如何把解法推广到结构体数组实际项目中很少会用纯 int 数组更多是结构体数组。比如一个选手结构体type Player struct { ID int Name string Score int }按 ID 在order中的名次进行重排这时 map 映射依然适用只是把map[int]int的 key 换成结构体的 ID 字段然后遍历friends结构体切片按 ID 查出目标名次写到结果数组。这里要注意的是结构体切片无法直接比较所有 ID 的比较和映射都要基于具体字段。把 int 数组的解法抽象成“任意键到名次”的映射后扩展性会好很多。5.3 如果要保持稳定性排序法怎么写如果数据中有并列名次或者你想保持friends中相同编号元素的原有顺序排序法的sort.SliceStable比sort.Slice更合适。sort.SliceStable在比较结果相等时不会交换元素因此能保留原数组中的相对顺序。而sort.Slice是快排的变种不具备稳定性。但要注意sort.SliceStable的性能通常比sort.Slice差一些因为它在比较和交换中需要额外记录和维护位置信息。如果数据量不大、稳定性的需求明确用它没什么问题如果数据量大且对排序稳定没有硬性要求还是优先用哈希表映射。6. 写在最后的一些实操体会这道题我前前后后给不少新人讲过每次讲完都发现大家卡住的点不是“不会写”而是“没读懂”。order数组表达的不是“排序规则”而是“结果顺序本身”这一点一旦想明白代码基本就出来了。我自己写这类重排问题时的习惯是先画一遍映射关系哪怕是在草稿纸上随便写几个数组手动模拟一遍遍历和填充的过程。做算法题最忌讳的就是拿代码去硬试逻辑没有理顺之前写出来的代码大概率是错的调试成本反而更高。另一个体会是 Go 的切片和 map 虽然好用但底层细节还是值得花时间补一补。切片底层是数组指针、长度和容量三部分组成map 底层是哈希桶和溢出桶理解这些之后你就不会再犯“切片赋值等于拷贝”这种错误也能明白为什么预分配容量能提升性能。最后分享一个我实际调 bug 时用的小技巧在中间环节加fmt.Println打印 map 内容和填充过程中的每一步结果肉眼确认逻辑是否符合预期。虽然看起来有点“low”但面对数据量不大的算法题这比上调试器快得多。打印确认没问题后再把这些输出删掉或改为日志级别控制即可。希望这篇拆解能帮你把这个数组重排的 Go 实现彻底吃透。如果你在跑代码时还遇到其他奇怪的问题欢迎在评论区把具体的输入和输出贴出来我看到了会尽量帮你一起排查。