sort.Sort要求传入接口值而非指针，因为sort.Interface的Len、Less、Swap方法均定义在值接收者上；只要自定义类型（如IntSlice []int）以值接收者实现这三方法，传值或传指针均可，但[]int本身未实现该接口，故不能直接传&[]int。
为什么 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，不是底层数组），性能无损，语义也更自然。
使用场景：所有自定义排序逻辑，比如按结构体字段、按多条件、按映射值排序，都得靠实现这个接口。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
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) 次
最容易被忽略的一点：接口实现是否完整，只取决于方法签名和接收者类型，和变量怎么声明、怎么传入完全无关。写对了类型定义和方法，剩下的只是语法糖。
