go中[]t传参是切片头部结构复制+底层数组共享，修改元素（如s[i]=x）会影响原slice因array字段指向同一内存；append若扩容则新数组不共享，且s=append(s,x)不返回则调用方无变化。
Go 里 []T 传参既不是纯值传递，也不是纯引用传递，而是「切片头部结构复制 + 底层数组共享」——这决定了哪些修改能透出、哪些不能。
修改元素（如 s[i] = x）为什么会影响原 slice
因为所有 slice 变量的 array 字段都指向同一块内存地址（只要没扩容），len 和 cap 只控制可访问范围。所以直接通过索引赋值，就是往原底层数组写数据。
- 即使函数内
s是参数副本，&s[0]和调用方&original[0]打印出来地址一致 - 这种行为和
map、chan类似：结构体轻量拷贝，但底层资源共用 - 注意：若原 slice 已被
append触发扩容，后续再传入的 slice 可能已指向新数组，此时修改不再影响“最初那个”
append 后不返回会导致调用方看不到变化
append 是否分配新数组，取决于当前 cap 是否足够。无论是否扩容，它返回的是一个**新头部结构**，而原参数变量仍指向旧头部。
- 常见错误：
s = append(s, x)写在函数里，但没return s，调用方的 slicelen和cap完全不变 - 扩容判断逻辑：若
len(s)+1 ，则复用底层数组；否则 malloc 新数组并 copy - 调试技巧：打印
cap(s)和&s[0]，对比前后是否变化，就能确认是否发生了底层数组迁移
想安全隔离数据时，必须显式 copy 或 make + copy
多个 slice 共享底层数组是常态，但有时你恰恰需要“断开连接”。不能靠传指针（*[]T），那只会让头部结构也共享，反而更难控制。
- 正确做法：用
copy到新分配的底层数组，例如newS := make([]int, len(s)); copy(newS, s) - 避免踩坑：
newS := s[:len(s):len(s)]这种“三索引切片”只是限制cap，底层数组仍共享 - 如果函数要返回独立副本，就别试图修改入参，直接
return append([]T(nil), s...)或copy方式构造
最易被忽略的点：底层数组共享不是 bug，是设计；但它的边界很模糊——append 是否扩容、s[i] 是否越界、copy 是否越界，都会让共享关系突然断裂或意外延续。写函数时，永远要问自己一句：这个 slice 的 ptr 在这一行之后还指向原来那块内存吗？
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
