真实的国产乱ⅩXXX66竹夫人,五月香六月婷婷激情综合,亚洲日本VA一区二区三区,亚洲精品一区二区三区麻豆

成都創(chuàng)新互聯(lián)網(wǎng)站制作重慶分公司

golang中經(jīng)常會犯的一些錯誤

0.1、索引

https://waterflow.link/articles/

創(chuàng)新互聯(lián)專注于三亞企業(yè)網(wǎng)站建設,響應式網(wǎng)站開發(fā),商城系統(tǒng)網(wǎng)站開發(fā)。三亞網(wǎng)站建設公司,為三亞等地區(qū)提供建站服務。全流程按需網(wǎng)站策劃，專業(yè)設計，全程項目跟蹤，創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務

1、未知的枚舉值

我們現(xiàn)在定義一個類型是unit32的Status，他可以作為枚舉類型，我們定義了3種狀態(tài)

type Status uint32

const (
	StatusOpen Status = iota
	StatusClosed
	StatusUnknown
)

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

0-開啟狀態(tài)，1-關閉狀態(tài)，2-未知狀態(tài)

現(xiàn)在我們假設有一個請求參數(shù)過來，數(shù)據(jù)結構如下：

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

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

然后我們在服務端創(chuàng)建一個結構體，方便把這些字段解析出來：

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

