Go程序启动时初始化顺序为：全局变量初始化→init函数执行→runtime初始化完成→main启动；其中init按包依赖拓扑序和同包文件名字典序执行，跨包引用未初始化变量将得到零值。
Go 程序启动时的初始化顺序
在 main 函数执行前，Go 运行时已完成一系列不可见但关键的初始化动作。这些动作不是由用户控制的，但理解它们能帮你解释奇怪的 panic、竞态或初始化失败问题。
核心顺序是：全局变量初始化 → init 函数执行 → runtime 初始化完成 → main 启动。其中 init 函数的执行顺序受包依赖和源文件顺序双重影响，容易出错。
全局变量和 init 函数的执行时机与陷阱
所有包级变量（包括未显式赋值的零值变量）会在 init 之前完成内存分配和零值填充；随后按「导入依赖拓扑序 + 同包内文件名字典序」依次执行各 init 函数。
- 如果
init中调用尚未初始化的其他包变量（比如跨包引用了还没走完init的变量），结果是该变量仍为零值——不是 bug，是定义行为 - 同包多个
.go文件都含init？按文件名排序（如a.go先于b.go），不是按 import 顺序 -
import _ "net/http/pprof"这类匿名导入，本质就是触发其包内init注册 HTTP handler，没有main也能生效
var x = func() int { println("x init"); return 42 }()
func init() { println("in init") }
func main() { println("in main") }
// 输出顺序：
// x init
// in init
// in main
runtime.main 是怎么被调用的
你写的 main 函数其实只是被 Go 启动代码包装后的一个普通函数。真正入口是链接器插入的 C 函数 runtime.rt0_go，它设置栈、初始化 g0 和 m0，再调用 runtime.main。
立即学习“go语言免费学习笔记（深入）”；
runtime.main 做三件事：启动 GC 协程、执行用户 main、等待所有 goroutine 结束后调用 exit。这意味着：
-
os.Exit()会跳过 defer 和runtime.main的收尾逻辑，直接终止进程 - 如果你在
init里启了一个 goroutine 并发写全局 map，而没加 sync，main还没开始就可能 panic：fatal error: concurrent map writes - CGO_ENABLED=0 构建时，
runtime.main不会启动信号处理协程，某些 syscall 行为会不同
调试初始化阶段问题的实用方法
当程序在 main 前崩溃（比如段错误、nil pointer dereference），GDB 或 delve 很难直接断点到 init，因为符号信息不全。更有效的办法是：
- 加编译标记：
go build -gcflags="-m -l" -ldflags="-s -w"查看变量逃逸和内联情况，辅助判断初始化依赖 - 用
go tool compile -S main.go看汇编，搜索CALL.*init确认调用链 - 在怀疑的包里加
println("pkgname.init")（注意：不能用log，它本身依赖初始化） - 用
go run -gcflags="-l" -ldflags="-linkmode=external" ...强制外部链接，有时能暴露 cgo 初始化顺序问题
最常被忽略的是：init 函数里不能依赖 flag.Parse() 或 os.Args 的最终值——因为它们在 main 开始后才被 runtime 正确设置，init 阶段读到的可能是未清理的 argv 副本。
