原文: The Top 10 Most Common Mistakes I’ve Seen in Go Projects

作者: Teiva Harsanyi

譯者: Simon Ma

我在Go開發中遇到的十大常見錯誤。順序無關緊要。

未知的列舉值

讓我們看一個簡單的例子:

type Status uint32

const (
    StatusOpen Status = iota
    StatusClosed
    StatusUnknown
)

在這裡，我們使用iota建立了一個列舉，其結果如下：

StatusOpen = 0
StatusClosed = 1
StatusUnknown = 2
 

現在，讓我們假設這個Status型別是JSON請求的一部分，將被marshalled/unmarshalled。

我們設計了以下結構：

type Request struct {
    ID        int    `json:"Id"`
    Timestamp int    `json:"Timestamp"`
    Status    Status `json:"Status"`
}

然後，接收這樣的請求：

{
  "Id": 1234,
  "Timestamp": 1563362390,
  "Status": 0
}

這裡沒有什麼特別的，狀態會被unmarshalled為StatusOpen

然而，讓我們以另一個未設定狀態值的請求為例:

{
  "Id": 1235,
  "Timestamp": 1563362390
}

在這種情況下，請求結構的Status欄位將初始化為它的零值(對於uint32型別:0)，因此結果將是StatusOpen而不是StatusUnknown。

那麼最好的做法是將列舉的未知值設定為0：

type Status uint32

const (
    StatusUnknown Status = iota
    StatusOpen
    StatusClosed
)

如果狀態不是JSON請求的一部分，它將被初始化為StatusUnknown，這才符合我們的期望。

自動優化的基準測試

基準測試需要考慮很多因素的,才能得到正確的測試結果。

一個常見的錯誤是測試程式碼無形間被編譯器所優化。

下面是teivah/bitvector庫中的一個例子:

func clear(n uint64, i, j uint8) uint64 {
    return (math.MaxUint64<<j | ((1 << i) - 1)) & n
}

此函式清除給定範圍內的位。為了測試它，可能如下這樣做:

func BenchmarkWrong(b *testing.B) {
    for i := 0; i < b.N; i++ {
        clear(1221892080809121, 10, 63)
    }
}

在這個基準測試中，clear不呼叫任何其他函式，沒有副作用。所以編譯器將會把clear優化成行內函數。一旦內聯，將會導致不準確的測試結果。

一個解決方案是將函式結果設定為全域性變數，如下所示：

var result uint64

func BenchmarkCorrect(b *testing.B) {
    var r uint64
    for i := 0; i < b.N; i++ {
        r = clear(1221892080809121, 10, 63)
    }
    result = r
}

如此一來，編譯器將不知道clear是否會產生副作用。

因此，不會將clear優化成行內函數。

延伸閱讀

High Performance Go Workshop

被轉移的指標

在函式呼叫中，按值傳遞的變數將建立該變數的副本，而通過指標傳遞只會傳遞該變數的記憶體地址。

那麼，指標傳遞會比按值傳遞更快嗎？請看一下這個例子。

我在本地環境上模擬了0.3KB的資料，然後分別測試了按值傳遞和指標傳遞的速度。

結果顯示：按值傳遞比指標傳遞快4倍以上，這很違背直覺。

測試結果與Go中如何管理記憶體有關。我雖然不能像威廉·肯尼迪那樣出色地解釋它，但讓我試著總結一下。

譯者注開始

作者沒有說明Go記憶體的基本儲存方式，譯者補充一下。

1. 下面是來自Go語言聖經的介紹：

   一個goroutine會以一個很小的棧開始其生命週期，一般只需要2KB。

   一個goroutine的棧，和作業系統執行緒一樣，會儲存其活躍或掛起的函式呼叫的本地變數，但是和OS執行緒不太一樣的是，一個goroutine的棧大小並不是固定的；棧的大小會根據需要動態地伸縮。

   而goroutine的棧的最大值有1GB，比傳統的固定大小的執行緒棧要大得多，儘管一般情況下，大多goroutine都不需要這麼大的棧。

2. 譯者自己的理解：

   • 棧：每個Goruntine開始的時候都有獨立的棧來儲存資料。（Goruntine分為主Goruntine和其他Goruntine，差異就在於起始棧的大小）

   • 堆: 而需要被多個Goruntine共享的資料，儲存在堆上面。

譯者注結束

眾所周知，可以在堆或棧上分配變數。

