前言

go的 init函數(shù)給人的感覺怪怪的，我想不明白聰明的 google團(tuán)隊為何要設(shè)計出這么一個“雞肋“的機(jī)制。實(shí)際編碼中，我主張盡量不要使用init函數(shù)。

首先來看看 init函數(shù)的作用吧。

init() 介紹

init()與包的初始化順序息息相關(guān)，所以先介紹一個go中包的初始化順序吧。（下面的內(nèi)容部分摘自《The go programinng language》）

大體而言，順序如下：

• 首先初始化包內(nèi)聲明的變量
• 之后調(diào)用 init 函數(shù)
• 最后調(diào)用 main 函數(shù)

變量的初始化順序

變量的初始化順序由他們的依賴關(guān)系決定

應(yīng)該任何強(qiáng)類型語言都是這樣子吧。

例如：

var a = b + c;
var b = f();	// 需要調(diào)用 f() 函數(shù)
var c = 1
func f() int{return c + 1;}

a 依賴 b 和 c；b 依賴 f()，f() 依賴 c。因此，他們的初始化順序理所當(dāng)然是 c -> b -> a。

graph TB; b-->a c-->a f-->b c-->b

Ps：其實(shí)在這里可能引申出一個沒用的小技巧。當(dāng)你有一個函數(shù)需要在包被初始化的過程中被調(diào)用時，你可以把這個函數(shù)賦值給一個包級變量。這樣，當(dāng)包被初始化時就會自動調(diào)用這個函數(shù)了，這個函數(shù)甚至能夠在 init() 之前被調(diào)用！不過話說回來，它既然比 init() 更早被調(diào)用，那它才是真正的 init() 才對；此外你也可以在 init() 中調(diào)用該函數(shù)，這樣才更合理一些。

// 笨版
// 函數(shù)必須得有一個返回值才行
var _ = func() interface{} {
	fmt.Println("hello")
	return nil
}()

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

func main() {

}
// Output:
// hello
// world

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

func main() {

}
// Output:
// hello
// world

包內(nèi)變量的初始化順序

一個包內(nèi)往往有多個 go文件，這么go文件的初始化順序由它們被提交給編譯器的順序決定，順序和這些文件的名字有關(guān)。

init()

主角出場了。先來看看它的設(shè)計動機(jī)吧：

Each variable declared at package level starts life with the value of its initializer expression, if any, but for some variables, like tables of data,an initializer expression may not be the simplest way to set its initial value.In that case,the init function mechanism may be simpler. 《The go pragramming language P44》

這句話的意思是有的包級變量沒辦法用一條簡單的表達(dá)式來初始化，這個 時候，init機(jī)制就派上用場了。

init() 不能被調(diào)用，也不能被 reference，它們會在程序啟動時自動執(zhí)行。

同一個 go 文件中 init 函數(shù)的調(diào)用順序

一個包內(nèi)，甚至 go 文件內(nèi)可以包含多個 init()，同一個 go 文件中的 init() 調(diào)用順序由他們的聲明順序決定 。

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

同一個包下面不同 go 文件中 init() 的調(diào)用順序

依舊是由它們的聲明順序決定，同一個包下面的所有go 文件在編譯時會被編譯器合并成一個“大的go文件“（并不是真正合并，僅僅是效果類似而已）。合并的順序由編譯器決定。

不要把程序是否能夠正常工作寄托在init()能夠按照你期待的順序被調(diào)用上。

不過話說回來，正經(jīng)人誰在一個包里寫很多 init() 呀，而且還把這些 init() 放在不同文件里，更可惡的是每個文件里還有多個 init()。要是看到這樣的代碼，我立馬：@#$%^*...balabala...

一個包里最多寫一個init()（我甚至覺得最好連一個 init() 都不要有）

不同包內(nèi) init 函數(shù)的調(diào)用順序

唯獨(dú)這個順序，我們程序員是絕對可控的。它們的調(diào)用順序由包之間的依賴關(guān)系決定。假設(shè) a包需要 import b包，b包需要import c包，那么很顯然他們的調(diào)用順序是，c包的init()最先被調(diào)用，其次是b包，最后是a包。

