因为子切片与原切片共享底层数组，修改子切片会改变原切片；需用copy或slices.Clone隔离，append不赋值则丢失元素，且扩容时机取决于cap而非代码逻辑。
为什么修改子切片会悄悄改掉原切片
因为 s[i:j] 不创建新数组，只新建一个切片头，data 字段仍指向原底层数组起始位置。只要没扩容，所有基于同一数组的切片都共享内存。
常见错误现象：解析日志时用 lines := bytes.Split(buf, '\n') 得到多个 []byte，随后对某个子切片做 sub[0] = 'X'，结果 buf 里对应位置也被改了。
- 判断是否共享：打印
uintptr(unsafe.Pointer(&s[0]))（仅调试用）或直接看cap(s)是否大于len(s)—— 容量有富余，大概率还在原数组上 - 截取后想隔离：用
make([]T, len(src)); copy(dst, src)或 Go 1.21+ 的slices.Clone(src) - 不要依赖
append来“保护”原切片 —— 它可能不扩容，也可能扩容，行为由当前cap决定，不是由代码写法决定
append 后原切片没变？不是 bug，是值传递的必然结果
append 返回新切片，但不会自动更新调用方变量。Go 对切片是值传递，函数内拿到的是 sliceheader 的副本，哪怕 data 指针相同，赋值操作也只改局部副本。
使用场景：封装日志累积、错误收集、HTTP 响应体拼接等需要动态增长的逻辑。
立即学习“go语言免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 错误写法：
append(s, x)没赋值 → 新元素彻底丢失 - 正确写法：
s = append(s, x)，必须显式重赋值 - 函数内需返回：
func extend(s []int, x int) []int { return append(s, x) }，调用方负责s = extend(s, x) - 传指针（如
*[]int）虽可行，但违背 Go 惯用法，且容易漏解引用，不推荐
扩容时机完全取决于 cap，不是 len 或代码行数
是否触发扩容，只看 len(s) + 新增元素个数 是否成立。不满足就分配新数组、拷贝、返回；满足就原地写入，覆盖底层数组空闲位置。
性能影响：频繁扩容带来拷贝开销；更危险的是——你以为在往原数组追加，其实某次 append 后指针已切换，后续修改再不影响原切片，逻辑断裂。
- 示例：
s := []int{1,2,3}（len=3, cap=3），s = append(s, 4)必扩容；但s := make([]int, 2, 5)，再append(s, 4)就只是改第 2 个位置，不换底层数组 - 预分配技巧：
make([]T, 0, estimatedCap)可减少意外断连，尤其适合已知大致长度的场景（如批量读 DB） - 调试时可加断言：
if len(s) == cap(s) { log.Println("next append will reallocate") }
copy 函数不共享、不扩容，但长度控制复制数量
copy(dst, src) 是元素级复制，dst 和 src 完全独立，无论是否同源、是否扩容，都不会相互干扰。但它复制的数量由 len(dst) 决定，不是 len(src)。
容易踩的坑：把 copy(dst[:n], src) 写成 copy(dst, src[:n])，结果 dst 被填满，src 却只取了前 n 个 —— 方向反了，语义完全不同。
-
copy(a, b)复制min(len(a), len(b))个元素 - 目标切片长度太小？数据被截断，无 panic，也不报错
- 想深拷贝整个 src：先
dst := make([]T, len(src))，再copy(dst, src) - 和
append组合用要小心：dst = append(dst[:0], src...)看似清空再追加，但如果cap(dst) >= len(src)，仍可能复用底层数组
append 可能维持共享，下一次就断开，而断开点由运行时容量状态决定，无法仅从代码静态判断。 
