为什么不建议在go项目中使用init()

// 更合理的版本
func init() {
    fmt.Println("hello")
    fmt.Println("world")
}

func main() {

}
// Output:
// hello
// world

func init() {
    fmt.Print("a")
}
func init() {
    fmt.Print("b")
}
func init() {
    fmt.Print("c")
}
// Output
// abc

同一个包下面不同 go 文件中 init() 的调用顺序

依旧是由它们的声明顺序决定，同一个包下面的所有go 文件在编译时会被编译器合并成一个“大的go文件“（并不是真正合并，仅仅是效果类似而已）。合并的顺序由编译器决定。

不要把程序是否能够正常工作寄托在init()能够按照你期待的顺序被调用上。

不过话说回来，正经人谁在一个包里写很多 init() 呀，而且还把这些 init() 放在不同文件里，更可恶的是每个文件里还有多个 init()。要是看到这样的代码，我立马：@#$%^&*...balabala...

一个包里最多写一个init()（我甚至觉得最好连一个 init() 都不要有）

不同包内 init 函数的调用顺序

唯独这个顺序，我们程序员是绝对可控的。它们的调用顺序由包之间的依赖关系决定。假设 a包需要 import b包，b包需要import c包，那么很显然他们的调用顺序是，c包的init()最先被调用，其次是b包，最后是a包。

graph LRc-->bb-->a

一个包的init函数最多会被调用一次

道理类似于一个变量最多会被初始化一次。

有的同学会问，一个变量明明可以多次赋值呀，可第二次对这个变量赋值那还能够叫初始化么？

例如有如下的包结构，B包和C包都分别import A包，D包需要import B包和C包。

graph TD; A-->B A-->C B-->D C-->D

在 A包中有 init()

func init() {
    fmt.Println("hello world")
}

import(
    _ "pkg"
)

import(
    "pkg"
)

// pc[i] 是 i 中 bit = 1 的数量
var pc [256]byte

func init() {
    for i := range pc {
        pc[i] = pc[i/2] + byte(i&1)
    }
}

// 返回 x 中等于 1 的 bit 的数量
func PopCount(x uint64) int {
    return int(pc[byte(x>>(0*8))] +
        pc[byte(x>>(1*8))] +
        pc[byte(x>>(2*8))] +
        pc[byte(x>>(3*8))] +
        pc[byte(x>>(4*8))] +
        pc[byte(x>>(5*8))] +
        pc[byte(x>>(6*8))] +
        pc[byte(x>>(7*8))])
}

PopCount 函数的作用数计算数字中等于 1 的 bit 的数量。例如 ：

var i uint64 = 2

var pc = []byte{0, 1, 1,...}

var pc = generatePc()

func generatePc() [256]byte {
    var localPc [256]byte
    for i := range localPc {
        localPc[i] = localPc[i/2] + byte(i&1)
    }
    return localPc
}

var pc = generatePc()
var pc2 = generatePc2()
var pc3 = generatePc3()
// ...

有的同学可能不太喜欢这种写法，那么用上 init() 后，会写成这样

func init() {
    initPc()
    initPc2()
    initPc3()
}

我觉得两种写法都说的过去吧，虽然我个人更倾向第一种写法。