Go 包初始化顺序怎样影响全局变量

Go 里“全局变量先后顺序”不是简单地看文件从上到下执行。真正影响结果的是三层关系：import 拓扑决定包与包之间的先后，包级变量的依赖关系决定同一个包里的初始化顺序，所有包级变量完成后才会调用 init。如果初始化表达式没有显式依赖，才轮到声明顺序发挥作用。

排查全局变量拿到零值、配置未加载或注册逻辑太早执行时，先看它依赖了哪个包和变量，再看 init；不要先凭文件名猜顺序。

先看 import 拓扑：依赖包一定先完成初始化

完整程序会先初始化被导入的包。假设 main 导入 app，app 又导入 config，那么顺序是 config → app → main。同一个包即使被多个包导入，也只初始化一次。

这意味着 app 的包级变量可以使用已经完成初始化的 config 导出变量，但不能反过来要求 config 在初始化时读取 app。Go 的包导入图本身不能形成循环，跨包顺序通常是最容易确定的一层。

最小配方：包级变量先按依赖，再按声明顺序

同一个包内，Go 会反复寻找“已经没有未初始化依赖”的变量，选择声明顺序最靠前的那个进行初始化。依赖不只来自变量表达式，也可能藏在初始化表达式调用的函数体里。

package settings

var (
    port = defaultPort() // 函数体引用了默认配置，先准备端口
    addr = "127.0.0.1:" + port
    ready = addr != "" // ready 依赖 addr，不能只看它排在前面还是后面
)

const defaultPortValue = "8080"

func defaultPort() string {
    // 用常量提供稳定默认值，避免初始化阶段读取尚未准备好的外部状态。
    return defaultPortValue
}

这里的关键不是三行变量的排列，而是 addr 明确依赖 port，ready 又依赖 addr。如果把一个变量引用藏在函数体里，依赖分析仍然会沿着当前包的函数引用关系追踪；但通过接口方法、外部状态等形成的“隐藏依赖”不一定能被语言规则识别，因此不要把副作用塞进全局初始化。

关键规则：init 一定在包级变量之后

一个包的初始化分两步：先给所有包级变量赋初值，再按源文件呈现顺序调用包内的 init 函数。多个 init 可以存在，但不能像普通函数一样被显式调用。跨包时，导入包的变量初始化和 init 都完成后，当前包才会开始。

package registry

var handlers = map[string]func(){}

func init() {
    // handlers 已经完成变量初始化，init 只负责注册默认处理器。
    handlers["health"] = func() {}
}

func HealthHandler() func() {
    // 显式返回当前注册表中的处理器，调用方无需猜 init 的时机。
    return handlers["health"]
}

因此，不能用 init 解决一个本来需要运行时配置的依赖。比如配置文件、环境变量、数据库连接或测试替身，都更适合由构造函数接收，再由 main 或测试明确调用。

变体与兼容坑：把隐式全局状态改成显式构造

如果初始化顺序变得难以解释，可以把全局变量改成结构体字段，用 NewApp 把依赖放进参数。这样做的价值不是“改变 Go 的初始化规则”，而是让顺序从语言隐式行为变成调用方可见的普通代码。

package app

type Config struct {
    Addr string
}

type App struct {
    cfg Config
}

func NewApp(cfg Config) *App {
    // 先校验必要配置，再创建 App，避免包级变量提前读取外部环境。
    if cfg.Addr == "" {
        cfg.Addr = "127.0.0.1:8080"
    }
    return &App{cfg: cfg}
}

func (a *App) Addr() string {
    // 运行期只读取已经注入的配置，不依赖 init 的副作用。
    return a.cfg.Addr
}

排障时可以按下面的表快速判断：

常见问题

同一个包拆成多个文件后，哪个文件先初始化？

变量声明顺序需要结合编译器接收的文件顺序判断；为了可重复，构建系统通常应按词法文件名顺序提供同包源文件。不要把跨文件的隐式副作用当成设计手段。

多个 init 函数能不能依赖彼此的执行结果？

它们会按源文件呈现顺序依次调用，但这种依赖不如显式函数调用清楚。若顺序是业务逻辑的一部分，应改成可命名、可测试的初始化函数。

包级变量一定会先得到零值吗？

变量存储会先有对应类型的零值，但显式初始化仍会在包初始化阶段完成。看到零值并不代表 init 已经运行，也不代表后续初始化一定会覆盖它。

记住一句话：先看 import 拓扑，再看包级变量依赖，最后看 init；凡是必须由调用方控制的状态，就不要藏在全局初始化里。