Go init 函数过多导致启动顺序难查怎么办

Go 项目里出现多个 init() 后，真正难查的通常不是“哪个 init 先执行”这么简单，而是包级变量初始化、副作用和跨文件依赖被藏在了不同入口。处理这类问题的稳妥办法是：先按 Go 规范还原初始化边界，再把业务依赖移到显式构造函数中，让 main 负责组装和处理错误。

不要靠增加日志或调整文件名“碰运气”。先画出包级变量、init() 和外部依赖的关系；能通过参数传递的初始化，都应尽量改成 NewXxx 或 BuildXxx。

规范依据：https://go.dev/ref/spec#Program_initialization_and_execution

先还原 Go 的初始化边界

程序初始化会先完成被导入包，再初始化当前包。一个包内部，先处理包级变量；变量的依赖分析会沿着初始化表达式和函数体中的引用展开，准备好的变量按声明顺序逐步初始化。所有包级变量完成后，才调用该包声明的 init()。

多个 init() 可以出现在同一个文件或不同文件中，调用顺序取决于它们在编译器接收到的源文件内容中的出现顺序。规范建议构建系统按词法文件名顺序提供同包文件，因此这能帮助复现，但不应被当作表达业务依赖的方式。

为什么 init 越多越难判断

常见症状有三类：测试包一导入就改全局注册表；某个 init() 读取环境变量，但调用方看不出要求；不同文件里的初始化互相依赖，改名或新增文件后日志顺序发生变化。此时先做一张表，比继续添加打印更有效：

判断顺序时要区分“规范保证”和“代码巧合”：同包变量有依赖时，依赖关系优先；没有被检测到的隐藏数据依赖，顺序可能不符合直觉。把启动所需的实体、配置和注册动作列出来，再逐项追到声明位置。

把隐式副作用改成显式构造

如果 init() 只是为了读取配置、创建客户端或登记处理器，可以把它改为返回值明确的构造函数。下面的写法让依赖关系出现在函数签名里，错误也能在启动层统一处理：

type App struct {
	Config   Config
	Registry *Registry
}

func NewConfig() (Config, error) {
	// 读取并校验配置；失败时把原因交给启动层处理。
	return Config{}, nil
}

func NewRegistry(cfg Config) (*Registry, error) {
	// 注册表依赖已经校验过的 Config，不再偷偷读取全局变量。
	return &Registry{}, nil
}

func BuildApp() (*App, error) {
	// 构造顺序由调用关系表达，便于测试替换和定位失败点。
	cfg, err := NewConfig()
	if err != nil {
		return nil, err // 启动失败保留原始错误，不继续使用半成品。
	}
	reg, err := NewRegistry(cfg)
	if err != nil {
		return nil, err // 注册失败立即返回，避免留下部分全局状态。
	}
	return &App{Config: cfg, Registry: reg}, nil
}

实际项目中可以让 main 调用 BuildApp，也可以把构造步骤拆到启动包。重点不是函数名固定为 New，而是初始化所需的数据通过参数进入、失败可以返回、资源生命周期能够被调用方看见。

重构后用四项检查收口

1. 查导入副作用：匿名导入是否仍然只是为了触发注册；若是，优先改成显式注册调用。
2. 查测试隔离：每个测试是否能独立创建 Config、Registry 和 App；不能就说明仍有共享全局状态。
3. 查错误路径：配置缺失、注册失败和重复注册是否都有明确返回或启动日志。
4. 查并发边界：不要在 init() 中启动难以回收的 goroutine；需要并发时由生命周期明确的启动组件管理。

最后可以保留少量真正无副作用的 init()，例如包内固定表的静态准备，但要避免让它承担外部 I/O、环境读取和跨包业务编排。这样即使继续保留 init，读者也能一眼看出它不会改变应用启动的关键状态。

常见问题

同一个 Go 文件里能写多个 init 函数吗？

可以。它们会按源代码中的出现顺序调用，但不建议用多个 init 表达复杂业务流程。

调整文件名能固定 init 顺序吗？

构建系统按词法文件名顺序提供源文件时，顺序更容易复现；但文件名仍不应替代显式依赖和构造调用。

init 里启动 goroutine 有什么问题？

初始化本身按单 goroutine 顺序推进，但 init 启动的 goroutine 可能与后续初始化并发，容易产生竞态。应把并发启动放到可管理生命周期的显式组件中。