答應我，別在go專案中用init()了

機智的小小帥發表於2021-04-10
Go

前言

go的 init函式給人的感覺怪怪的，我想不明白聰明的 google團隊為何要設計出這麼一個“雞肋“的機制。實際編碼中，我主張儘量不要使用init函式。

首先來看看 init函式的作用吧。

init() 介紹

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

大體而言，順序如下：

  1. 首先初始化包內宣告的變數
  2. 之後呼叫 init 函式
  3. 最後呼叫 main 函式
變數的初始化順序
變數的初始化順序由他們的依賴關係決定

應該任何強型別語言都是這樣子吧。

例如：

var a = b + c;
var b = f();	// 需要呼叫 f() 函式
var c = 1
func f() int{return c + 1;}

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

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

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

// 笨版
// 函式必須得有一個返回值才行
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
包內變數的初始化順序

一個包內往往有多個 go檔案，這麼go檔案的初始化順序由它們被提交給編譯器的順序決定，順序和這些檔案的名字有關。

init()

主角出場了。先來看看它的設計動機吧：

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》

這句話的意思是有的包級變數沒辦法用一條簡單的表示式來初始化，這個 時候，init機制就派上用場了。

init() 不能被呼叫，也不能被 reference，它們會在程式啟動時自動執行。

同一個 go 檔案中 init 函式的呼叫順序

一個包內，甚至 go 檔案內可以包含多個 init()，同一個 go 檔案中的 init() 呼叫順序由他們的宣告順序決定 。

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 LR c-->b b-->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")
}

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

我不喜歡 init 函式的原因

我不喜歡 init 函式的一個重要原因是，它會隱藏掉程式的一些細節，它會在沒有經過你同意的情況下，偷偷幹一些事情。go 的函式王國裡，所有的函式都需要程式設計師顯示的呼叫(Call)才會被執行，只有它——init()，是個例如，你明明沒 Call 它，它卻偷偷執行了。

有的同學會說，c++ 裡類的建構函式也是在物件被建立時就會默默執行呀。確實是這樣，但在 c++ 裡，當你點進這個類的定義時，你就能立馬看到它的建構函式和解構函式。在 go 裡，當你點進某個包時，你能立馬看到包內的init()麼？這個包有沒有init()以及有幾個init()完全是個未知數，你需要在包內的所有檔案中搜尋 init() 這個關鍵字才能摸清包的 init()情況，而大多數人包括我懶得費這個功夫。在c++中建立物件時，程式設計師能夠很清楚的意識到這個操作會觸發這個類的建構函式，這個建構函式的內容也能很快找到；但在 go 中，import 包時，一切卻沒那麼清晰了。

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

init() 給專案維護帶來的困難

當你看到這樣的 import 程式碼時

import(
	_ "pkg"
)

你立馬能夠知道，這個 import 的目的就是呼叫 pkg 包的 int()。

當看到

import(
	"pkg"
)

你卻很難知道，pkg 包裡藏著一個 init()，它被偷偷呼叫了。

但這還好，你起碼知道如果 pkg 包有 init() 的話，它會在此處被呼叫。

但當pkg 包，被多個包 import 時，pkg 包內的 init() 何時被呼叫的，就是一個謎了。你得搞清楚這些包之間的 import 先後順序關係，這是一場噩夢。

使用 init()的時機

先說一下我的結論：我認為 init()應該僅被用來初始化包內變數。

《The go programming language》提供了一個使用 init函式的例子。

// 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

變數 i 的二進位制表示形式為

0000000000000000000000000000000000000000000000000000000000000010

把它傳入 PopCount 最終得到的結果將為 1，因為它只有一個 bit 的值為 1。

pc 是一個表，它的 index 為 x，其中 0 <= x <= 255，value 為 x 中等於 1 的 bit 的數量。

它的初始化思想是：

  1. 如果一個數x最後的 bit 為 1，那麼這個數值為 1 的bit數 = x/2 的值為1的bit數 + 1；

  2. 如果一個數x最後的 bit 為 0，那麼這個數值為 1 的bit數 = x/2 的值為1的bit數；

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