graph LRc-->bb-->a

一個包的init函數(shù)最多會被調(diào)用一次

道理類似于一個變量最多會被初始化一次。

有的同學(xué)會問，一個變量明明可以多次賦值呀，可第二次對這個變量賦值那還能夠叫初始化么？

例如有如下的包結(jié)構(gòu)，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")
}

D包是 main 包，最終程序只輸出了一句 hello world。

我不喜歡 init 函數(shù)的原因

我不喜歡 init 函數(shù)的一個重要原因是，它會隱藏掉程序的一些細(xì)節(jié)，它會在沒有經(jīng)過你同意的情況下，偷偷干一些事情。go 的函數(shù)王國里，所有的函數(shù)都需要程序員顯示的調(diào)用(Call)才會被執(zhí)行，只有它——init()，是個例如，你明明沒 Call 它，它卻偷偷執(zhí)行了。

有的同學(xué)會說，c++ 里類的構(gòu)造函數(shù)也是在對象被創(chuàng)建時就會默默執(zhí)行呀。確實(shí)是這樣，但在 c++ 里，當(dāng)你點(diǎn)進(jìn)這個類的定義時，你就能立馬看到它的構(gòu)造函數(shù)和析構(gòu)函數(shù)。在 go 里，當(dāng)你點(diǎn)進(jìn)某個包時，你能立馬看到包內(nèi)的init()么？這個包有沒有init()以及有幾個init()完全是個未知數(shù)，你需要在包內(nèi)的所有文件中搜索 init() 這個關(guān)鍵字才能摸清包的 init()情況，而大多數(shù)人包括我懶得費(fèi)這個功夫。在c++中創(chuàng)建對象時，程序員能夠很清楚的意識到這個操作會觸發(fā)這個類的構(gòu)造函數(shù)，這個構(gòu)造函數(shù)的內(nèi)容也能很快找到；但在 go 中，import 包時，一切卻沒那么清晰了。

希望將來 goland 或者 vscode 能夠分析包內(nèi)的 init() 情況，這樣我對 init() 的惡意會減半。

init() 給項目維護(hù)帶來的困難

當(dāng)你看到這樣的 import 代碼時

import(
	_ "pkg"
)

你立馬能夠知道，這個 import 的目的就是調(diào)用 pkg 包的 int()。

當(dāng)看到

import(
	"pkg"
)

你卻很難知道，pkg 包里藏著一個 init()，它被偷偷調(diào)用了。

但這還好，你起碼知道如果 pkg 包有 init() 的話，它會在此處被調(diào)用。

但當(dāng)pkg 包，被多個包 import 時，pkg 包內(nèi)的 init() 何時被調(diào)用的，就是一個謎了。你得搞清楚這些包之間的 import 先后順序關(guān)系，這是一場噩夢。

使用 init()的時機(jī)

先說一下我的結(jié)論：我認(rèn)為 init()應(yīng)該僅被用來初始化包內(nèi)變量。

《The go programming language》提供了一個使用 init函數(shù)的例子。

// pc[i] 是 i 中 bit = 1 的數(shù)量
var pc [256]byte

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

// 返回 x 中等于 1 的 bit 的數(shù)量
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 函數(shù)的作用數(shù)計算數(shù)字中等于 1 的 bit 的數(shù)量。例如 ：

var i uint64 = 2

變量 i 的二進(jìn)制表示形式為

0000000000000000000000000000000000000000000000000000000000000010

把它傳入 PopCount 最終得到的結(jié)果將為 1，因?yàn)樗挥幸粋€ bit 的值為 1。

pc 是一個表，它的 index 為 x，其中 0 = x = 255，value 為 x 中等于 1 的 bit 的數(shù)量。

它的初始化思想是：

• 如果一個數(shù)x最后的 bit 為 1，那么這個數(shù)值為 1 的bit數(shù) = x/2 的值為1的bit數(shù) + 1；
• 如果一個數(shù)x最后的 bit 為 0，那么這個數(shù)值為 1 的bit數(shù) = x/2 的值為1的bit數(shù)；

