切片是值类型但底层数据共享：赋值复制结构（含指针、长度、容量），指针指向同一底层数组；修改元素影响其他切片，append扩容可能更换底层数组。
切片本身是值类型，但底层数据是共享的
Go 中 []int 这类切片变量本身是**值类型**——赋值或传参时会复制其结构（指针、长度、容量），但这个结构里存的指针指向的是底层数组。所以多个切片可能共用同一段内存。
这意味着：
• 修改某个切片的元素（如 s[0] = 99）会影响其他指向同一底层数组的切片；
• 但对切片变量重新赋值（如 s = append(s, 1)）可能触发扩容，导致底层数组更换，后续修改就不再影响原切片。
常见错误现象：
• 在函数内 append 后没返回新切片，调用方看不到新增元素；
• 以为“传切片就是传引用”，结果发现函数内重赋值（s = []int{1,2}）不影响外部变量。
函数参数传递：不是引用传递，而是“带指针的值传递”
Go 没有引用传递（如 C++ 的 &T 或 Java 的对象引用语义）。所有参数都是值传递，切片也不例外。只是它的值里包含一个指向底层数组的指针。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
• 若需在函数中修改底层数组内容（如翻转、填充），直接传切片即可，无需加 *；
• 若需改变切片头（长度/容量）且让调用方感知（比如追加后要延续使用），函数必须返回新切片，并由调用方显式接收；
• 真正需要“修改切片头并影响调用方”的场景，才考虑传 *[]T（指针到切片），但极少必要，容易过度设计。
示例对比：
func modifyContent(s []int) { s[0] = 999 } // ✅ 外部 s[0] 变了<br>func tryExtend(s []int) { s = append(s, 1) } // ❌ 外部 s 不变，因为 s 被重新赋值了<br>func extendAndReturn(s []int) []int { return append(s, 1) } // ✅ 正确做法
和数组、map、channel 的行为对比
切片常被拿来和其它类型对比，混淆点就在这里：
-
[3]int是纯值类型：传参时整个数组拷贝，改它不影响原数组； -
map和chan行为类似切片：变量本身是轻量结构（含指针），传参不复制底层数据，增删改都反映到原值； - 但
map和chan是引用语义的“伪装者”——它们的底层结构不可寻址、不可扩容，而切片的底层数组可能被替换（append扩容时）。
性能提示：
• 切片扩容（尤其是反复 append 未预估容量）会频繁分配新底层数组、拷贝旧数据，造成 GC 压力；
• 如果明确知道最终长度，优先用 make([]T, 0, n) 预分配容量。
判断两个切片是否共享底层数组？
没有内置函数直接判断，但可通过反射或 unsafe（不推荐）获取底层数组地址。更安全实用的做法是：用 reflect.ValueOf(s).UnsafeAddr()（仅限 slice header 里的 Data 字段）——但要注意这属于非安全操作，生产环境慎用。
实际开发中，更推荐逻辑上控制：避免依赖“是否共享”，而是明确谁拥有数据所有权；若需隔离，用 copy(dst, src) 显式复制一份；若需确保独立，可 append([]T(nil), s...) 创建新底层数组。
容易被忽略的一点：即使两个切片长度不同、起始索引不同，只要它们的 cap 足够大且原始底层数组相同，仍可能意外共享内存——这是并发读写 panic 的常见根源（fatal error: concurrent map writes 类似，但切片无自动保护）。