• 棧儲存當前Goroutine的正在使用的變數（譯者注: 可理解為區域性變數）。一旦函式返回，變數就會從棧中彈出。
• 堆儲存共享變數（全域性變數等）。

讓我們看一個簡單的例子，返回單一的值：

func getFooValue() foo {
    var result foo
    // Do something
    return result
}

當呼叫函式時，result變數會在當前Goruntine棧建立，當函式返回時，會傳遞給接收者一份值的拷貝。而result變數自身會從當前Goruntine棧出棧。

雖然它仍然存在於記憶體中，但它不能再被訪問。並且還有可能被其他資料變數所擦除。

現在，在看一個返回指標的例子：

func getFooPointer() *foo {
    var result foo
    // Do something
    return &result
}

當呼叫函式時，result變數會在當前Goruntine棧建立，當函式返回時，會傳遞給接收者一個指標（變數地址的副本）。如果result變數從當前Goruntine棧出棧，則接收者將無法再訪問它。（譯者注：此情況稱為“記憶體逃逸”）

在這個場景中，Go編譯器將把result變數轉義到一個可以共享變數的地方:堆。

不過，傳遞指標是另一種情況。例如：

func main()  {
    p := &foo{}
    f(p)
}

因為我們在同一個Goroutine中呼叫f，所以p變數不需要轉義。它只是被推送到堆疊，子功能可以訪問它。（譯者注：不需要其他Goruntine共享的變數就儲存在棧上即可）

比如，io.Reader中的Read方法簽名，接收切片引數，將內容讀取到切片中，返回讀取的位元組數。而不是返回讀取後的切片。（譯者注：如果返回切片，會將切片轉義到堆中。）

type Reader interface {
    Read(p []byte) (n int, err error)
}

為什麼棧如此之快？ 主要有兩個原因：

1. 堆疊不需要垃圾收集器。就像我們說的，變數一旦建立就會被入棧，一旦函式返回就會從出棧。不需要一個複雜的程序來回收未使用的變數。
2. 儲存變數不需要考慮同步。堆屬於一個Goroutine，因此與在堆上儲存變數相比，儲存變數不需要同步。

總之，當建立一個函式時，我們的預設行為應該是使用值而不是指標。只有在我們想要共享變數時才應使用指標。

如果我們遇到效能問題，可以使用go build -gcflags "-m -m"命令，來顯示編譯器將變數轉義到堆的具體操作。

再次重申，對於大多數日常用例來說，值傳遞是最合適的。

延伸閱讀

1. Language Mechanics On Stacks And Pointers

2. Understanding Allocations: the Stack and the Heap - GopherCon SG 2019

出乎意料的break

如果f返回true，下面的例子中會發生什麼？

for {
  switch f() {
  case true:
    break
  case false:
    // Do something
  }
}

我們將呼叫break語句。然而，將會break出switch語句，而不是for迴圈。

同樣的問題：

for {
  select {
  case <-ch:
  // Do something
  case <-ctx.Done():
    break
  }
}

break與select語句有關，與for迴圈無關。

break出for/switch或for/select的一種解決方案是使用帶標籤的break，如下所示：

loop:
    for {
        select {
        case <-ch:
        // Do something
        case <-ctx.Done():
            break loop
        }
    }

缺失上下文的錯誤

Go在錯誤處理方面仍然有待提高，以至於現在錯誤處理是Go2中最令人期待的需求。

當前的標準庫(在Go 1.13之前)只提供error的建構函式，自然而然就會缺失其他資訊。

讓我們看一下pkg/errors庫中錯誤處理的思想：

An error should be handled only once. Logging an error is handling an error. So an error should either be logged or propagated.

（譯：錯誤應該只處理一次。記錄log 錯誤就是在處理錯誤。所以，錯誤應該記錄或者傳播）

對於當前的標準庫，很難做到這一點，因為我們希望向錯誤中新增一些上下文資訊，使其具有層次結構。

例如: 所期望的REST呼叫導致資料庫問題的示例：

unable to server HTTP POST request for customer 1234
 |_ unable to insert customer contract abcd
     |_ unable to commit transaction

如果我們使用pkg/errors，可以這樣做：

func postHandler(customer Customer) Status {
    err := insert(customer.Contract)
    if err != nil {
        log.WithError(err).Errorf("unable to server HTTP POST request for customer %s", customer.ID)
        return Status{ok: false}
    }
    return Status{ok: true}
}

func insert(contract Contract) error {
    err := dbQuery(contract)
    if err != nil {
        return errors.Wrapf(err, "unable to insert customer contract %s", contract.ID)
    }
    return nil
}