在 PopCount 中把一個 8byte 數(shù)拆成了 8 個單 byte 數(shù)，分別計算這8個單 byte 數(shù)中 bit 為 1 的數(shù)量，最后累加即可。

這里 pc 的初始化確實(shí)比較復(fù)雜，無法直接用

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

這種形式給出。

一個可以替代 init()的方法是：

var pc = generatePc()

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

我覺得這樣子初始化比利用 init() 初始化要更好，因?yàn)槟憧梢粤ⅠR知道 pc 是怎樣得來的，而利用 init() 時，你需要利用 ide 來查找 pc 的 write reference，之后才能知道，哦，原來它(pc)來這里(init()) 被初始化了呀。

當(dāng)包內(nèi)有多個變量的初始化流程比較復(fù)雜時，可能會寫出如下代碼。

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

有的同學(xué)可能不太喜歡這種寫法，那么用上 init() 后，會寫成這樣

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

我覺得兩種寫法都說的過去吧，雖然我個人更傾向第一種寫法。

使用 init()的時機(jī)，僅僅有一個例外，后面說。

不使用 init 函數(shù)的時機(jī)

init()除了初始化變量，不應(yīng)該干其他任何事！

有兩個原則：

• 一個包的 init() 不應(yīng)該依賴包外的環(huán)境
• 一個包的 init() 不應(yīng)該對包外的環(huán)境造成影響

設(shè)置這兩個原則的理由是：任何對外部有依賴或者對外部有影響的代碼都有義務(wù)顯式的讓程序員知曉，不應(yīng)該自己悄咪咪地去做，最好是顯式地讓程序員自己去調(diào)用。

init() 的活動范圍就應(yīng)該僅僅被局限在包內(nèi)，自己和自己玩，不要影響了其他小朋友的游戲體驗(yàn)。

如下幾條行為就踩了紅線：

• 讀取配置（依賴于外部的配置文件，且一般讀取配置得到的 obj 會被其他包訪問，違反了第一條和第二條）
• 注冊路由（因?yàn)樾薷牧?http 包中的 routeMap，會對 http 包造成影響，違反了第二條）
• 連接數(shù)據(jù)庫（連接數(shù)據(jù)庫后一般會得到一個 db 對象給業(yè)務(wù)層去curd吧？違反了第二條）
• etc... 我暫時只能想到這么多了

一個反面教材 https://github.com/go-sql-driver/mysql

反面教材就是：https://github.com/go-sql-driver/mysql 這個大名鼎鼎的包

當(dāng)使用這個包時，一個必不可少的語句是：

import (
	_ "github.com/go-sql-driver/mysql"
)

原因是它里面有個 init函數(shù)，會把自己注冊到 sql 包里。

func init() {
	sql.Register("mysql", MySQLDriver{})
}

按照之前的標(biāo)準(zhǔn)，此處明顯不符合規(guī)范，因?yàn)樗绊懥藰?biāo)準(zhǔn)庫的 sql 包。

我認(rèn)為一個更好的方法是，創(chuàng)建一個 export 的專門用來做初始化工作的方法：

// Package mysql
func Init() {
	sql.Register("mysql", MySQLDriver{})
}

然后在 main 包中顯式的調(diào)用它：

// Package main
func main(){
    mysql.Init();
    // other logic
}

來比較一下兩種方式吧。

1. 使用 Init()

• 是否需要告訴開發(fā)者額外的信息？

需要。

需要告訴開發(fā)者：使用這個庫時，記得一定要調(diào)用 Init() 哦，我在里面做了一些工作。

開發(fā)者，點(diǎn)進(jìn) Init()，瞬間了然。

• 是否能夠阻止開發(fā)者不正確的調(diào)用？

不能。

因?yàn)槭?export 的，所以開發(fā)者可以想到哪兒調(diào)用就到哪兒調(diào)用，想調(diào)用多少次就調(diào)用多少次。

因此需要額外告訴開發(fā)者：請您務(wù)必只調(diào)用一次，之后就不要調(diào)用了。且必須在用到 sql 包之前調(diào)用，一般而言都是在 main() 的第一句調(diào)用。

1. 使用 init()

