golang中經常會犯的一些錯誤

slowquery發表於2022-09-25

0.1、索引

1、未知的列舉值

我們現在定義一個型別是unit32的Status，他可以作為列舉型別，我們定義了3種狀態

type Status uint32

const (
    StatusOpen Status = iota
    StatusClosed
    StatusUnknown
)

其中我們使用了iota，相關的用法自行google。最終對應的狀態就是：

0-開啟狀態，1-關閉狀態，2-未知狀態

現在我們假設有一個請求引數過來，資料結構如下：

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

可以看到是一個json型別的字串，其中就包含了Status狀態，我們的請求是希望把狀態修改為關閉狀態。

然後我們在服務端建立一個結構體，方便把這些欄位解析出來：

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

好了，我們在main中執行下程式碼，看下解析是否正確：

package main

import (
    "encoding/json"
    "fmt"
)

type Status uint32

const (
    StatusOpen Status = iota
    StatusClosed
    StatusUnknown
)

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

func main() {
    js := `{
        "Id": 1234,
        "Timestamp": 1563362390,
        "Status": 1
      }`

    request := &Request{}
    err := json.Unmarshal([]byte(js), request)
    if err != nil {
        fmt.Println(err)
        return
    }
}

執行後的結果如下：

go run main.go
&{1234 1563362390 1}

可以看到解析是沒問題的。

然而，讓我們再提出一個未設定狀態值的請求（無論出於何種原因）：

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

在這種情況下，請求結構的狀態欄位將被初始化為其零值（對於 uint32 型別：0）。因此，StatusOpen 而不是 StatusUnknown。

最佳實踐是將列舉的未知值設定為 0：

type Status uint32

const (
    StatusUnknown Status = iota
    StatusOpen
    StatusClosed
)

在這裡，如果狀態不是 JSON 請求的一部分，它將被初始化為 StatusUnknown，正如我們所期望的那樣。

2、指標無處不在？

按值傳遞變數將建立此變數的副本。而透過指標傳遞它只會複製記憶體地址。

因此，傳遞指標總是會更快，對麼？

如果你相信這一點，請看看這個例子。這是一個 0.3 KB 資料結構的基準測試，我們透過指標和值傳遞和接收。 0.3 KB 並不大，但這與我們每天看到的資料結構型別（對於我們大多數人來說）應該相差不遠。

當我在本地環境中執行這些基準測試時，按值傳遞比按指標傳遞快 4 倍以上。這可能有點違反直覺，對吧？

這其實與 Go 中如何管理記憶體有關。我們都知道變數可以分配在堆上或棧上，也知道：

棧包含給定 goroutine 的正在進行的變數。一旦函式返回，變數就會從堆疊中彈出。
堆包含共享變數（全域性變數等）。

讓我們看下下面這個簡單的例子：

type foo struct{}

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

這裡，一個結果變數由當前的 goroutine 建立。這個變數被壓入當前堆疊。一旦函式返回，客戶端將收到此變數的副本。變數本身從堆疊中彈出。它仍然存在於記憶體中，直到它被另一個變數擦除，但它不能再被訪問。

我們現在修改下上面的例子，使用指標：

type foo struct{}

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

結果變數仍然由當前的 goroutine 建立，但客戶端將收到一個指標（變數地址的副本）。如果結果變數從堆疊中彈出，則此函式的客戶端無法再訪問它。

在這種情況下，Go 編譯器會將結果變數轉移到可以共享變數的地方：堆。

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

type foo struct{}

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

因為我們在同一個 goroutine 中呼叫 f，所以 p 變數不需要被轉移。它只是被壓入堆疊，子函式可以訪問它。

比如在 io.Reader 的 Read 方法中接收切片而不是返回切片的直接結果，也不會轉移到堆上。

但是返回一個切片（它是一個指標）會將其轉移到堆中。

為什麼堆疊那麼快？主要原因有兩個：

堆疊不需要垃圾收集器。正如我們所說，一個變數在建立後被簡單地壓入，然後在函式返回時從堆疊中彈出。無需進行復雜的過程來回收未使用的變數等。
堆疊屬於一個 goroutine，因此與將變數儲存在堆上相比，儲存變數不需要同步。這也導致效能增益。

結論就是：

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

最後：

如果我們遇到效能問題，一種可能的最佳化可能是檢查指標在某些特定情況下是否有幫助。使用以下命令可以知道編譯器何時將變數轉移到堆中：go build -gcflags “-m -m”。（記憶體逃逸）

3、中斷 for/switch 或 for/select

我們看下下面的程式碼會發生什麼：

package main

func f() bool {
    return true
}

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

我們將呼叫 break 語句。但是，這會破壞 switch 語句，而不是 for 迴圈。

相同的情況還會出現在fo/select中，像下面這樣：

