Go 程序启动时 runtime 做了哪些初始化工作：从 main 到第一行代码的完整流程

不写 main 之前，你永远不算真正理解 Go

大多数 Go 开发者都有一个朴素认知：程序从 main() 开始。这个认知在语言层面没有错，但它掩盖了 Go 程序真实的第一条指令——它往往藏在汇编入口 rt0_linux_amd64.s 里。很多奇怪的启动期问题，只有真正搞清楚 runtime 在用户代码之前做了什么，才看得穿。

Go 程序启动时 runtime 做了哪些初始化工作：从 main 到第一行代码的完整流程

这篇文章不做源码逐行翻译，而是把 Go 程序启动时 runtime 做的初始化工作，按流程拆开，讲讲每个环节为什么存在、出问题会是什么样子，以及我们应该在什么地方介入。

入口从哪里开始：用户 main 并不是第一条指令

在 Linux/amd64 上，一个 Go 可执行文件真正的入口是一个汇编符号，通常是 _rt0_amd64_linux，它设置好基本寄存器后调用 runtime.rt0_go。你可以自己验证：用 go build 编出一个二进制，然后执行 go tool objdump -s "runtime.rt0_go" 二进制名，会看到清晰的调用顺序。

// 简化的启动调用链（linux/amd64）
_rt0_amd64_linux
  → runtime.rt0_go
    → runtime.args
    → runtime.osinit
    → runtime.schedinit
    → runtime.newproc 创建调用 runtime.main 的主 goroutine
    → runtime.mstart  启动主线程调度循环

注意，runtime.schedinit 执行时，所有代码仍然运行在官方称为 m0 的主线程上，使用的是 g0 的系统栈。这个阶段还没有任何普通 goroutine 被调度。

启动过程中 runtime 到底初始化了什么

1. 收集系统级信息

在内核把控制权交给 Go 二进制之后，runtime 首先要感知所在环境。它需要拿到操作系统给的参数和内存布局，比如页大小、CPU 核数、进程参数。这一步很基础，但出了问题影响深远。

想想看：如果你在容器里用 CPU quota 限制，而 runtime 还是按物理 CPU 核数初始化，调度器就会创建多余的线程候选，导致上下文切换变多。对于 Go 这样自带并发的语言，错误的环境感知常常会让性能调优一开始就偏掉。

2. 内存分配器和垃圾回收状态的建立

在 schedinit 中，runtime 会初始化内存分配器的关键结构，包括固定堆大小、arena 范围、各 size class 的空闲列表。紧接着是垃圾回收器的状态准备，例如设置 GC 触发阈值。

如果这一步失败，程序无法向用户分配任何堆内存，基本会在没有任何可读 Go panic 的情况下直接崩掉。这也是为什么启动期内存问题最难排查：它发生在 fmt 包还没准备好输出机制之前。

3. 调度器与 goroutine 模型

调度器的全局队列、处理器 P 列表、本地运行队列、M 与 P 的绑定关系，都在 schedinit 里完成。随后通过 newproc 把 runtime.main 作为第一个普通 goroutine 放入队列，最后 mstart 进入调度循环。

有一件事值得强调：此时还没有调度用户代码，但 runtime 已经可以在自己建立的调度规则里运转。也就是说，你在 init 函数里写的 go func() 已经具备执行条件，因为这时的调度器已经算是可用了。

4. 执行用户初始化链

当主 goroutine 被调度到之后，runtime.main 会先完成一系列收尾动作，比如初始化 sysmon 监控线程、启动 GC 的 sweep 过程，然后调用编译器生成的初始化函数链 doInit，最终才调用你的 main.main。

这里有个容易误会的点：包级变量的初始化并不是在进入 main() 第一行才发生，而是在更早的 doInit 阶段就已经逐包执行了。所以，站在用户视角，你的第一行可执行代码可能并不是 fmt.Println，而是某个依赖库里 var GlobalConfig = loadConfig() 的赋值。

容易被忽略的启动期危险区

Runtime 初始化整体设计得很稳，但一旦你开始在里面塞业务逻辑，麻烦就来了。

场景一：一个服务为了“启动更早拿配置”在 init() 里发起了远程读取，结果配置中心抖动，程序启动时间从 1 秒变成 10 秒。更麻烦的是，在 init() 超时之前，进程没有任何业务日志，你只能靠 BPF 或阻塞 dump 去找原因。

场景二：项目越来越大，某个全局变量依赖另一个包的 init() 先执行，但又没法显式声明依赖。这时候 Go 的初始化顺序只会按源码包依赖关系编译期确定，人工很难维护，最后往往会改成“在 main 开头手动 init”。

场景三：有团队习惯在 init() 里设置 CPU 亲和性或调用 runtime.LockOSThread()。这本身可行，但要知道此时 runtime 尚未做一部分与 sysmon 相关的设置，你过早锁定线程可能影响后续调度。

一个经典误区：GOMAXPROCS 真的在 main 之前就有默认值了吗？

是的。Go runtime 会从系统实时探测并设置默认 GOMAXPROCS，这个动作发生在 schedinit 时，早于用户代码。如果你使用 runtime.GOMAXPROCS 在 main 里调整它，实际上是第二次覆盖。理解这点有助于排查“明明没设置 GOMAXPROCS，为什么 runtime.NumCPU() 返回容器限制值”的问题——因为 Go 1.5 后确实会用容器 cgroup 感知修正核数，但不同版本策略有差异。

把这些信息放到一张表里：启动阶段与失效表现

初始化阶段	主要职责	失败时的典型现象
entry	设置 m0/g0 栈，初始化寄存器	段错误，可能完全没有输出
osinit/args	获取系统参数、CPU核数、环境变量	环境变量为空或 CPU 信息异常
schedinit	内存分配器、调度器、GC 状态初始化	启动即 panic，且堆栈不完整
newproc	创建运行 runtime.main 的主 goroutine	无法进入 Go 代码，进程直接退出
mstart	启动主线程调度循环	程序挂死，没有业务日志
doInit	执行包级变量和函数 init	panic 在某个 init 中，启动中断