• 是否需要告訴開發(fā)者額外的信息？

需要

依舊需要告訴開發(fā)者，一定要用 _ "github.com/go-sql-driver/mysql"這個語句顯式的導(dǎo)入包哦，因?yàn)槲依?code>init()在里面做一些工作。

開發(fā)者：那你做了什么工作

庫：親，請您點(diǎn)進(jìn) mysql 包，在目錄下搜索 init() 關(guān)鍵字，慢慢找哦。

開發(fā)者：......

• 是否能夠阻止開發(fā)者不正確的調(diào)用？

勉強(qiáng)可以吧。

因?yàn)?init() 只會被調(diào)用一次，不可能被調(diào)用多次，這從根本上杜絕了開發(fā)者調(diào)用多次的可能性。

可你管不了開發(fā)者的 import 時機(jī)，假設(shè)開發(fā)者在其他地方 import 了，導(dǎo)致你在 sql.Open()時，mysql 的 driver 沒有被正常注冊，你還是拿開發(fā)者沒有辦法。只能哀嘆一聲：我累了，毀滅吧。

我覺得作為庫的提供者，最主要的是提供完善的機(jī)制，在用戶使用你的庫時，能利用你提供的機(jī)制，寫出無bug 的代碼。而不是像保姆一樣，想方設(shè)法避免用戶出錯。

所以可能使用 init() 為了的優(yōu)勢就是減少了代碼量吧。

使用 Init() 時，需要兩句代碼

import (
	"github.com/go-sql-driver/mysql"	// 這句
)

func main(){
    mysql.Init()				  // 這句
}

但是使用 init 時，卻只需要一句代碼

import (
	_ "github.com/go-sql-driver/mysql"	// 這句
)

oh yeah，足足少寫了一句代碼！

一個例外 單元測試

可能使用 init 的唯一例外就是寫單元測試的時候了吧。

假設(shè)我現(xiàn)在需要需要對 dao 層的增刪改查邏輯的寫一個單元測試。

func TestCURDPlayer(t *testing.T) {
	// 測試 curd 玩家信息
}

func TestCURDStore(t *testing.T) {
	// 測試 curd 商店信息
}

func TestCURDMail(t *testing.T) {
	// 測試 curd 郵件信息
}

很顯然，這些測試都是依賴數(shù)據(jù)庫的，因此為了正常的測試，必須初始化數(shù)據(jù)庫

func TestCURDPlayer(t *testing.T) {
	// 測試 curd 玩家信息
    initdb()
    // balabala
}

func TestCURDStore(t *testing.T) {
	// 測試 curd 商店信息
    initdb()
    // balabala
}

func TestCURDMail(t *testing.T) {
	// 測試 curd 郵件信息
    initdb()
    // balabala
}

func initdb(){
    // sql.Open()...
}

難道我每次新增一個單元測試，都要在單元測試的代碼中加一個 initdb() 么，這也太麻煩了吧。

這個時候 init() 就派上用場了?？梢赃@樣

func TestCURDPlayer(t *testing.T) {
	// 測試 curd 玩家信息
    // balabala
}

func TestCURDStore(t *testing.T) {
	// 測試 curd 商店信息
    // balabala
}

func TestCURDMail(t *testing.T) {
	// 測試 curd 郵件信息
    // balabala
}

func init(){
    initdb()
}

func initdb(){
    // sql.Open()...
}

這樣，當(dāng)對這個文件進(jìn)行單元測試時，可以確保在執(zhí)行每個 TestXXX 函數(shù)時，db 肯定是被正確初始化了的。

那為什么這個地方可以利用 init() 來初始化數(shù)據(jù)庫呢？

理由之一是它的影響范圍很小，僅僅在 xxx_test.go 文件中生效，在 go run 時不會起作用，在 go test 時才會起作用。

理由之二是我懶。。。

總結(jié)

init 更像是一個語法糖，它會讓開發(fā)者對代碼的追蹤能力變?nèi)?，所以能不用就最好不用?/p>

到此這篇關(guān)于為什么不建議在go項目中使用用init()的文章就介紹到這了,更多相關(guān)go init內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！