go的append不修改原切片，因其值传递三字段结构体并总返回新切片；是否共享底层数组严格取决于len+新增数≤cap，扩容与否由当前容量唯一决定，必须赋值s=append(s,x)才生效。
Go 的 append 不会修改原切片变量，它返回一个新切片值；是否共享底层数组，只取决于当前 cap 是否足够容纳新增元素——不是“有时共享、有时不”，而是“每次调用都严格按容量判断”。
为什么 append(s, x) 后 s 没变？
因为 append 返回的是一个新的切片结构体（含新的 len，可能指向新或旧数组），而 Go 是值传递：传入的是 s 这个三字段结构体的副本。函数内部或表达式中不赋值，原变量就永远停在旧状态。
-
s = append(s, x)是必须写的，不是可选习惯 - 写成
append(s, x)单独一行，等同于什么都没做 - 用
fmt.Printf("%p", s)打印的是底层数组地址，不是切片变量地址；别靠这个判断“有没有扩容”
什么时候会意外覆盖数据？
典型场景是多个 append 共享同一个低容量切片，且都没更新变量本身。例如：
common := make([]int, 0, 4) a := append(common, 1) b := append(common, 2) // 这里直接复用 common 的底层数组，从索引 0 开始写！
结果 a 和 b 都看到 [2]，因为 b 覆盖了 common 底层数组第一个位置。
- 只要
len + 新元素数 ≤ cap，append就原地写入，不管之前有没有 append 过 - 多个子切片（如
s[2:4],s[3:5]）共用底层数组时，改一个会影响另一个 - HTTP body 解析后取
body[8:16]存进 context，会“钉住”整个几 MB 的原始[]byte
如何安全提取或复制一段 slice？
目标是切断与原底层数组的指针关联，避免 GC 拖累或意外修改。
- 通用方案：
newS := append([]T(nil), oldS...)—— 利用nil切片强制分配新数组 - Go 1.21+ 推荐：
newS := slices.Clone(oldS)（slices在golang.org/x/exp/slices，1.21 后进标准库） - 仅限
[]byte：newB := bytes.Clone(oldB)（Go 1.20+） - 性能敏感路径：
dst := make([]T, len(src)); copy(dst, src)—— 避免append内部的额外判断开销
扩容不是安全开关，cap 才是唯一依据
有人误以为“append 过一次就断连了”，其实完全错误。关键永远是当前切片的 cap 和你要追加的元素总数。
-
make([]int, 3, 8)→append(s, 1)仍复用原数组，s[0] = 99会立刻反映在新切片上 -
make([]int, 3)（即 cap=3）→append(s, 1)必扩容，新切片独立 - 不要依赖“看起来扩容过”，每次调用
append前都要检查cap(s) - len(s) >= n
最常被忽略的一点：len 和 cap 是两个独立控制的字段。你看到 cap=10，不代表这 10 个位置都“归你管”——它只说明底层数组还有多长，不提供任何安全边界或写保护。