好了，我們在main中執(zhí)行下代碼，看下解析是否正確：

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": ,
		"Status": 1
	  }`

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

執(zhí)行后的結果如下：

go run main.go
&{1234  1}

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

然而，讓我們再提出一個未設置狀態(tài)值的請求（無論出于何種原因）：

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

在這種情況下，請求結構的狀態(tài)字段將被初始化為其零值（對于 uint32 類型：0）。因此，StatusOpen 而不是 StatusUnknown。

最佳實踐是將枚舉的未知值設置為 0：

type Status uint32

const (
	StatusUnknown Status = iota
	StatusOpen
	StatusClosed
)

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

2、指針無處不在？

按值傳遞變量將創(chuàng)建此變量的副本。而通過指針傳遞它只會復制內(nèi)存地址。

因此，傳遞指針總是會更快，對么？

如果你相信這一點，請看看這個例子。這是一個 0.3 KB 數(shù)據(jù)結構的基準測試，我們通過指針和值傳遞和接收。 0.3 KB 并不大，但這與我們每天看到的數(shù)據(jù)結構類型（對于我們大多數(shù)人來說）應該相差不遠。

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

這其實與 Go 中如何管理內(nèi)存有關。我們都知道變量可以分配在堆上或棧上，也知道：

  • 棧包含給定 goroutine 的正在進行的變量。一旦函數(shù)返回，變量就會從堆棧中彈出。
  • 堆包含共享變量（全局變量等）。

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

type foo struct{}

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

這里，一個結果變量由當前的 goroutine 創(chuàng)建。這個變量被壓入當前堆棧。一旦函數(shù)返回，客戶端將收到此變量的副本。變量本身從堆棧中彈出。它仍然存在于內(nèi)存中，直到它被另一個變量擦除，但它不能再被訪問。

我們現(xiàn)在修改下上面的例子，使用指針：

type foo struct{}

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

結果變量仍然由當前的 goroutine 創(chuàng)建，但客戶端將收到一個指針（變量地址的副本）。如果結果變量從堆棧中彈出，則此函數(shù)的客戶端無法再訪問它。

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

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

type foo struct{}

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

因為我們在同一個 goroutine 中調(diào)用 f，所以 p 變量不需要被轉(zhuǎn)移。它只是被壓入堆棧，子函數(shù)可以訪問它。

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

但是返回一個切片（它是一個指針）會將其轉(zhuǎn)移到堆中。

為什么堆棧那么快？主要原因有兩個：

  • 堆棧不需要垃圾收集器。正如我們所說，一個變量在創(chuàng)建后被簡單地壓入，然后在函數(shù)返回時從堆棧中彈出。無需進行復雜的過程來回收未使用的變量等。
  • 堆棧屬于一個 goroutine，因此與將變量存儲在堆上相比，存儲變量不需要同步。這也導致性能增益。

結論就是：

當我們創(chuàng)建一個函數(shù)時，我們的默認行為應該是使用值而不是指針。僅當我們想要共享變量時才應使用指針。

最后：

如果我們遇到性能問題，一種可能的優(yōu)化可能是檢查指針在某些特定情況下是否有幫助。使用以下命令可以知道編譯器何時將變量轉(zhuǎn)移到堆中：go build -gcflags "-m -m"。（內(nèi)存逃逸）

3、中斷 for/switch 或 for/select

我們看下下面的代碼會發(fā)生什么：

package main

func f() bool {
	return true
}

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

我們將調(diào)用 break 語句。但是，這會破壞 switch 語句，而不是 for 循環(huán)。

相同的情況還會出現(xiàn)在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
		}
	}
}

雖然調(diào)用了break，但是還是會陷入死循環(huán)。break 與 select 語句有關，與 for 循環(huán)無關。

打破 for/switch 或 for/select 的，一種方案是直接return結束整個函數(shù)，下面如果還有代碼不會被執(zhí)行。

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

  // 這里不會執(zhí)行
	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
		}
	}

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

4、錯誤管理

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

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

讓我們看一個接口請求數(shù)據(jù)庫的例子，我們分為接口層，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 創(chuàng)建。service層 insert 通過向其添加更多上下文來包裝此錯誤。然后，接口層通過記錄錯誤來處理錯誤。每個級別都返回或處理錯誤。

例如，我們可能還想檢查錯誤原因本身以實現(xiàn)重試。假設我們有一個來自處理數(shù)據(jù)庫訪問的外部庫的 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 將遞歸檢索沒有實現(xiàn)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 被包裝，它永遠不會觸發(fā)重試。

5、切片初始化

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

我們有時候經(jīng)常會這樣初始化切片：

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

我們都知道切片的底層是數(shù)組。如果沒有更多可用空間，它會實施增長戰(zhàn)略。在這種情況下，會自動創(chuàng)建一個新數(shù)組（容量更大）并復制所有元素。

現(xiàn)在，假設我們需要多次重復這個增長操作，因為我們的 []Foo 包含數(shù)千個元素？插入的攤銷時間復雜度（平均值）將保持為 O(1)，但在實踐中，它會對性能產(chǎn)生影響。

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

  • 使用預定義的長度對其進行初始化：

    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對我們來說非常好用，他可以在協(xié)程之間傳遞數(shù)據(jù)、可以控制協(xié)程的生命周期等等。但是這也造成了它的濫用。

go官方文檔是這么定義的：

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

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

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

  • 一個截止時間。它意味著一個持續(xù)時間（例如 250 毫秒）或日期時間（例如 2022-01-08 01:00:00），我們認為如果達到，我們必須取消正在進行的活動（I/O 請求，等待通道輸入等）。
  • 取消信號（基本上是 <-chan struct{}）。 在這里，行為是相似的。 一旦我們收到信號，我們必須停止正在進行的活動。 例如，假設我們收到兩個請求。 一個插入一些數(shù)據(jù)，另一個取消第一個請求（因為它不再需要）。 這可以通過在第一次調(diào)用中使用可取消上下文來實現(xiàn)，一旦我們收到第二個請求，該上下文將被取消。
  • 鍵/值列表（均基于 interface{} 類型）。

另外需要說明的是。

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

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

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

一個 Go 應用程序是基于 urfave/cli 的（如果你不知道，那是一個在 Go 中創(chuàng)建命令行應用程序的好庫）。一旦開始，開發(fā)人員就會繼承某種應用程序上下文。這意味著當應用程序停止時，庫將使用此上下文發(fā)送取消信號。

我了解的是，這個上下文是在調(diào)用 gRPC 端點時直接傳遞的。這不是我們想要做的。

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

為此，我們可以簡單地創(chuàng)建一個組合上下文。如果 parent 是應用程序上下文的名稱（由 urfave/cli 創(chuàng)建），那么我們可以簡單地這樣做：

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、使用文件名作為函數(shù)輸入？

假設我們必須實現(xiàn)一個函數(shù)來計算文件中的空行數(shù)。一般我們是這樣實現(xiàn)的：

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
}

文件名作為輸入給出，所以我們打開它然后我們實現(xiàn)我們的邏輯，對吧？

現(xiàn)在，假設我們要在此函數(shù)之上實現(xiàn)單元測試，以測試普通文件、空文件、具有不同編碼類型的文件等。這很容易變得非常難以管理。

此外，如果我們想要對http body實現(xiàn)相同的邏輯，我們將不得不為此創(chuàng)建另一個函數(shù)。

Go 帶有兩個很棒的抽象：io.Reader 和 io.Writer。我們可以簡單地傳遞一個 io.Reader 來抽象數(shù)據(jù)源，而不是傳遞文件名。

是文件嗎？ HTTP body？字節(jié)緩沖區(qū)？這并不重要，因為我們?nèi)詫⑹褂孟嗤?Read 方法。

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

我們把讀取文件的部分放到函數(shù)外面

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

使用第二種實現(xiàn)，無論實際數(shù)據(jù)源如何，都可以調(diào)用該函數(shù)。同時，這將有助于我們的單元測試，因為我們可以簡單地從字符串創(chuàng)建一個 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 和循環(huán)變量

我看到一個常見錯誤是使用帶有循環(huán)變量的 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 共享相同的變量實例，所以它會產(chǎn)生 3 3 3。而不是我們認為的1 2 3

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

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 循環(huán)范圍內(nèi)創(chuàng)建另一個變量：

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

調(diào)用 i := i 可能看起來有點奇怪，但它完全有效。處于循環(huán)中意味著處于另一個范圍內(nèi)。所以 i := i 創(chuàng)建了另一個名為 i 的變量實例。當然，為了便于閱讀，我們可能想用不同的名稱來稱呼它。

原文
https://itnext.io/the-top-10-most-common-mistakes-ive-seen-in-go-projects-4b79d4f6cd65


當前題目：golang中經(jīng)常會犯的一些錯誤
文章位置：http://weahome.cn/article/dsoicoo.html

其他資訊

在線咨詢

微信咨詢

電話咨詢

028-86922220（工作日）

18980820575（7×24）

提交需求

返回頂部