Go全局变量默认分配在堆上，由GC统一管理，生命周期贯穿程序始终，无法强制置于栈或数据段，验证方式包括内存统计、pprof或逃逸分析中的“global variable”标识。
Go 全局变量默认就在堆上，不需要额外操作
go 语言中所有全局变量（即包级变量）在程序启动时就被分配在堆上，由 go 的垃圾回收器管理。这不是可选行为，而是运行时的硬性设计——go tool compile 会直接将它们标记为需要堆分配，哪怕类型是 int 或 struct{} 这样的小值类型。
常见误解是“栈更快，所以全局变量可能在栈上”，但 Go 规定：栈只用于函数局部变量，且生命周期必须能被编译器静态推断；全局变量生命周期贯穿整个程序，只能在堆。
如何验证全局变量确实在堆上
最直接的方式是用 runtime.ReadMemStats 对比变量初始化前后的堆分配变化，或用 pprof 查看堆对象分布。更轻量的方法是观察逃逸分析结果：
package main
var g int = 42 // 全局变量
func main() {
println(&g) // 打印地址，每次运行都不同，且地址范围属于 heap（如 0xc000010230）
}
运行 go build -gcflags="-m -l" main.go，你会看到类似输出：main.g &g does not escape —— 注意这里“does not escape”不是说它在栈上，而是说它没从当前作用域“逃逸出去”，因为本来就在包级作用域，压根不参与局部逃逸分析。真正关键的提示藏在编译器日志里：global variable 字样明确标识其分配位置。
为什么不能把全局变量强制放到栈或数据段
Go 不提供类似 C 的 static、__attribute__((section)) 或链接器脚本控制方式。原因很实际：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- GC 需要统一扫描所有活动堆对象，全局变量必须纳入这个图谱
- 支持动态加载包（如
plugin）时，全局变量地址需可重定位，数据段固定地址不满足 - 并发安全要求：全局变量可能被任意 goroutine 访问，堆分配配合写屏障才能保证内存可见性
试图用 unsafe 指针绕过或伪造栈地址，会导致 GC 漏扫、崩溃或静默数据损坏，绝对不可行。
真正该关心的是初始化时机和并发安全
堆分配本身无需干预，但全局变量的初始化顺序、是否被多 goroutine 竞争读写，才是实际项目中最常出问题的地方：
- 包级变量按源码声明顺序初始化，跨包依赖靠
init()函数协调，但 init 顺序只保证同包内确定，跨包不确定 - 未加锁的全局可变变量（如
var counter int）在并发写时必然产生竞态，go run -race会立刻报出Data Race - 如果变量是大结构体或含指针字段（如
map[string]int），初始化时会触发堆分配和写屏障，但这是透明的，无需手动优化
真正要动手的，是用 sync.Once 做惰性初始化，或用 sync.Map 替代原生 map，而不是纠结“怎么让它上堆”。堆这件事，Go 早就替你决定了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
