go 1.4 虽引入栈扩容机制，但大数组（如 [8096]int）放在函数内仍是推荐做法；栈分配通常比堆更快，而全局声明会污染命名空间、破坏封装性，语义错误远比潜在的栈复制开销更值得警惕。
在 Go 中，是否因“栈复制”而刻意将大变量移出函数体（例如改为包级变量），是一个常见但被误解的优化误区。实际上，Go 编译器会根据变量逃逸分析（escape analysis）自动决定其分配位置——无论你写成局部数组还是包级变量，只要该变量的实际使用范围局限于函数内，编译器通常仍将其分配在栈上；反之，若它被返回、取地址并传入可能长期存活的上下文，就会逃逸到堆。
以你的两个例子为例：
func foo() {
var buf [8096]int // ✅ 推荐：作用域明确、生命周期可控、无副作用
// do something with buf
}var buf [8096]int // ❌ 不推荐：全局变量，破坏封装，线程不安全（并发调用时共享同一份内存）
func foo() {
// do something with buf —— 多个 goroutine 同时调用会相互覆盖！
}⚠️ 关键注意事项：
- 栈复制不是性能瓶颈：Go 的栈扩容采用“复制旧栈 + 调整指针”的方式，仅在首次扩容时发生，且现代 CPU 缓存友好；对 [8096]int（约 64KB）这类大小，绝大多数场景下不会触发扩容（默认初始栈为 2KB，但编译器会为大栈帧预留足够空间或直接分配更大初始栈）。
- 全局变量危害远大于栈开销：包级数组 buf 是全局可访问、可修改的，不仅导致命名空间污染，更引发严重并发风险——多个 goroutine 同时调用 foo() 将竞争同一内存区域，造成数据错乱。
- 语义与设计原则优先：Go 强调“显式优于隐式”和“最小作用域原则”。变量应在最窄的作用域内声明，既提升可读性，也便于编译器优化与垃圾回收（尽管栈变量无需 GC，但逻辑清晰性直接影响维护成本）。
✅ 正确做法是：保持变量局部化，并借助 go tool compile -gcflags="-m" 检查逃逸行为。例如：
go tool compile -m -l main.go # 输出类似：main.foo &buf does not escape → 确认未逃逸，安全驻留栈上
总结：不必为规避栈复制而牺牲代码语义与安全性。优先保证作用域最小化、避免全局状态；性能疑虑应以实测和逃逸分析为依据，而非过早臆断。真正的优化点往往在算法、IO 或并发模型，而非手动“挪动”数组位置。
