答案。

Go 在程序启动时对包、变量和函数的初始化有严格的规则。主要机制是执行 init 函数和初始化全球变量。正确理解这些过程对于防止错误和意外效果至关重要。

问题历史：

自 Go 诞生以来，就引入了启动阶段的严格划分：声明、初始化和后续的代码执行。在 C/C++ 等语言中，通常使用全球变量的构造函数，而 Go 中的初始化顺序是确定的，但有其独特之处。

问题：

轻易地陷入陷阱，比如公共变量的初始化或 init 的调用导致包之间的相互依赖或循环情况。这难以追踪，程序的行为可能与开发者的预期不符，尤其是在隐蔽的依赖或状态在启动时被封装的情况下。

解决方案：

Go 中的包按其依赖关系的顺序进行初始化：先初始化依赖，然后是当前包。首先初始化包级变量（按照源文件中的出现顺序），然后调用任何 init() 函数（如果存在的话）。可以在同一个文件中声明多个 init()。同一包内文件之间的初始化顺序未定义（这可能导致错误）。

代码示例：

// a.go
package main
import "fmt"
func init() {
    fmt.Println("init from a.go")
}

// b.go
package main
import "fmt"
func init() {
    fmt.Println("init from b.go")
}

这些 init 函数的执行结果在同一目录下的文件之间不可预测，但总是发生在 main() 函数之前。

关键特性：

先初始化依赖，然后是当前包。
按照声明顺序初始化包级变量，仅后调用所有 init 函数。
在同一包的文件之间，init 函数的调用顺序未定义（可能因构建而异）。

隐含问题。

可以依赖于同一包中不同文件的 init 函数执行顺序吗？

不能！Go 不保证同一包中不同文件之间的 init 函数执行顺序。对特定顺序的期待可能导致难以捉摸的错误和业务逻辑的混乱。

在 init 函数执行时，全球变量可能未初始化吗？

不能——所有包的全球变量严格按照声明的顺序在该包的所有 init 函数之前执行。例外情况仅为包之间的交叉初始化（见下文）。

如何避免包之间的 init 循环依赖？

Go 不允许包级别的循环导入（这是编译时错误），但可能会陷入间接初始化的陷阱：A 依赖于 B，B 又依赖于 C，而 C（通过全球变量或 init）调用 A 的代码。在这种情况下，可能会出现 init/全球构造函数调用顺序的不明显性。

常见错误和反模式

期望同一包中不同文件之间的 init 函数有特定顺序。
通过包级变量（尤其是有副作用的）隐藏状态初始化。
试图在 init 函数中注入复杂的业务逻辑。
循环间接创建全球状态（通过字段、闭包或函数）。

生活中的例子

消极案例

团队的服务初始化逻辑在多个不同文件的 init 函数中执行。一个 init 函数依赖于另一个的结果，这导致在不同构建和不同服务器上的随机行为。

优点：

将代码中的责任区域分开。
启动时方便添加处理。

缺点：

不可预测的行为：有时服务无法正确启动，有时又能够正常工作。
难以维护和诊断。

积极案例

所有状态和初始化通过 main() 中的显式调用完成。init 函数仅用于启动追踪和小型检查。