package main

import (
    "context"
    "time"
)

func main() {
    ch := make(chan struct{})
    ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
    defer cancel()
    for {
        select {
        case <-ch:
        // Do something
        case <-ctx.Done():
            break
        }
    }
}

雖然呼叫了break，但是還是會陷入死迴圈。break 與 select 語句有關，與 for 迴圈無關。

打破 for/switch 或 for/select 的，一種方案是直接return結束整個函式，下面如果還有程式碼不會被執行。

package main

import (
    "context"
    "fmt"
    "time"
)

func main() {
    ch := make(chan struct{})
    ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
    defer cancel()
    for {
        select {
        case <-ch:
        // Do something
        case <-ctx.Done():
            return
        }
    }

  // 這裡不會執行
    fmt.Println("done")
}

還有一種方案是使用中斷標記

package main

import (
    "context"
    "fmt"
    "time"
)

func main() {
    ch := make(chan struct{})
    ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
    defer cancel()
loop:
    for {
        select {
        case <-ch:
        // Do something
        case <-ctx.Done():
            break loop
        }
    }

  // 會繼續往下執行
    fmt.Println("done")
}

4、錯誤管理

一個錯誤應該只處理一次。記錄錯誤就是處理錯誤。因此，應該記錄或傳播錯誤。

我們可能希望為錯誤新增一些上下文並具有某種形式的層次結構。

讓我們看一個介面請求資料庫的例子，我們分為介面層，service層和類庫層。我們希望返回的層次結構像下面這樣：

unable to serve HTTP POST request for id 1
 |_ unable to insert customer
     |_ unable to commit transaction

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

package main

import (
    "fmt"

    "github.com/pkg/errors"
)

func postHandler(id int) string {
    err := insert(id)
    if err != nil {
        fmt.Printf("unable to serve HTTP POST request for id %d\n", id)
        return `{ok: false}`
    }
    return `{ok: true}`
}

func insert(id int) error {
    err := dbQuery(id)
    if err != nil {
        return errors.Wrapf(err, "unable to insert customer")
    }
    return nil
}

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

func main() {
    res := postHandler(1)
    fmt.Println(res)
}

初始錯誤（如果不是由外部庫返回）可以使用 errors.New 建立。service層 insert 透過向其新增更多上下文來包裝此錯誤。然後，介面層透過記錄錯誤來處理錯誤。每個級別都返回或處理錯誤。

例如，我們可能還想檢查錯誤原因本身以實現重試。假設我們有一個來自處理資料庫訪問的外部庫的 db 包。這個庫可能會返回一個名為 db.DBError 的暫時（臨時）錯誤。要確定是否需要重試，我們必須檢查錯誤原因：

package main

import (
    "fmt"

    "github.com/pkg/errors"
)

type DbError struct {
    msg string
}

func (e *DbError) Error() string {
    return e.msg
}

func postHandler(id int) string {
    err := insert(id)
    if err != nil {
        errCause := errors.Cause(err)
        if _, ok := errCause.(*DbError); ok {
            fmt.Println("retry")
        } else {
            fmt.Printf("unable to serve HTTP POST request for id %d\n", id)
            return `{ok: false}`
        }

    }
    return `{ok: true}`
}

func insert(id int) error {
    err := dbQuery(id)
    if err != nil {
        return errors.Wrapf(err, "unable to insert customer")
    }
    return nil
}

func dbQuery(id int) error {
    // Do something then fail
    return &DbError{"unable to commit transaction"}
}

func main() {
    res := postHandler(1)
    fmt.Println(res)
}

這是使用errors.Cause完成的，它也來自pkg/errors。（可以透過errors.Cause檢查。 errors.Cause 將遞迴檢索沒有實現causer 的最頂層錯誤，這被認為是原始原因。）

有時候也會有人這麼用。例如，檢查錯誤是這樣完成的：

package main

import (
    "fmt"

    "github.com/pkg/errors"
)

type DbError struct {
    msg string
}

func (e *DbError) Error() string {
    return e.msg
}

func postHandler(id int) string {
    err := insert(id)
    if err != nil {
        switch err.(type) {
        default:
            fmt.Printf("unable to serve HTTP POST request for id %d\n", id)
            return `{ok: false}`
        case *DbError:
            fmt.Println("retry")

        }
    }
    return `{ok: true}`
}

func insert(id int) error {
    err := dbQuery(id)
    if err != nil {
        return errors.Wrapf(err, "unable to insert customer")
    }
    return nil
}

func dbQuery(id int) error {
    // Do something then fail
    return &DbError{"unable to commit transaction"}
}

func main() {
    res := postHandler(1)
    fmt.Println(res)
}

如果 DBError 被包裝，它永遠不會觸發重試。

5、切片初始化

