告別混亂的 init--：Go 語言中更清晰的初始化策略

如何駕馭啓動複雜性並編寫更可測試、更顯式的 Go 代碼。

相信許多 Go 開發者都曾遇到過這樣的場景：加入一個新項目，克隆代碼庫，開始探索代碼結構。打開一個包，映入眼簾的便是那個熟悉卻時而令人頭痛的函數：init()。緊接着，在另一個包裏又發現一個。再打開一個，赫然又是一個。很快，你便意識到，應用程序的核心啓動邏輯——數據庫連接、配置加載、服務註冊——分散在多個隱式的 init() 函數中。

你不由得產生疑問：

這些 init() 函數以什麼順序執行？
如果其中一個失敗會發生什麼？
在不啓動真實數據庫的情況下，我該如何測試這個包？

如果這個場景似曾相識，那麼你遇到了 Go 語言中最常見的反模式之一：過度使用 init() 函數。雖然 init() 有其存在的意義，但依賴它進行復雜的設置邏輯會導致代碼變得晦澀難懂、脆弱且難以測試。

本文旨在引導你擺脫 init() 陷阱。我們將探討爲什麼 init() 可能存在問題，然後深入研究更清晰、更顯式且更易於測試的 Go 應用程序初始化策略。

init() 的誘惑與危險

init() 函數是 Go 語言中的一個特殊函數，它會在包初始化時自動運行。它不需要參數也不返回任何值。它是 "魔法" ——它只是運行。對於快速應急的設置來說，這可能很方便。

讓我們看一個典型的問題示例。想象一個 config 包和一個 database 包。

混亂的 init() 場景：

// config/config.go
package config

import (
 "encoding/json"
 "os"
)

var AppConfig struct {
 DatabaseURL string`json:"database_url"`
}

// This init() has side effects and no error handling
func init() {
 file, err := os.Open("config.json")
 if err != nil {
  // We can't return an error, so we have to panic.
  panic("could not open config.json: " + err.Error())
 }
 defer file.Close()

 decoder := json.NewDecoder(file)
 err = decoder.Decode(&AppConfig)
 if err != nil {
  panic("could not decode config: " + err.Error())
 }
}

// database/database.go
package database

import (
 "database/sql"
 "your/project/path/config"

 _ "github.com/lib/pq" // Postgres driver
)

var DB *sql.DB

// This init() depends on another init() and also panics
func init() {
 var err error
 // Implicitly depends on config.AppConfig being populated by its own init()
 DB, err = sql.Open("postgres", config.AppConfig.DatabaseURL)
 if err != nil {
  panic("could not connect to database: " + err.Error())
 }

 if err = DB.Ping(); err != nil {
  panic("database is not reachable: " + err.Error())
 }
}

雖然這段代碼可能可以運行，但它存在幾個關鍵缺陷：

隱藏的依賴關係：database 包隱式依賴於 config 包的 init() 已成功運行。這在函數簽名中並不明顯。你的代碼現在通過隱藏的全局狀態耦合在一起。
缺乏優雅的錯誤處理：init() 無法返回錯誤。處理失敗（如缺少配置文件或錯誤的數據庫密碼）的唯一選擇是 panic，這將導致整個應用程序崩潰。
不可測試的代碼：如何爲 database 包中使用了 database.DB 的函數編寫單元測試？你無法輕鬆地將 DB 替換爲測試用的模擬數據庫。該包永久性地綁定到在 init() 中創建的真實數據庫連接。
不確定的執行順序：Go 語言規範定義了 init() 函數按照包依賴順序執行。但隨着項目增長，這個順序可能變得不清晰，導致微妙且令人沮喪的錯誤。

那麼，替代方案是什麼呢？

策略一：顯式的 New... 構造函數

在 Go 中最地道、最強大的解決方案是將初始化邏輯移入顯式的構造函數中，通常命名爲 New...。

一個優秀的構造函數能做好三件事：

它將依賴項作爲參數接收。
它返回一個結構體的新實例。
它返回一個錯誤（error），允許調用方優雅地處理故障。

讓我們使用這個模式重構之前的示例。

"清晰的構造函數" 方法：

// config/config.go
package config

import (
 "encoding/json"
 "fmt"
 "os"
)

