Golang中sort.Sort为何用接口而非指针

在Go语言中，`sort.Sort`要求传入实现`sort.Interface`接口的值而非指针，根本原因在于该接口的`Len`、`Less`、`Swap`三个方法均定义在**值接收者**上——这使得值和指针均可满足接口，但关键在于：只有显式为自定义类型（如`type IntSlice []int`）实现这三个方法后，该类型才真正具备接口能力；而原生`[]int`或`*[]int`本身并未实现该接口，因此直接传`&mySlice`必然编译失败。这种设计兼顾了语义清晰性与性能：值接收者让切片（仅复制header）排序既安全又高效，避免强制取址的冗余和错误，同时确保接口满足性在编译期静态可验、无反射开销。理解这一点，就能避开“以为要传指针”“误对内置切片取址”等高频陷阱，写出正确、高效且符合Go惯用法的排序逻辑。

为什么 sort.Sort 要求传入接口值，而不是指针

因为 sort.Sort 的参数类型是 sort.Interface，而这个接口的三个方法（Len、Less、Swap）都定义在**值接收者**上。Go 语言规定：如果接口方法由值接收者定义，那么值和指针都能满足该接口；但如果只用指针接收者定义，就只有指针能满足。

常见错误现象：sort.Sort(&mySlice) 编译失败，报错类似 cannot use &mySlice (type *[]int) as type sort.Interface —— 这不是因为不能传指针，而是因为你传的是 *[]int，它根本没实现 sort.Interface。

• []int 本身不实现 sort.Interface，必须自己定义类型并实现三个方法
• 典型写法是 type IntSlice []int，然后给 IntSlice 实现 Len/Less/Swap
• 只要这三个方法是值接收者（如 func (s IntSlice) Len() int），那 sort.Sort(IntSlice{...}) 和 sort.Sort(&IntSlice{...}) 都合法
• 但传 &[]int 或 *IntSlice（当方法是值接收者时）反而容易误以为“要传指针”，结果类型不匹配

sort.Interface 的三个方法为什么必须是值接收者

这是为了兼容切片这种底层共享底层数组的类型。如果强制要求指针接收者，用户每次排序都要显式取地址，既啰嗦又容易出错；而值接收者在调用时会自动取地址（对切片而言，复制的是 header，不是底层数组），性能无损，语义也更自然。

使用场景：所有自定义排序逻辑，比如按结构体字段、按多条件、按映射值排序，都得靠实现这个接口。

• Len() 返回长度，不能返回 len(s) 的别名（比如 len(*s)），否则 panic
• Swap(i, j int) 必须原地交换元素，若用值接收者却试图修改副本，实际数组不会变
• 如果你不小心把 Swap 写成指针接收者，而其他两个是值接收者，整个类型就不再满足 sort.Interface

常见踩坑：传了指针，但类型没实现接口

最典型的错误是以为“排序要改原数据，所以得传指针”，于是写 sort.Sort(&myIntSlice)，但 myIntSlice 是 []int 类型，它压根没实现 sort.Interface —— Go 不会自动为内置切片类型附加方法。

错误信息示例：cannot use &myIntSlice (type *[]int) as type sort.Interface in argument to sort.Sort: *[]int does not implement sort.Interface

• 别对 []int 取地址后直接传给 sort.Sort，它不是接口实现者
• 正确做法是先定义新类型：type MySlice []int，再实现三个方法
• 如果已经用了 type MySlice []int，但方法全用指针接收者，那 sort.Sort(MySlice{...}) 就会编译失败
• Go 不会因为“你传了指针”就帮你动态绑定方法；接口满足性在编译期静态检查，跟运行时无关

动态调用？其实根本不存在

sort.Sort 看似“动态”，其实是标准的接口多态：编译器在调用前就知道具体类型实现了哪些方法，生成的是直接函数调用（不是反射、不是 interface{} 动态分发）。所谓“动态调用”是误解。

性能影响：几乎没有额外开销。底层就是三次函数调用 + 循环，和手写快排性能几乎一致。

• 不要用 reflect.Value.Call 去模拟 sort.Sort，纯属画蛇添足
• 如果你看到某段代码在运行时决定调哪个排序逻辑，那大概率是用了 switch 或函数变量，不是 sort.Sort 本身的机制
• 真正要注意的反而是：别在 Less 方法里做耗时操作（比如网络请求、磁盘读取），它会被调用 O(n log n) 次

最容易被忽略的一点：接口实现是否完整，只取决于方法签名和接收者类型，和变量怎么声明、怎么传入完全无关。写对了类型定义和方法，剩下的只是语法糖。

理论要掌握，实操不能落！以上关于《Golang中sort.Sort为何用接口而非指针》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！