func dbQuery(contract Contract) error {
    // Do something then fail
    return errors.New("unable to commit transaction")
}

如果不是由外部庫返回的初始error可以使用error.New建立。中間層insert對此錯誤新增更多上下文資訊。最終通過log錯誤來處理錯誤。每個級別要麼返回錯誤，要麼處理錯誤。

我們可能還想檢查錯誤原因來判讀是否應該重試。假設我們有一個來自外部庫的db包來處理資料庫訪問。 該庫可能會返回一個名為db.DBError的臨時錯誤。要確定是否需要重試，我們必須檢查錯誤原因：

使用pkg/errors中提供的errors.Cause可以判斷錯誤原因。

func postHandler(customer Customer) Status {
    err := insert(customer.Contract)
    if err != nil {
        switch errors.Cause(err).(type) {
        default:
            log.WithError(err).Errorf("unable to server HTTP POST request for customer %s", customer.ID)
            return Status{ok: false}
        case *db.DBError:
            return retry(customer)
        }

    }
    return Status{ok: true}
}

func insert(contract Contract) error {
    err := db.dbQuery(contract)
    if err != nil {
        return errors.Wrapf(err, "unable to insert customer contract %s", contract.ID)
    }
    return nil
}

我見過的一個常見錯誤是部分使用pkg/errors。 例如，通過這種方式檢查錯誤：

switch err.(type) {
default:
  log.WithError(err).Errorf("unable to server HTTP POST request for customer %s", customer.ID)
  return Status{ok: false}
case *db.DBError:
  return retry(customer)
}

在此示例中，如果db.DBError被wrapped，它將永遠不會執行retry。

延伸閱讀

Don’t just check errors, handle them gracefully

正在擴容的切片

有時，我們知道切片的最終長度。假設我們想把Foo切片轉換成Bar切片，這意味著這兩個切片的長度是一樣的。

我經常看到切片以下面的方式初始化：

var bars []Bar
bars := make([]Bar, 0)

切片不是一個神奇的資料結構，如果沒有更多可用空間，它會進行雙倍擴容。在這種情況下，會自動建立一個切片(容量更大)，並複製其中的元素。

如果想容納上千個元素，想象一下，我們需要擴容多少次。雖然插入的時間複雜度是O(1)，但它仍會對效能有所影響。

因此，如果我們知道最終長度，我們可以:

• 用預定義的長度初始化它

  func convert(foos []Foo) []Bar {
    bars := make([]Bar, len(foos))
    for i, foo := range foos {
        bars[i] = fooToBar(foo)
    }
    return bars
  }

• 或者使用長度0和預定義容量初始化它：

  func convert(foos []Foo) []Bar {
    bars := make([]Bar, 0, len(foos))
    for _, foo := range foos {
        bars = append(bars, fooToBar(foo))
    }
    return bars
  }

毫無規範的Context

context.Context 經常被誤用。 根據官方文件:

A Context carries a deadline, a cancelation signal, and other values across API boundaries.

這種描述非常籠統，以至於讓一些人對使用它感到困惑。

讓我們試著詳細描述一下。Context可以包含:

• A deadline（最後期限）。它意味著到期之後（250ms之後或者一個指定的日期），我們必須停止正在進行的操作（I/O請求，等待的channel輸入，等等）。
• A cancelation signal（取消訊號）。一旦我們收到訊號，我們必須停止正在進行的活動。例如，假設我們收到兩個請求：一個用來插入一些資料，另一個用來取消第一個請求。這可以通過在第一個呼叫中使用cancelable上下文來實現，一旦我們獲得第二個請求，這個上下文就會被取消。
• A list of key/value （鍵/值列表）均基於interface{}型別。

值得一提的是，Context是可以組合的。例如，我們可以繼承一個帶有截止日期和鍵/值列表的Context。此外，多個goroutines可以共享相同的Context，取消一個Context可能會停止多個活動。

回到我們的主題，舉一個我經歷的例子。

一個基於urfave/cli （如果您不知道，這是一個很好的庫，可以在Go中建立命令列應用程式）建立的Go應用。一旦開始，程式就會繼承父級的Context。這意味著當應用程式停止時，將使用此Context傳送取消訊號。

我經歷的是，這個Context是在呼叫gRPC時直接傳遞的，這不是我想做的。相反，我想當應用程式停止時或無操作100毫秒後，傳送取消請求。