有時，我們知道切片的最終長度是多少。例如，假設我們要將 Foo 的切片轉換為 Bar 的切片，這意味著這兩個切片將具有相同的長度。

我們有時候經常會這樣初始化切片：

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

我們都知道切片的底層是陣列。如果沒有更多可用空間，它會實施增長戰略。在這種情況下，會自動建立一個新陣列（容量更大）並複製所有元素。

現在，假設我們需要多次重複這個增長操作，因為我們的 []Foo 包含數千個元素？插入的攤銷時間複雜度（平均值）將保持為 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
}

選哪個更好呢？第一個稍微快一點。然而，你可能更喜歡第二個，因為無論我們是否知道初始大小，在切片末尾新增一個元素都是使用 append 完成的。

6、上下文管理

context.Context對我們來說非常好用，他可以在協程之間傳遞資料、可以控制協程的生命週期等等。但是這也造成了它的濫用。

go官方文件是這麼定義的：

==一個 Context 攜帶一個截止日期、一個取消訊號和其他跨 API 邊界的值。==

這個描述很寬泛，足以讓一些人對為什麼以及如何使用它感到困惑。

讓我們試著詳細說明一下。上下文可以攜帶：

一個截止時間。它意味著一個持續時間（例如 250 毫秒）或日期時間（例如 2022-01-08 01:00:00），我們認為如果達到，我們必須取消正在進行的活動（I/O 請求，等待通道輸入等）。
取消訊號（基本上是 <-chan struct{}）。在這裡，行為是相似的。一旦我們收到訊號，我們必須停止正在進行的活動。例如，假設我們收到兩個請求。一個插入一些資料，另一個取消第一個請求（因為它不再需要）。這可以透過在第一次呼叫中使用可取消上下文來實現，一旦我們收到第二個請求，該上下文將被取消。
鍵/值列表（均基於 interface{} 型別）。

另外需要說明的是。

首先，上下文是可組合的。因此，我們可以有一個包含截止日期和鍵/值列表的上下文。

此外，多個 goroutine 可以共享相同的上下文，因此取消訊號可能會停止多個活動。

我們可以看下一個具體的錯誤例子

一個 Go 應用程式是基於 urfave/cli 的（如果你不知道，那是一個在 Go 中建立命令列應用程式的好庫）。一旦開始，開發人員就會繼承某種應用程式上下文。這意味著當應用程式停止時，庫將使用此上下文傳送取消訊號。

我瞭解的是，這個上下文是在呼叫 gRPC 端點時直接傳遞的。這不是我們想要做的。

相反，我們想向 gRPC 庫傳遞：請在應用程式停止時或在 100 毫秒後取消請求。

為此，我們可以簡單地建立一個組合上下文。如果 parent 是應用程式上下文的名稱（由 urfave/cli 建立），那麼我們可以簡單地這樣做：

package main

import (
    "context"
    "fmt"
    "log"
    "os"
    "time"

    "github.com/urfave/cli/v2"
)

func main() {

    app := &cli.App{
        Name:  "boom",
        Usage: "make an explosive entrance",
        Action: func(parent *cli.Context) error {
      // 父上下文傳進來，給個超時時間
            ctx, cancel := context.WithTimeout(parent.Context, 10*time.Second)
            defer cancel()
            grpcClientSend(ctx)

            return nil
        },
    }

    if err := app.Run(os.Args); err != nil {
        log.Fatal(err)
    }
}

func grpcClientSend(ctx context.Context) {
    for {
        select {
        case <-ctx.Done(): // 達到超時時間就結束
            fmt.Println("cancel!")
            return
        default:
            time.Sleep(2 * time.Second)
            fmt.Println("do something!")
        }
    }
}

7、使用檔名作為函式輸入？

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

package main

import (
    "bufio"
    "fmt"
    "os"

    "github.com/pkg/errors"
)

func main() {

    cou, err := count("a.txt")
    if err != nil {
        fmt.Println(err)
        return
    }
    fmt.Println(cou)
}

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
}

檔名作為輸入給出，所以我們開啟它然後我們實現我們的邏輯，對吧？

現在，假設我們要在此函式之上實現單元測試，以測試普通檔案、空檔案、具有不同編碼型別的檔案等。這很容易變得非常難以管理。

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

Go 帶有兩個很棒的抽象：io.Reader 和 io.Writer。我們可以簡單地傳遞一個 io.Reader 來抽象資料來源，而不是傳遞檔名。

是檔案嗎？ HTTP body？位元組緩衝區？這並不重要，因為我們仍將使用相同的 Read 方法。

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

我們把讀取檔案的部分放到函式外面

package main

import (
    "bufio"
    "fmt"
    "io"
    "os"

    "github.com/pkg/errors"
)

