传切片开销小但需防底层数组共享；大容量切片传参时若内部频繁append或截取，可能使调用方意外看到修改。
传参时别直接传大切片，用指针或切片头结构
Go 函数参数传递是值拷贝，但 []T 本身只含三个字段（ptr/len/cap），所以传切片开销极小——真正的问题在于：你传进去后，函数内部若频繁 append 或截取，可能意外共享底层数组，导致调用方看到未预期的修改。更隐蔽的风险是，大容量切片（比如 make([]byte, 0, 100）虽没数据，但 cap 占内存，传参本身不耗资源，但后续操作容易触发扩容或泄漏。
实操建议：
- 如果函数只读、不改长度或内容，直接传
[]T即可，零成本 - 如果函数要重用底层数组（如批量解析日志行），传入后立刻用
s = s[:0]清空长度，再复用 - 如果必须隔离修改（比如加工后返回新切片，且不能影响原数组），别依赖
append，先make目标容量，再copy - 极端场景（如处理 GB 级缓冲区且生命周期长），考虑传
*[]T指针，但仅限需要动态替换整个切片头（ptr/len/cap）时，日常几乎不用
避免在循环里反复 append 到同一变量
这是最常被忽略的性能陷阱：for _, x := range src { dst = append(dst, transform(x)) } 看似自然，但如果 dst 初始化为 []T{}，每次 append 都可能触发扩容，尤其当 src 元素数不确定时，底层数组会多次 realloc + copy，GC 压力陡增。
正确做法取决于你是否知道目标大小：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 已知最终长度（如解析固定行数 CSV）：用
dst := make([]T, len(src))，然后索引赋值dst[i] = transform(src[i]) - 长度可预估（如日志按块切分，每块约 1MB）：用
dst := make([]T, 0, estimatedCap)，再append - 完全不可预估：接受扩容代价，但至少把
dst提前声明在循环外，避免重复初始化
删除或过滤元素时，用 s[:0] 复用底层数组
比如从 100 万条记录中筛出状态为 active 的项，写成 filtered := make([]T, 0) 再 append，会额外分配内存；而用 filtered := origin[:0] 开头，就能复用 origin 的底层数组，只要最终长度 ≤ 原容量，就零新分配。
注意边界：
-
origin[:0]是安全的，即使origin是nil（nil[:0]合法） - 后续
append(filtered, ...)若超出原 cap，仍会扩容，但至少省掉第一次分配 - 别在同一个切片上边遍历边
append到自己（如for i := range s { if cond(s[i]) { s = append(s, s[i]) } }），这会导致读取脏数据或 panic
并发读写大切片必须加锁或换数据流模型
切片不是线程安全的。多个 goroutine 同时调用 append、修改同一索引、或执行 s = s[:n]，会引发 data race。go run -race 很容易暴露，但线上可能静默错乱。
选哪种方案，看访问模式：
- 读多写少：用
sync.RWMutex，读用RLock，写用Lock - 写是追加为主：考虑
chan []T传递所有权，让单个 goroutine 负责该切片的全部修改 - 高频写+需低延迟：放弃共享切片，改用
sync.Pool缓存预分配的切片对象，每个 goroutine 自取自还 - 绝对不要：只对切片长度加
atomic，因为append可能改 ptr 和 cap，原子操作无法覆盖
真正麻烦的不是“怎么写”，而是“什么时候意识到它在共享底层数组”——一次 s[100:200] 截取，可能让两个逻辑无关的模块悄悄共用同一片内存。查这类 bug，得盯紧 len 和 cap 的变化，而不是只看 len。
