go 切片本身是轻量级描述符（含指针、长度、容量），按值传递开销极小，无需为性能而改用全局变量或指针；实测表明二者性能几乎无差异，且参数化设计更利于可读性、可测试性和编译器优化。
go 切片本身是轻量级描述符（含指针、长度、容量），按值传递开销极小，无需为性能而改用全局变量或指针；实测表明二者性能几乎无差异，且参数化设计更利于可读性、可测试性和编译器优化。
在 Go 开发中，一个常见误区是认为“避免传参 = 提升性能”，尤其当某个数据（如 []string 类型的排除模式列表）在多次调用中保持不变时，开发者容易考虑将其提升为全局变量以“节省复制开销”。但这种优化不仅通常无效，还可能损害代码质量。
切片传递的本质：高效且安全
Go 中所有参数均按值传递，但切片（[]T）本身不是底层数组，而是一个三字段运行时描述符：
type slice struct {
array unsafe.Pointer // 指向底层数组首地址
len int // 当前长度
cap int // 容量
}无论其底层数组包含 10 个还是 100 万个元素，传递切片仅复制这 24 字节（64 位系统下）的结构体。底层数组内存不会被复制，也不存在“写时复制（Copy-on-Write）”机制——Go 的切片共享底层数组是设计使然，而非延迟复制策略。
因此，以下两种写法在性能和内存行为上完全等价：
func checkFiles(path string, excluded []string) { /* 使用 excluded */ }
// vs
var globalExcluded = []string{"tmp/", ".git/", "node_modules/"}
func checkFiles(path string) { /* 使用 globalExcluded */ }为什么不应滥用全局变量？
- 可测试性受损：全局变量使函数依赖外部状态，单元测试需手动重置或 mock，增加脆弱性；
- 并发不安全：若未来逻辑演变为修改该切片（如动态追加规则），全局变量将引发竞态，而参数化天然隔离；
- 可读性下降：调用方无法从函数签名得知其行为依赖哪些外部数据，违反显式契约原则；
- 编译器优化受限：现代 Go 编译器（如 SSA 后端）对局部参数有更强的寄存器分配和缓存优化能力；全局变量因可能被其他 goroutine 修改，常需额外内存屏障或重加载。
实证：基准测试打消疑虑
以下简化版基准测试（保存为 slices_test.go）直接对比参数传入与全局访问：
package main
import "testing"
var gslice = make([]string, 1000)
func global(s string) {
for i := 0; i < 100; i++ {
_ = s
_ = gslice // 访问全局切片
}
}
func param(s string, ss []string) {
for i := 0; i < 100; i++ {
_ = s
_ = ss // 访问参数切片
}
}
func BenchmarkParameter(b *testing.B) {
for i := 0; i < b.N; i++ {
param("hi", gslice)
}
}
func BenchmarkGlobal(b *testing.B) {
for i := 0; i < b.N; i++ {
global("hi")
}
}运行 go test -bench . 典型输出：
BenchmarkParameter-8 30000000 55.2 ns/op BenchmarkGlobal-8 30000000 55.0 ns/op
两者耗时几乎一致，差异在测量噪声范围内——证明过早优化全局化毫无收益。
正确实践建议
- ✅ 优先使用参数传递：保持函数纯度、提升可组合性与可测试性；
- ❌ 避免仅为性能提升为全局变量：除非该数据 truly 全局且生命周期贯穿整个程序（如配置常量）；
- ⚠️ *仅当需修改切片头（len/cap）时才传 `[]T**：例如函数内要append` 并希望调用方看到新长度——但这属于语义需求，非性能驱动；
- ? 真有性能瓶颈？用 pprof 定位：文件 I/O、正则匹配、磁盘寻道等操作耗时通常是切片传参的 10⁴–10⁶ 倍，优化此处毫无意义。
总结：Go 的切片设计已高度优化，开发者应信任语言机制，聚焦于清晰的接口设计和正确的抽象层次，而非微观层面的“零拷贝幻想”。