為此，可以簡單地建立一個組合的Context。如果parent是父級的Context的名稱（由urfave/cli建立），那麼組合操作如下：

ctx, cancel := context.WithTimeout(parent, 100 * time.Millisecond)
response, err := grpcClient.Send(ctx, request)

Context並不複雜，在我看來，可謂是 Go 的最佳特性之一。

延伸閱讀

1. Understanding the context package in golang
2. gRPC and Deadlines

被遺忘的-race引數

我經常看到的一個錯誤是在沒有-race引數的情況下測試 Go 應用程式。

正如本報告所述，雖然Go“旨在使併發程式設計更容易，更不容易出錯”，但我們仍然遇到很多併發問題。

顯然，Go 競爭檢測器無法解決每一個併發問題。但是，它仍有很大價值，我們應該在測試應用程式時始終啟用它。

延伸閱讀

Does the Go race detector catch all data race bugs?

更完美的封裝

另一個常見錯誤是將檔名傳遞給函式。

假設我們實現一個函式來計算檔案中的空行數。最初的實現是這樣的：

func count(filename string) (int, error) {
    file, err := os.Open(filename)
    if err != nil {
        return 0, errors.Wrapf(err, "unable to open %s", filename)
    }
    defer file.Close()

    scanner := bufio.NewScanner(file)
    count := 0
    for scanner.Scan() {
        if scanner.Text() == "" {
            count++
        }
    }
    return count, nil
}

filename 作為給定的引數，然後我們開啟該檔案，再實現讀空白行的邏輯，嗯，沒有問題。

假設我們希望在此函式之上實現單元測試，並使用普通檔案，空檔案，具有不同編碼型別的檔案等進行測試。程式碼很容易變得非常難以維護。

此外，如果我們想對於HTTP Body實現相同的邏輯，將不得不為此建立另一個函式。

Go 設計了兩個很棒的介面：io.Reader 和 io.Writer (譯者注：常見IO 命令列，檔案，網路等)

所以可以傳遞一個抽象資料來源的io.Reader，而不是傳遞檔名。

仔細想一想統計的只是檔案嗎？一個HTTP正文？位元組緩衝區？

答案並不重要，重要的是無論Reader讀取的是什麼型別的資料，我們都會使用相同的Read方法。

在我們的例子中，甚至可以緩衝輸入以逐行讀取它（使用bufio.Reader及其ReadLine方法）：

func count(reader *bufio.Reader) (int, error) {
    count := 0
    for {
        line, _, err := reader.ReadLine()
        if err != nil {
            switch err {
            default:
                return 0, errors.Wrapf(err, "unable to read")
            case io.EOF:
                return count, nil
            }
        }
        if len(line) == 0 {
            count++
        }
    }
}

開啟檔案的邏輯現在交給呼叫count方：

file, err := os.Open(filename)
if err != nil {
  return errors.Wrapf(err, "unable to open %s", filename)
}
defer file.Close()
count, err := count(bufio.NewReader(file))

無論資料來源如何，都可以呼叫count。並且，還將促進單元測試，因為可以從字串建立一個bufio.Reader，這大大提高了效率。

count, err := count(bufio.NewReader(strings.NewReader("input")))

Goruntines與迴圈變數

我見過的最後一個常見錯誤是使用 Goroutines 和迴圈變數。

以下示例將會輸出什麼？

ints := []int{1, 2, 3}
for _, i := range ints {
  go func() {
    fmt.Printf("%v\n", i)
  }()
}

亂序輸出 1 2 3 ？答錯了。

在這個例子中，每個 Goroutine 共享相同的變數例項，因此最有可能輸出3 3 3。

有兩種解決方案可以解決這個問題。

第一種是將i變數的值傳遞給閉包（內部函式）：

ints := []int{1, 2, 3}
for _, i := range ints {
  go func(i int) {
    fmt.Printf("%v\n", i)
  }(i)
}

第二種是在for迴圈範圍內建立另一個變數：

ints := []int{1, 2, 3}
for _, i := range ints {
  i := i
  go func() {
    fmt.Printf("%v\n", i)
  }()
}

i := i可能看起來有點奇怪，但它完全有效。

因為處於迴圈中意味著處於另一個作用域內，所以i := i相當於建立了另一個名為i的變數例項。

當然，為了便於閱讀，最好使用不同的變數名稱。

延伸閱讀

Using goroutines on loop iterator variables

你還想提到其他常見的錯誤嗎？請隨意分享，繼續討論