// Config is now a struct we can create and pass around.
type Config struct {
 DatabaseURL string`json:"database_url"`
}

// NewConfig is our explicit constructor.
func NewConfig(path string) (*Config, error) {
 file, err := os.Open(path)
 if err != nil {
  return nil, fmt.Errorf("could not open config file at %s: %w", path, err)
 }
 defer file.Close()

 var cfg Config
 decoder := json.NewDecoder(file)
 if err := decoder.Decode(&cfg); err != nil {
  return nil, fmt.Errorf("could not decode config: %w", err)
 }

 return &cfg, nil
}

// database/database.go
package database

import (
 "database/sql"
 "fmt"
 "your/project/path/config"

 _ "github.com/lib/pq"
)

// The DB connection is no longer a global variable, but part of a struct
// or simply returned by the constructor.
// For this example, we'll just return it.

// NewDB is our explicit constructor.
// Notice how it explicitly asks for the config it needs!
func NewDB(cfg *config.Config) (*sql.DB, error) {
 db, err := sql.Open("postgres", cfg.DatabaseURL)
 if err != nil {
  return nil, fmt.Errorf("could not connect to database: %w", err)
 }

 if err = db.Ping(); err != nil {
  return nil, fmt.Errorf("database is not reachable: %w", err)
 }

 fmt.Println("Database connection established successfully.")
 return db, nil
}

現在，如何將它們整合起來？在我們的 main.go 中：

// main.go
package main

import (
 "log"
 "your/project/path/config"
 "your/project/path/database"
)

func main() {
 // 1. Explicitly load config
 cfg, err := config.NewConfig("config.json")
 if err != nil {
  log.Fatalf("FATAL: failed to load configuration: %v", err)
 }

 // 2. Explicitly create DB connection, passing the config
 db, err := database.NewDB(cfg)
 if err != nil {
  log.Fatalf("FATAL: failed to initialize database: %v", err)
 }

 // Now you can pass `db` to your services, handlers, etc.
 // server := NewServer(db)
 // server.Start()
}

其益處立竿見影且清晰可見：

顯式的依賴關係：database.NewDB 明確告訴你它需要什麼：一個 *config.Config。沒有魔法。
真正的錯誤處理：main 現在可以優雅地處理錯誤。它記錄致命錯誤，但也可以選擇重試或回退到默認值。
高度可測試：要測試一個需要數據庫的函數，你可以在測試文件中輕鬆創建一個模擬數據庫連接，並將其傳遞給構造函數。你的代碼在測試期間不再綁定到真實的數據庫。

策略二：使用依賴注入（DI）駕馭複雜性

New... 模式非常出色，能解決你 95% 的問題。然而，在非常龐大的應用程序中，在 main() 中手動連接數十個依賴項會變得繁瑣：

 cfg := NewConfig()
 db := NewDB(cfg)
 userRepo := NewUserRepository(db)
 orderRepo := NewOrderRepository(db)
 authService := NewAuthService(userRepo)
 // ... 依此類推

這時依賴注入（DI）框架就能發揮作用。Go 生態系統中一個流行的選擇是 Google 的 wire。

wire 是一個編譯時 DI 工具。你只需編寫簡單的 New... 構造函數（提供者），就像我們上面做的那樣，然後告訴 wire 如何連接它們。它會生成執行連接操作的純 Go 代碼。

一個 wire 的配置可能如下所示：

// wire.go
// go:build wireinject

package main

import (
 "your/project/path/config"
 "your/project/path/database"
 "your/project/path/server"

 "github.com/google/wire"
)

// InitializeServer 告訴 wire 如何構建一個 Server。
func InitializeServer() (*server.Server, error) {
 // wire.Build 將在編譯時連接這些提供者。
 wire.Build(config.NewConfig, database.NewDB, server.NewServer)
 return nil, nil
}

運行 go generate 會生成一個 wire_gen.go 文件，其中包含正確的、顯式的連接代碼，讓你兩全其美：自動化和顯式、可讀的代碼。

那麼，何時使用 init() 纔是真正合適的？

init() 並非一無是處，使用 init() 函數來檢查包級變量的初始狀態。在 Go 標準庫中有很多這樣的的例子。

重置包級變量值：

標準庫 flag 包：

