切片是三字宽的值类型结构体，包含array、len、cap字段；传参赋值直接拷贝这三字段，不涉及指针解引用；修改元素影响底层数组，但append扩容后指向新数组则原变量不受影响。
切片不是指针，是三字宽的值类型结构体
Go 中的 slice 常被误认为“类似 C 的指针数组”，但它的底层就是一个纯值：三个机器字长的结构体——array（unsafe.Pointer）、len、cap。传参、赋值、截取操作都直接拷贝这三个字段，不涉及指针解引用或间接寻址。
- 这意味着
s1 := s2[1:3]不分配新内存，只是构造一个新的结构体，指向同一底层数组的偏移位置 - 函数接收
slice参数时，修改其元素（如s[0] = 10）会影响原底层数组；但若在函数内做s = append(s, x)并超出cap，就可能扩容并指向新数组，此时原变量不受影响 - 用
reflect.TypeOf(s).Kind()可验证它是reflect.Slice，但reflect.ValueOf(s).CanAddr()是false——它本身不可取地址，因为它是值，不是变量别名
为什么 append 有时改原切片，有时不改？
关键看是否触发扩容：append 只有在 len(s) 时复用底层数组；一旦 <code>len == cap，就会调用 growslice 分配新数组、拷贝数据、返回新切片头。
- 常见错误现象：
func add(s []int) { s = append(s, 99) }调用后原切片不变——因为扩容后新切片头未返回，旧变量仍指向原地址 - 正确做法：必须显式返回，
func add(s []int) []int { return append(s, 99) } - 性能影响：频繁小量
append（尤其未预估cap）会引发多次内存分配和拷贝；建议用make([]T, 0, expectedCap)预分配
截取切片时，cap 怎么算？容易踩的共享坑
s[i:j] 的 cap 不是原切片的 cap，而是 cap(s) - i（即从新起始位置到底层数组末尾的长度）。这决定了后续 append 的安全边界。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 典型陷阱：
a := [5]int{0,1,2,3,4}; s := a[1:3]; t := s[0:2]; t = append(t, 99)—— 此时t和s共享底层数组，s的第二个元素（原a[2]）会被悄悄覆盖为99 - 避免意外共享：需深拷贝时用
copy(dst, src)，不要依赖截取；敏感场景（如解析网络包、多 goroutine 写入）建议立即copy到独立底层数组 -
s[:0]清空切片但保留容量，适合循环复用；s = s[:0]比s = nil更省内存（不触发 GC 回收底层数组）
怎么判断两个切片是否共享底层数组？
Go 标准库没提供直接判断函数，但可通过反射或 unsafe 对比 array 字段地址实现，不过生产环境慎用 unsafe。更实用的是逻辑规避：
立即学习“go语言免费学习笔记（深入）”；
- 使用
reflect.ValueOf(s).UnsafeAddr()仅对底层数组首元素有效，且要求切片非空；空切片（len=0）的array指针可能是 nil 或任意地址，不可靠 - 真正需要隔离时，统一走
dst := make([]T, len(src)); copy(dst, src)，明确语义，不依赖底层细节 - 调试阶段可用
fmt.Printf("%p", &s[0])（要求len(s)>0）粗略比对地址，但注意 panic 风险（空切片取&s[0]会 panic）
底层数组的生命周期由所有引用它的切片共同决定，哪怕只剩一个未被 GC 的切片，整个底层数组就无法回收——这点在长期运行的服务中，容易因无意保留长切片而造成内存泄漏。
