在一次开发过程中，想要将程序运行环境的变量作为缓存的key值作为区分，因此在声明全局变量时使用了其他变量赋值。通过如下测试代码简化具体逻辑。
var a string
var b = fmt.Sprintf("prefix_%s",a)
func init(){
a = "test"
}
func TestPrint(t *testing.T) {
fmt.Println(a)
fmt.Println(b)
}
当我们执行测试程序时，诡异的事情发生了。
=== RUN TestPrint
test
prefix_
--- PASS: TestPrint (0.00s)
PASS
变量b在初始化时，a变量并未如预想的结果被初始化。后续我们通过查阅资料发现是由于包初始化顺序导致的，简单来说，对于测试代码初始化顺序为：
- 变量
- init()
- main()/test()
更详细的内容参考Package initialization。这部分内容总结如下：
包初始化
在一个包内，包级别变量的初始化是逐步进行的，初始化过程按照变量声明顺序中最早，同时不依赖其他未初始化的变量的顺序进行。
更准确地说，如果包级别变量的初始化不是通过初始化表达式或其初始化过程不依赖于未初始化的变量，则认为它已准备好进行初始化。 初始化按照变量的声明顺序进行。
如果一个或多个初始化周期依赖于某些尚未被初始化的变量，则这些处理无效。这部可以参考上述测试代码。b依赖a完后初始化，但是b初始化时，a还未被初始化（var a string 只是a被声明，真正的初始化是在init()），因此b初始化时对于a的依赖未生效，或者说此时a为空，b = “prefix_”。
如果左侧多个变量通过右侧单个(多个)表达式初始化，那么所有变量将在同一步骤被初始化。
var x = a
var a, b = f() // a和b将在x被初始化之前同时初始化
包初始化时，空白变量与声明中的任何其他变量一样，也会被处理。
在多个文件中变量的声明顺序由文件呈现给编译器的顺序决定：第一个文件中声明的变量一定在第二个文件中声明的任意变量之前初始化。
依赖分析不依赖于变量的实际值，只依赖于源文件中对它们的词法引用，并进行传递分析。 例如，如果变量 x 的初始化表达式引用一个函数，其函数体引用变量 y，则 x 取决于 y。 例如：
var (
a = c + b // == 9
b = f() // == 4
c = f() // == 5
d = 3 // == 5 after initialization has finished
)
func f() int {
d++
return d
}
通过实验结果可以发现，初始化顺序是d, b, c, a。请注意，初始化表达式中子表达式的顺序无关紧要： a = c + b和a = b + c在本示例中产生相同的初始化顺序。
每个包在初始化时都执行依赖分析；仅考虑对当前包中声明的变量、函数和（非接口）方法的引用。如果变量之间存在其他隐藏的数据依赖关系，则不指定这些变量之间的初始化顺序。例如：
var x = I(T{}).ab() // x 存在对 a,b的隐藏依赖
var _ = sideEffect() // 不依赖x, a,或b
var a = b
var b = 42
type I interface { ab() []int }
type T struct{}
func (T) ab() []int { return []int{a, b} }
Package initialization中说变量a将在b之后被初始化，但是x是在b之前，还是b,a之间或者a之后初始化，以及sideEffect()被调用的顺序(在 x 初始化之前或之后)是未被指定的。
但是我通过如下实验发现真实的情况和文档有些出入，具体的：对上述测试代码进行修改。
var x = I(T{}).ab() // x 存在对 a,b的隐藏依赖
var y = sideEffect() // 不依赖x, a,或b
var a = b
var b = 42
type I interface { ab() []int }
type T struct{}
func (T) ab() []int {
time.Sleep(1*time.Second)
fmt.Println(a,b)
return []int{a, b}
}
func sideEffect() int{
fmt.Println("init side")
return 1
}
func TestPrint(t *testing.T) {
fmt.Println(a)
fmt.Println(b)
fmt.Println(x)
fmt.Println(y)
}
实验结果如下：
42 42
init side
=== RUN TestPrint
42
42
[42 42]
1
--- PASS: TestPrint (0.00s)
PASS
实验结果表明，初始化顺序为：b,a,x,y。猜测应该是依赖分析过程隐藏的依赖关系有被分析到。因此按照真实的依赖和声明关系进行初始化。考虑到是不是文档版本太旧，源码已经进行了优化。但是文档日期为Version of Feb 10, 2021。我使用的golang版本为go version go1.15 darwin/amd64,文档出错的概率基本为0。于是再次优化了测试代码：
var x = I(T{}).ab() // x 存在对 a,b的隐藏依赖
var y = sideEffect() // 不依赖x, a,或b
var a = f()
var b = 42
type I interface { ab() []int }
type T struct{}
func sideEffect() int{
fmt.Println("init side")
return 1
}
func f() int{
fmt.Println("init a")
return 42
}
func (T) ab() []int {
fmt.Println("init x")
return []int{a, b}
}
func TestPrint(t *testing.T) {
fmt.Println(x)
fmt.Println(y)
fmt.Println(a)
fmt.Println(b)
}
实验结果为：
init x
init side
init a
=== RUN TestPrint
[0 42]
1
42
42
--- PASS: TestPrint (0.00s)
PASS
由于x初始化时，b并未被初始化，因此实验结果证明了，golang无法分析出这种基于接口的隐藏依赖关系。
变量也可以使用init方法进行初始化。
func init() { … }
每个包中甚至一个原文件中也可以定义多个这样的函数。init标识符只能用于声明init函数，因此init函数不能从程序的任何地方被调用。
一个没有imports的包通过按照init函数在源文件中出现的顺序为全局变量分配初始化值。如果包中存在多个源文件，则按照展示给编译器的文件顺序初始化变量。如果有包导入，则在初始化包本身之前初始化导入的包。如果多个包导入一个包，导入的包只会被初始化一次。包的导入，需要确保不会有循环初始化依赖，否则将编译错误。
包初始化、变量初始化和 init 函数的调用会发生在同一个 goroutine 中，该协程将逐个对包进行初始化。一个 init 函数可能会启动其他 goroutines，这些 goroutines 可以与初始化代码同时运行。然而，初始化总是对 init 函数进行排序：在前一个函数返回之前，它不会调用下一个函数。
为了确保可重现的初始化行为，鼓励构建系统以词法文件名顺序将属于同一包的多个文件呈现给编译器。
