修改切片元素会改变原切片，因其结构体虽值传递，但array字段是指向底层数组的指针；函数内s[0]=100、copy、json.Unmarshal等操作均直接写入原始底层数组。
修改切片元素会改变原切片
会。因为 slice 是值传递的结构体，但其 array 字段是指向底层数组的指针。函数内执行 s[0] = 100、copy(s, src) 或遍历赋值等操作，都直接写入原始底层数组。
常见错误现象：传入一个 []byte 做加解密或 JSON 解析后，原始 buffer 内容被覆写；日志模块和加密模块共用同一份切片，结果日志输出的是密文残留。
使用场景：当你只需要“改内容”（如填充、翻转、序列化写入），且调用方不再读/写该切片时，这种共享是高效且安全的。
- ✅ 安全前提：确认调用方后续不依赖原切片内容
- ⚠️ 风险点：多个 goroutine 同时读写同一传入切片 → 数据竞争（锁不住底层数组）
- ? 检查方式：看函数是否含
s[i] =、copy、json.Unmarshal、encoding/binary.Read等写入操作
append 后不接收返回值不会改变原变量，但可能污染底层数组
不会改变原 slice 变量的 len/cap/array 字段，但极大概率会复用原底层数组空间，导致后续对原 slice 的读写出现脏数据。
立即学习“go语言免费学习笔记（深入）”；
典型表现：removeFrom(s, 0) 返回新 slice，但你没接：removeFrom(s, 0)（丢弃返回值），接着又用 s[:0] 或循环写入，输出变成 [40 50 50 50 50] —— 这是底层数组被反复覆盖的信号。
原因：append 在容量足够时不分配新数组，而是就地拼接；原 slice 变量仍指向旧头，但内存已被改写。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- ✅ 正确做法：始终接收并赋值，
s = append(s[:i], s[i+1:]...) - ❌ 错误示范：
append(s[:i], s[i+1:]...)单独调用（返回值丢失） - ? 性能提示：频繁
append且未预估cap，会触发多次底层数组拷贝，增加 GC 压力
需要隔离传入切片时，选哪种拷贝方式？
目标只有一个：让函数内部所有写操作都不碰原始底层数组。选法取决于类型、Go 版本和性能敏感度。
append([]T{}, s)：通用、简洁，Go 1.22 前最常用；对 []byte 开销小，但每次触发一次小堆分配。
bytes.Clone(s)：仅限 []byte，Go 1.20+ 推荐；零分配、语义明确，底层走 runtime.clone 优化。
dst := make([]T, len(s)); copy(dst, s)：控制力最强，适合高频路径；注意 make 的容量必须 ≥ len(s)，否则 copy 不会填满。
- ❌ 危险写法：
make([]T, 0, cap(s))→ 创建空切片，跟原s完全无关，没解决隔离问题 - ⚠️ 并发场景：必须在起 goroutine 前完成隔离，传
append([]byte{}, s[i:j])，而非s[i:j] - ? 判断是否要隔离：上游是否还持有该切片？是否多处并发使用？文档是否标注 “modifies input”？
什么时候才该传 *[]T？
极少需要。传 *[]T 是为了在函数内替换整个 slice 头（比如把 s 指向一个全新底层数组），同时让调用方变量也更新 —— 这属于主动破坏封装，容易引发理解混乱和维护困难。
真实需求往往是：想扩容后延续使用、或统一管理生命周期。这两种情况，返回新 slice + 调用方显式赋值更清晰、更符合 Go 习惯。
- ✅ 推荐模式：
s = myFunc(s)，函数签名func myFunc(s []T) []T - ❌ 过度设计：
myFunc(&s)，函数签名func myFunc(s *[]T)，除非你在写类似sync.Pool的底层工具 - ⚠️ 容易被忽略的点：即使传了
*[]T，函数内仍要手动处理底层数组共享问题（比如append后没赋值给*s，照样污染原数组）
