切片变量是值类型，但底层数据共享：赋值或传参时复制三元组（ptr, len, cap），不复制底层数组；append扩容会分配新数组，切断共享；需根据所有权语义主动控制共享。
切片变量本身是值类型，但底层数据是共享的
Go语言中[]int这类切片类型在赋值或传参时，变量本身（含len、cap和指向底层数组的指针）按值拷贝，所以它不是引用类型；但因为拷贝的是指针，多个切片可能指向同一段底层数组内存，修改元素会影响彼此——这是容易误以为它是“引用类型”的根本原因。
- 对切片变量做
a = b，只是复制了它的结构体三元组（ptr, len, cap），不复制底层数组 - 调用函数时传
func(s []int)，函数内修改s[0] = 99会反映到原切片，但s = append(s, 1)后若触发扩容，则不会影响调用方的s - 用
reflect.TypeOf([]int{})查到的是slice，而reflect.ValueOf([]int{}).Kind()返回slice，但它的底层实现是struct { array unsafe.Pointer; len int; cap int }
append导致扩容时会切断共享关系
当append操作超出当前cap，运行时会分配新底层数组、拷贝旧数据、更新切片头，此时原切片与新切片不再共用内存。这个行为常被忽略，导致预期外的数据隔离或内存泄漏。
-
s := make([]int, 2, 2); t := s; s = append(s, 3)→ 此时t仍为[0 0]，s为[0 0 3]，二者无关联 - 判断是否发生扩容：比较
len(s)和cap(s)，或用unsafe.SliceData(s) == unsafe.SliceData(t)（Go 1.20+）验证指针是否一致 - 若需强制避免共享，可用
newS := append([]int(nil), s...)做浅拷贝；注意这不是深拷贝，若元素是指针或结构体含指针，仍可能间接共享
如何安全地传递和修改切片
多数场景下无需刻意规避共享，但涉及并发写入、函数副作用或生命周期管理时，必须明确控制底层数组归属。
- 只读场景：直接传
[]T，性能好且安全 - 需保证修改不影响调用方：传
*[]T并手动检查扩容，或让函数返回新切片（更推荐） - 并发写入：不能依赖切片头的原子性，需用
sync.Mutex保护整个底层数组，或改用chan通信 - 避免意外增长：声明时用
make([]T, 0, N)预设容量，减少append中途扩容概率
用unsafe验证切片底层指针是否相同
调试或测试时，可借助unsafe包确认两个切片是否指向同一块内存，比观察值更可靠。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
package main
import (
"fmt"
"unsafe"
)
func main() {
s := []int{1, 2, 3}
t := s[1:]
fmt.Printf("s ptr: %p\n", unsafe.SliceData(s))
fmt.Printf("t ptr: %p\n", unsafe.SliceData(t)) // 输出相同地址
}
注意：unsafe.SliceData仅在Go 1.20+可用；低于该版本可用(*reflect.SliceHeader)(unsafe.Pointer(&s)).Data（不推荐用于生产代码）。
真正难处理的从来不是“怎么知道它们共享”，而是“什么时候该主动断开共享”——这取决于数据所有权语义，而非语法表象。