var CommandLine *FlagSet

func init() {
 // It's possible for execl to hand us an empty os.Args.
 if len(os.Args) == 0 {
  CommandLine = NewFlagSet("", ExitOnError)
 } else {
  CommandLine = NewFlagSet(os.Args[0], ExitOnError)
 }

 // Override generic FlagSet default Usage with call to global Usage.
 // Note: This is not CommandLine.Usage = Usage,
 // because we want any eventual call to use any updated value of Usage,
 // not the value it has when this line is run.
 CommandLine.Usage = commandLineUsage
}

通過這個 init 函數，flag 包在程序啓動時就爲用戶提供了一個開箱即用的命令行解析能力，而無需用戶手動初始化 FlagSet。

標準庫 context 包：

// closedchan is a reusable closed channel.
var closedchan = make(chan struct{})

func init() {
 close(closedchan)
}

context 包中的 init 函數通過創建一個並立即關閉的全局 closedchan 變量，爲 Context 包提供了一個高效且可重用的機制來表示一個已經完成或取消的 Context 狀態；避免在不需要時不必要的通道分配。

標準庫 regexp 包：

// Bitmap used by func special to check whether a character needs to be escaped.
var specialBytes [16]byte

// special reports whether byte b needs to be escaped by QuoteMeta.
func special(b byte) bool {
 return b < utf8.RuneSelf && specialBytes[b%16]&(1<<(b/16)) != 0
}

func init() {
 for _, b := range []byte(`\.+*?()|[]{}^$`) {
  specialBytes[b%16] |= 1 << (b / 16)
 }
}

regexp 包中的 init 函數通過預先計算並填充一個高效的位圖查找表 specialBytes，確保了在程序開始使用正則表達式功能之前，這個重要的查找表就已經準備就緒，提高了性能。

標準庫 slog 包：

var defaultLogger atomic.Pointer[Logger]

func init() {
 defaultLogger.Store(New(newDefaultHandler(loginternal.DefaultOutput)))
}

// Default returns the default [Logger].
func Default() *Logger { return defaultLogger.Load() }

// SetDefault makes l the default [Logger], which is used by
// the top-level functions [Info], [Debug] and so on.
func SetDefault(l *Logger) {
 defaultLogger.Store(l)
 // ... ...
 }
}

slog 包中的 init 函數提供一個方便、安全且可配置的默認日誌記錄器。它確保在程序啓動時就有一個可用的日誌輸出機制，並允許開發者在需要時輕鬆地替換或定製這個默認行爲，而無需在代碼庫中到處傳遞日誌器實例。

註冊功能：

// src\image\image_test.go

import (
 "encoding/base64"
 "image"
 "strings"

 // Package image/jpeg is not used explicitly in the code below,
 // but is imported for its initialization side-effect, which allows
 // image.Decode to understand JPEG formatted images. Uncomment these
 // two lines to also understand GIF and PNG images:
 // _ "image/gif"
 // _ "image/png"
 _ "image/jpeg"
)

func Example() {
 reader := base64.NewDecoder(base64.StdEncoding, strings.NewReader(data))
 m, _, err := image.Decode(reader)
 // ... ...
}

當 image/jpeg 包被導入時，即使你的代碼沒有直接調用 jpeg.Decode() 或其他函數，該包內部的 init() 函數也會被執行。image/jpeg 包的 init() 函數會將其自身的解碼器註冊到 image 包中。

// src\image\jpeg\reader.go

func init() {
 image.RegisterFormat("jpeg", "\xff\xd8", Decode, DecodeConfig)
}

image.Decode：這是 image 標準庫中一個通用的函數，它可以根據圖片數據的頭部信息自動識別圖片格式（如 JPEG, GIF, PNG）並進行解碼。但它需要相應的解碼器被註冊。所以需要導入相應的圖片格式包（如 image/jpeg，image/gif，image/png）。

結論：選擇清晰而非魔法

init() 函數提供了一個誘人的捷徑，但它通常會導致隱式依賴、不可測試的代碼和啓動崩潰。通過擁抱顯式的構造函數（New...），你可以爲 Go 應用程序重新帶來清晰性和健壯性。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/gC9dtshP3JmmsuVWzTEjqQ

猜你喜歡