因为切片是包含ptr、len、cap的结构体，传参时拷贝该结构体，其中ptr仍指向原底层数组，故swap等操作能修改原始元素；append扩容会改变ptr，断开共享。
为什么 sort.Interface 的 Swap 能改到外面的切片？
因为切片本身不是指针，但它的值里“自带指针”——它是一个三字段结构体（ptr、len、cap），传参时拷贝的是这个结构体，而其中的 ptr 指向的仍是同一块底层数组内存。
- 只要没触发
append扩容，所有共享该底层数组的切片，改任意一个的元素，其他都能看到 -
sort.Ints、sort.Slice内部调用的Swap和Less都是值接收器，但照样能交换原始切片里的元素 - 这不是“引用传递”，而是“带指针的值传递”——Go 官方叫它“reference type”，但别被名字骗了，变量本身仍是值拷贝
哪些操作会断开底层数组共享？
一旦底层数组发生扩容，指针就变了，原来的共享关系就断了。最典型的就是 append 超过 cap 时。
-
s := []int{1,2}; t := s[0:1]→t和s共享底层数组 -
s = append(s, 3, 4, 5)→ 极大概率触发扩容，s.ptr指向新地址，t还指着旧数组 - 此时改
s[0]不再影响t[0]；但改t[0]仍会影响原数组中对应位置（除非原数组已被 GC） - 判断是否扩容：比较
len(s)和cap(s)，或用unsafe.SliceData（Go 1.20+）看指针是否变化
怎么安全地“复制一份不共享”的切片？
想彻底隔离修改，就得让新切片指向新内存，不能只靠截取或赋值。
- 最常用且语义清晰：
safe := append([]int{}, original...) - 显式控制长度和容量：
safe := make([]int, len(original)); copy(safe, original) - 对嵌套切片（比如
[]*Rule中的Rule.Right）要逐层深拷：光拷外层切片没用，Rule.Right仍可能被意外改 - 别用
new([]int)或&[]int{}—— 这些得到的是切片指针，不是新底层数组
结构体里存切片，为什么传参后字段被悄悄改了？
这是最容易踩的坑：结构体按值传递，但结构体里的切片字段，其 ptr 字段仍指向原底层数组。
立即学习“go语言免费学习笔记（深入）”；
-
type QRS struct { three []string }，q := QRS{three: rule.Right}→q.three和rule.Right共享底层数组 - 如果后续函数对
q.three做了append或直接赋值（如q.three[0] = "x"），rule.Right[0]就跟着变 - 修复方式不是加
*QRS，而是初始化时就做深拷：three: append([]string{}, rule.Right...) - 尤其注意 JSON 解析、模板渲染、中间件透传等场景——看似只是读，实则可能触发隐式修改
切片的“非指针却能改外面”本质，是头结构体里那个 ptr 字段在起作用。真正危险的从来不是语法，而是你忘了它什么时候还连着、什么时候已经断开了。