func main() {

    filename := "a.txt"
    file, err := os.Open(filename)
    if err != nil {
        fmt.Println(err, "unable to open ", filename)
        return
    }
    defer file.Close()
    count, err := count(bufio.NewReader(file))
    if err != nil {
        fmt.Println(err)
        return
    }
    fmt.Println(count)
}

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++
        }
    }
}

使用第二種實現，無論實際資料來源如何，都可以呼叫該函式。同時，這將有助於我們的單元測試，因為我們可以簡單地從字串建立一個 bufio.Reader：

package main

import (
    "bufio"
    "fmt"
    "io"
    "strings"

    "github.com/pkg/errors"
)

func main() {

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

    if err != nil {
        fmt.Println(err)
        return
    }
    fmt.Println(count)
}

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++
        }
    }
}

8、Goroutines 和迴圈變數

我看到一個常見錯誤是使用帶有迴圈變數的 goroutines。

以下示例的輸出是什麼？

package main

import (
    "fmt"
    "time"
)

func main() {

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

    time.Sleep(time.Second)
}

在這個例子中，每個 goroutine 共享相同的變數例項，所以它會產生 3 3 3。而不是我們認為的1 2 3

有兩種解決方案可以解決這個問題。第一個是將 i 變數的值傳遞給閉包（內部函式）：

package main

import (
    "fmt"
    "time"
)

func main() {

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

    time.Sleep(time.Second)
}

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

package main

import (
    "fmt"
    "time"
)

func main() {

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

    time.Sleep(time.Second)
}

呼叫 i := i 可能看起來有點奇怪，但它完全有效。處於迴圈中意味著處於另一個範圍內。所以 i := i 建立了另一個名為 i 的變數例項。當然，為了便於閱讀，我們可能想用不同的名稱來稱呼它。

原文
itnext.io/the-top-10-most-common-m...

本作品採用《CC 協議》，轉載必須註明作者和本文連結

連結串列作業中犯的一些錯誤
2020-12-03
寶鯤財經：外匯交易中不能犯的幾點錯誤
2018-08-27
Rxjs SwitchMap 的一些容易犯的錯誤和替代方案
2022-04-29
JS
工程師犯的最大錯誤？
2022-02-04
工程師
Golang開發常見的57個錯誤
2022-02-22
Golang
android開發中犯的小錯誤，不要學我！
2021-09-09
Android
這些常見的 Go 編碼錯誤，你犯過嗎（一）？
2022-05-16
Go
你會犯這些 Go 編碼錯誤嗎（二）？
2022-05-22
Go
90%的Java開發人員都會犯的5個錯誤
2022-12-28
Java
15個常見網站開發錯誤，誰都可能犯
2023-09-24
網站
macOS小白容易犯的24個錯誤
2020-10-13
Mac
Golang 學習筆記八錯誤異常
2019-01-20
Golang筆記
這些錯誤你都犯過嗎？來看看9大XMind初學者常見錯誤！
2019-04-03
5 個 Linux 新手會犯的失誤
2019-06-09
Linux
邦芒簡歷：簡歷中不能犯的8個錯誤
2023-11-27
更好的前端設計形式——設計者犯的常見錯誤及修改方法
2018-08-20
前端
開發時犯得小錯誤
2018-05-07
很多人容易犯的面試錯誤
2024-06-17
面試
使用 Kubernetes 最容易犯的 10 個錯誤！
2020-09-29
go新手容易犯的三個致命錯誤
2019-02-16
Go
Mark W3C測試中我犯得錯誤
2020-04-04
ionic 開發中的一些錯誤
2019-01-15
Python最容易犯的錯誤，一定要警惕！
2023-02-16
Python
Java初學者容易犯的程式碼錯誤
2019-01-24
Java
Java初學者容易犯哪些錯誤?
2020-08-04
Java
Include檔案易犯編譯錯誤
2020-04-07
編譯
公司為變得敏捷而犯的10大錯誤
2022-07-28
敏捷
Python新手入門最容易犯的錯誤有哪些?
2019-11-06
Python
Java 開發者最容易犯的10個錯誤
2019-01-06
Java
前端開發最容易犯的13個JavaScript錯誤
2018-07-11
前端JavaScript
十個PHP開發者最容易犯的錯誤
2018-04-02
PHP
淺析php中的異常與錯誤
2019-02-16
PHP
【常見錯誤】--Nltk使用錯誤
2018-09-13
記一次因為共享變數的犯錯誤
2020-10-16
變數
Spring In Action 5th中的一些錯誤
2020-10-22
Spring
web前端小白經常出現“四”個錯誤
2019-10-21
Web前端
Java程式設計師可能會犯的幾個錯誤, 看看你是不是躺槍了?
2018-12-16
Java程式設計師
總結一些，書寫 CSS 的時候，經常犯的錯誤！
2023-01-23
CSS