根本原因是append返回新切片头，是否影响原切片取决于是否触发底层数组扩容：未扩容时指针不变，修改可见；扩容后返回新数组指针，不接收返回值则上游仍指向旧数组。
切片传参后修改不生效，或意外影响上游数据，根本原因不是“引用/值传递”二分法，而是你没看清 append 是否触发了底层数组扩容。
为什么函数里 append 有时改不到原切片？
因为 append 返回的是新切片头——它可能指向新底层数组，也可能仍指向旧数组。调用方若没接收返回值，就等于丢弃了这个新头。
- 如果原切片
len(s) ，<code>append直接写入底层数组，指针不变；此时即使不接收返回值，上游切片看到的元素也会变（比如改s[0]） - 但一旦触发扩容（
len(s) == cap(s)），append分配新数组、拷贝、返回新头；若函数没把返回值赋给参数变量，上游切片仍指向旧数组，完全看不到新增元素 - 典型场景：递归 DFS 中的
path参数，每次append后不重新赋值path = append(path, x)，回溯时就会错乱
三参数截取 s[i:j:k] 怎么防越界写入？
默认截取 s[i:j] 的 cap 是 cap(s) - i，下游 append 可能悄悄写到原切片其他字段后面，引发静默污染。用三参数形式可锁死容量。
-
s[1:3]的cap可能是 9，而s[1:3:3]的cap强制为3 - 1 = 2，后续append必然扩容，不会复用原底层数组剩余空间 - 适合做“只读视图”或结构体字段：比如
type Request struct { body []byte }，接收 HTTP body 后用r.body = r.body[:n:n]封住容量，防止后续误append覆盖解析出的 header - 注意：
k不能超过原切片的cap(s)，否则 panic: "slice bounds out of range"
如何判断两个切片是否共享底层数组？
不能比 &s[0] ——那只是首元素地址，不同切片首元素可能相邻但数组不同。得比底层数组起始地址。
- 安全方式：
reflect.ValueOf(s).UnsafeAddr()，前提是s非 nil 且长度 > 0 - 更稳妥（无需 reflect）：
unsafe.Slice(&s[0], len(s))得到一个新切片，再用reflect.ValueOf().Pointer()取其底层数组地址 - 调试时快速验证：修改
s1某个元素，看s2对应位置是否同步变化；但生产环境别依赖这种行为 - 常见陷阱：从
bytes.Buffer.Bytes()拿到的切片，Buffer内部可能复用底层数组，下次Write就可能覆盖你缓存的数据
最易被忽略的点：cap 不是“还能塞几个”，而是“从 s[0] 开始到底层数组末尾有多少个”。截取操作会大幅压缩它，而多数人只盯着 len 看。传参前若不确定容量是否足够，要么预分配，要么用 append([]T(nil), s...) 强制深拷贝——别指望“传引用就安全”。
