前言
go的 init函式給人的感覺怪怪的，我想不明白聰明的 google團隊為何要設計出這么一個“雞肋“的機制，實際編碼中，我主張盡量不要使用init函式，
首先來看看 init函式的作用吧，
init() 介紹
init()與包的初始化順序息息相關，所以先介紹一個go中包的初始化順序吧，（下面的內容部分摘自《The go programinng language》）
大體而言，順序如下：
- 首先初始化包內宣告的變數
- 之后呼叫
init函式 - 最后呼叫
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，
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包，
一個包的init函式最多會被呼叫一次
道理類似于一個變數最多會被初始化一次，
有的同學會問，一個變數明明可以多次賦值呀，可第二次對這個變數賦值那還能夠叫初始化么？
例如有如下的包結構，B包和C包都分別import A包，D包需要import B包和C包，
在 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 的數量，
它的初始化思想是：
-
如果一個數x最后的 bit 為 1，那么這個數值為 1 的bit數 = x/2 的值為1的bit數 + 1；
-
如果一個數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()除了初始化變數，不應該干其他任何事！
有兩個原則：
- 一個包的
init()不應該依賴包外的環境 - 一個包的
init()不應該對包外的環境造成影響
設定這兩個原則的理由是：任何對外部有依賴或者對外部有影響的代碼都有義務顯式的讓程式員知曉，不應該自己悄咪咪地去做，最好是顯式地讓程式員自己去呼叫，
init() 的活動范圍就應該僅僅被局限在包內，自己和自己玩，不要影響了其他小朋友的游戲體驗，
如下幾條行為就踩了紅線：
- 讀取配置（依賴于外部的組態檔，且一般讀取配置得到的 obj 會被其他包訪問，違反了第一條和第二條）
- 注冊路由（因為修改了
http包中的 routeMap，會對http包造成影響，違反了第二條） - 連接資料庫（連接資料庫后一般會得到一個 db 物件給業務層去curd吧？違反了第二條）
- 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
}
來比較一下兩種方式吧，
-
使用
Init()-
是否需要告訴開發者額外的資訊？
需要，
需要告訴開發者：使用這個庫時，記得一定要呼叫 Init() 哦，我在里面做了一些作業，
開發者，點進
Init()，瞬間了然， -
是否能夠阻止開發者不正確的呼叫？
不能，
因為是
export的，所以開發者可以想到哪兒呼叫就到哪兒呼叫，想呼叫多少次就呼叫多少次，因此需要額外告訴開發者：請您務必只呼叫一次，之后就不要呼叫了，且必須在用到
sql包之前呼叫，一般而言都是在main()的第一句呼叫，
-
-
使用
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 更像是一個語法糖，它會讓開發者對代碼的追蹤能力變弱，所以能不用就最好不用，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/274680.html
標籤：其他
上一篇：Java物件的創建程序