這裡 pc 的初始化確實比較複雜，無法直接用

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(i&1)
	}
	return localPc
}

我覺得這樣子初始化比利用 init() 初始化要更好，因為你可以立馬知道 pc 是怎樣得來的，而利用 init() 時，你需要利用 ide 來查詢 pc 的 write reference，之後才能知道，哦，原來它(pc)來這裡(init()) 被初始化了呀。

當包內有多個變數的初始化流程比較複雜時，可能會寫出如下程式碼。

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

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

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

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

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

不使用 init 函式的時機

init()除了初始化變數，不應該幹其他任何事！

有兩個原則：

  1. 一個包的 init() 不應該依賴包外的環境
  2. 一個包的 init() 不應該對包外的環境造成影響

設定這兩個原則的理由是：任何對外部有依賴或者對外部有影響的程式碼都有義務顯式的讓程式設計師知曉，不應該自己悄咪咪地去做，最好是顯式地讓程式設計師自己去呼叫。

init() 的活動範圍就應該僅僅被侷限在包內，自己和自己玩，不要影響了其他小朋友的遊戲體驗。

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

  1. 讀取配置（依賴於外部的配置檔案，且一般讀取配置得到的 obj 會被其他包訪問，違反了第一條和第二條）
  2. 註冊路由（因為修改了 http 包中的 routeMap，會對 http 包造成影響，違反了第二條）
  3. 連線資料庫（連線資料庫後一般會得到一個 db 物件給業務層去curd吧？違反了第二條）
  4. etc... 我暫時只能想到這麼多了

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

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

當使用這個包時，一個必不可少的語句是：

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

原因是它裡面有個 init函式，會把自己註冊到 sql 包裡。

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

按照之前的標準，此處明顯不符合規範，因為它影響了標準庫的 sql 包。

我認為一個更好的方法是，建立一個 export 的專門用來做初始化工作的方法：

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

然後在 main 包中顯式的呼叫它：

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

來比較一下兩種方式吧。

  1. 使用 Init()

    • 是否需要告訴開發者額外的資訊？

      需要。

      需要告訴開發者：使用這個庫時，記得一定要呼叫 Init() 哦，我在裡面做了一些工作。

      開發者，點進 Init()，瞬間瞭然。

    • 是否能夠阻止開發者不正確的呼叫？

      不能。

      因為是 export 的，所以開發者可以想到哪兒呼叫就到哪兒呼叫，想呼叫多少次就呼叫多少次。

      因此需要額外告訴開發者：請您務必只呼叫一次，之後就不要呼叫了。且必須在用到 sql 包之前呼叫，一般而言都是在 main() 的第一句呼叫。

  2. 使用 init()

    • 是否需要告訴開發者額外的資訊？

      需要

      依舊需要告訴開發者，一定要用 _ "github.com/go-sql-driver/mysql"這個語句顯式的匯入包哦，因為我利用init()在裡面做一些工作。

      開發者：那你做了什麼工作

      庫：親，請您點進 mysql 包，在目錄下搜尋 init() 關鍵字，慢慢找哦。

      開發者：......

    • 是否能夠阻止開發者不正確的呼叫？

      勉強可以吧。

      因為 init() 只會被呼叫一次，不可能被呼叫多次，這從根本上杜絕了開發者呼叫多次的可能性。

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

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

所以可能使用 init() 為了的優勢就是減少了程式碼量吧。

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

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

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

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

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

oh yeah，足足少寫了一句程式碼！

一個例外 單元測試

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

假設我現在需要需要對 dao 層的增刪改查邏輯的寫一個單元測試。

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

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

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

很顯然，這些測試都是依賴資料庫的，因此為了正常的測試，必須初始化資料庫

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()...
}

這樣，當對這個檔案進行單元測試時，可以確保在執行每個 TestXXX 函式時，db 肯定是被正確初始化了的。

那為什麼這個地方可以利用 init() 來初始化資料庫呢？

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

理由之二是我懶。。。

總結

init 更像是一個語法糖，它會讓開發者對程式碼的追蹤能力變弱，所以能不用就最好不用。

相關文章