Go1.18新特性工作區(qū)模糊測(cè)試及泛型的使用詳解

更新時(shí)間：2022年07月19日 14:18:25 作者：字節(jié)跳動(dòng)技術(shù)團(tuán)隊(duì)

這篇文章主要為大家介紹了Go?1.18新特性中的工作區(qū)?模糊測(cè)試?泛型使用進(jìn)行詳細(xì)講解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪

類型統(tǒng)一化（Type Unification）
函數(shù)參數(shù)類型推導(dǎo)（Function Argument Type Inference）
推導(dǎo)算法與示例
約束類型推導(dǎo)（Constraints Type Inference）
推導(dǎo)算法與示例
簡(jiǎn)單的例子
一個(gè)更復(fù)雜的例子
使用約束類型推導(dǎo)保存類型信息

泛型的使用局限

成員函數(shù)無(wú)法使用泛型
無(wú)法使用約束定義之外的方法
無(wú)法使用成員變量

總結(jié)

前言

2022年3月15日，Google發(fā)布了萬(wàn)眾矚目的Golang 1.18，帶來(lái)了好幾個(gè)重大的新特性，包括：

解決本地同時(shí)開發(fā)多個(gè)倉(cāng)庫(kù)帶來(lái)的一些問題的工作區(qū)（Workspace）
能夠自動(dòng)探測(cè)代碼分支，隨機(jī)生成輸入，并且檢查代碼是否會(huì)panic的模糊測(cè)試（Fuzzing Test）
眾多開發(fā)者盼星星盼月亮終于等到的泛型支持。

本文將簡(jiǎn)單講述這三個(gè)特性的相關(guān)內(nèi)容。

Go工作區(qū)模式（Go Workspace Mode）

現(xiàn)實(shí)的情況

多倉(cāng)庫(kù)同時(shí)開發(fā)

在實(shí)際的開發(fā)工作中，我們經(jīng)常會(huì)同時(shí)修改存在依賴關(guān)系的多個(gè)module，例如在某個(gè)service模塊上實(shí)現(xiàn)需求的同時(shí)，也需要對(duì)項(xiàng)目組的某個(gè)common模塊做出修改，整個(gè)的工作流就會(huì)變成下面這樣：

可以看到，每次修改Common庫(kù)，都需要將代碼push到遠(yuǎn)端，然后再修改本地service倉(cāng)庫(kù)的依賴，再通過(guò)go mod tidy從遠(yuǎn)端拉取Common代碼，不可謂不麻煩。

有些同學(xué)可能會(huì)問了，這種情況，在service倉(cāng)庫(kù)的go.mod中添加一條replace不就能夠解決嗎？

但是，如果在go.mod中使用replace，在維護(hù)上需要付出額外的心智成本，萬(wàn)一將帶有replace的go.mod推到遠(yuǎn)端代碼庫(kù)了，其他同學(xué)不就一臉懵逼了？

多個(gè)新倉(cāng)庫(kù)開始開發(fā)

假設(shè)此時(shí)我正在開發(fā)兩個(gè)新的模塊，分別是：

code.byted.org/SomeNewProject/Common
code.byted.org/SomeNewProject/MyService

并且MyService依賴于Common。

在開發(fā)過(guò)程中，出于各種原因，有可能不會(huì)立即將代碼推送到遠(yuǎn)端，那么此時(shí)假設(shè)我需要本地編譯MyService，就會(huì)出現(xiàn)go build（或者go mod tidy）自動(dòng)下載依賴失敗，因?yàn)榇藭r(shí)Common庫(kù)根本就沒有發(fā)布到代碼庫(kù)中。

出于和上述“多倉(cāng)庫(kù)同時(shí)開發(fā)”相同的理由，replace也不應(yīng)該被添加到MyService的go.mod文件中。

工作區(qū)模式是什么

Go工作區(qū)模式最早出現(xiàn)于Go開發(fā)者M(jìn)ichael Matloob在2021年4月提出的一個(gè)名為“Multi-Module Workspaces in cmd/go”的提案。

這個(gè)提案中提出，新增一個(gè)go.work文件，并且在這個(gè)文件中指定一系列的本地路徑，這些本地路徑下的go module共同構(gòu)成一個(gè)工作區(qū)（workspace），go命令可以操作這些路徑下的go module，在編譯時(shí)也會(huì)優(yōu)先使用這些go module。

使用如下命令就可以初始化一個(gè)工作區(qū)，并且生成一個(gè)空的go.work文件：

go work init .

新生成的go.work文件內(nèi)容如下：

go 1.18
directory ./.

go.work文件中，directory指示了工作區(qū)的各個(gè)module目錄，在編譯代碼時(shí)，會(huì)優(yōu)先使用同一個(gè)workspace下的module。

在go.work中，也支持使用replace來(lái)指定使用本地代碼庫(kù)，但在大多數(shù)情況下，更好的做法是將依賴的本地代碼庫(kù)的路徑加入directory中。

使用時(shí)的注意點(diǎn)

目前（go 1.18）僅go build會(huì)對(duì)go.work做出判斷，而go mod tidy并不care Go工作區(qū)。

Go模糊測(cè)試（Go Fuzzing Test）

為什么Golang要支持模糊測(cè)試

從1.18起，模糊測(cè)試（Fuzzing Test）作為語(yǔ)言安全的一環(huán)，加入了Golang的testing標(biāo)準(zhǔn)庫(kù)。Golang加入模糊測(cè)試的原因非常明顯：安全是程序員在構(gòu)建軟件的過(guò)程中必不可少且日益重要的考量因素。

Golang至今為止，已經(jīng)在保障語(yǔ)言安全方面提供了很多的特性和工具，例如強(qiáng)制使用顯式類型轉(zhuǎn)換、禁止隱式類型轉(zhuǎn)換、對(duì)數(shù)組與切片的越界訪問檢查、通過(guò)go.sum對(duì)依賴包進(jìn)行哈希校驗(yàn)等等。

在進(jìn)入云原生時(shí)代之后，Golang成為了云原生基礎(chǔ)設(shè)施與服務(wù)的頭部語(yǔ)言之一。這些系統(tǒng)對(duì)安全性的要求自然不言而喻。尤其是針對(duì)用戶的輸入，不被用戶的輸入弄出處理異常、崩潰、被操控是對(duì)這些系統(tǒng)的基本要求之一。

這就要求我們的系統(tǒng)在處理任何用戶輸入的時(shí)候都能保持穩(wěn)定，但是傳統(tǒng)的質(zhì)量保障手段，例如Code Review、靜態(tài)分析、人工測(cè)試、Unit Test等等，在面對(duì)日益復(fù)雜的系統(tǒng)時(shí)，自然就無(wú)法窮盡所有可能的輸入組合，尤其是一些非常不明顯的corner case。

而模糊測(cè)試就是業(yè)界在解決這方面問題的優(yōu)秀實(shí)踐之一，Golang選擇支持它也就不難理解了。

模糊測(cè)試是什么

模糊測(cè)試是一種通過(guò)數(shù)據(jù)構(gòu)造引擎，輔以開發(fā)者可以提供的一些初始數(shù)據(jù)，自動(dòng)構(gòu)造出一些隨機(jī)數(shù)據(jù)，作為對(duì)程序的輸入來(lái)進(jìn)行測(cè)試的一種方式。模糊測(cè)試可以幫助開發(fā)人員發(fā)現(xiàn)難以發(fā)現(xiàn)的穩(wěn)定性、邏輯性甚至是安全性方面的錯(cuò)誤，特別是當(dāng)被測(cè)系統(tǒng)變得更加復(fù)雜時(shí)。

模糊測(cè)試在具體的實(shí)現(xiàn)上，通?？梢圆灰蕾囉陂_發(fā)測(cè)試人員定義好的數(shù)據(jù)集，取而代之的則是一組通過(guò)數(shù)據(jù)構(gòu)造引擎自行構(gòu)造的一系列隨機(jī)數(shù)據(jù)。模糊測(cè)試會(huì)將這些數(shù)據(jù)作為輸入提供給待測(cè)程序，并且監(jiān)測(cè)程序是否出現(xiàn)panic、斷言失敗、無(wú)限循環(huán)，或者其他什么異常情況。這些通過(guò)數(shù)據(jù)構(gòu)造引擎生成的數(shù)據(jù)被稱為語(yǔ)料（corpus） 。另外模糊測(cè)試其實(shí)也是一種持續(xù)測(cè)試的手段，因?yàn)槿绻幌拗茍?zhí)行的次數(shù)或者執(zhí)行的最大時(shí)間，它就會(huì)一直不停的執(zhí)行下去。

Golang的模糊測(cè)試由于被實(shí)現(xiàn)在了編譯器工具鏈中，所以采用了一種名為“覆蓋率引導(dǎo)的fuzzing”的入?yún)⑸杉夹g(shù)，大致運(yùn)行過(guò)程如下：

Golang的模糊測(cè)試如何使用

Golang的模糊測(cè)試在使用時(shí)，可以簡(jiǎn)單地直接使用，也可以自己提供一些初始的語(yǔ)料。

最簡(jiǎn)單的實(shí)踐例子

模糊測(cè)試的函數(shù)也是放在xxx_test.go里的，編寫一個(gè)最簡(jiǎn)單的模糊測(cè)試?yán)樱黠@的除0錯(cuò)誤）：

package main
import "testing"
import "fmt"
func FuzzDiv(f *testing.F) {
        f.Fuzz(func(t *testing.T, a, b int) {
                fmt.Println(a/b)
        })
}

可以看到類似于單元測(cè)試，模糊測(cè)試的函數(shù)名都是FuzzXxx格式，且接受一個(gè)testing.F指針對(duì)象。

然后在函數(shù)中使用f.Fuzz對(duì)指定的函數(shù)進(jìn)行模糊測(cè)試，被測(cè)試的函數(shù)的第一個(gè)參數(shù)必須是“*testing.T”類型，后面可以跟任意多個(gè)基本類型的參數(shù)。

編寫完成之后，使用這樣的命令來(lái)啟動(dòng)模糊測(cè)試：

go test -fuzz .

模糊測(cè)試默認(rèn)會(huì)一直進(jìn)行下去，只要被測(cè)試的函數(shù)不panic不出錯(cuò)?？梢酝ㄟ^(guò)“-fuzztime”選項(xiàng)來(lái)限制模糊測(cè)試的時(shí)間：

go test -fuzztime 10s -fuzz .

使用模糊測(cè)試對(duì)上述代碼進(jìn)行測(cè)試時(shí)，會(huì)碰到產(chǎn)生panic的情況，此時(shí)模糊測(cè)試會(huì)輸出如下信息：

warning: starting with empty corpus
fuzz: elapsed: 0s, execs: 0 (0/sec), new interesting: 0 (total: 0)
fuzz: elapsed: 0s, execs: 1 (65/sec), new interesting: 0 (total: 0)
--- FAIL: FuzzDiv (0.02s)
--- FAIL: FuzzDiv (0.00s)
testing.go:1349: panic: runtime error: integer divide by zero
goroutine 11 [running]:
runtime/debug.Stack()
/Users/bytedance/.mytools/go/src/runtime/debug/stack.go:24 +0x90
testing.tRunner.func1()
/Users/bytedance/.mytools/go/src/testing/testing.go:1349 +0x1f2
panic({0x1196b80, 0x12e3140})
/Users/bytedance/.mytools/go/src/runtime/panic.go:838 +0x207
mydev/fuzz.FuzzDiv.func1(0x0?, 0x0?, 0x0?)
/Users/bytedance/Documents/dev_test/fuzz/main_test.go:8 +0x8c
reflect.Value.call({0x11932a0?, 0x11cbf68?, 0x13?}, {0x11be123, 0x4}, {0xc000010420, 0x3, 0x4?})
/Users/bytedance/.mytools/go/src/reflect/value.go:556 +0x845
reflect.Value.Call({0x11932a0?, 0x11cbf68?, 0x514?}, {0xc000010420, 0x3, 0x4})
/Users/bytedance/.mytools/go/src/reflect/value.go:339 +0xbf
testing.(*F).Fuzz.func1.1(0x0?)
/Users/bytedance/.mytools/go/src/testing/fuzz.go:337 +0x231
testing.tRunner(0xc000003a00, 0xc00007e3f0)
/Users/bytedance/.mytools/go/src/testing/testing.go:1439 +0x102
created by testing.(*F).Fuzz.func1
/Users/bytedance/.mytools/go/src/testing/fuzz.go:324 +0x5b8
Failing input written to testdata/fuzz/FuzzDiv/2058e4e611665fa289e5c0098bad841a6785bf79d30e47b96d8abcb0745a061c
To re-run:
go test -run=FuzzDiv/2058e4e611665fa289e5c0098bad841a6785bf79d30e47b96d8abcb0745a061c
FAIL
exit status 1
FAIL mydev/fuzz 0.059s

其中的：

Failing input written to testdata/fuzz/FuzzDiv/2058e4e611665fa289e5c0098bad841a6785bf79d30e47b96d8abcb0745a061c

這一行表示模糊測(cè)試將出現(xiàn)panic的測(cè)試入?yún)⒈４娴搅诉@個(gè)文件里面，此時(shí)嘗試輸出這個(gè)文件的內(nèi)容：

go test fuzz v1
int(-60)
int(0)

就可以看到引發(fā)panic的入?yún)?，此時(shí)我們就可以根據(jù)入?yún)z查我們的代碼是哪里有問題。當(dāng)然，這個(gè)簡(jiǎn)單的例子就是故意寫了個(gè)除0錯(cuò)誤。

提供自定義語(yǔ)料

Golang的模糊測(cè)試還允許開發(fā)者自行提供初始語(yǔ)料，初始語(yǔ)料可以通過(guò)“f.Add”方法提供，也可以將語(yǔ)料以上面的“Failing input”相同的格式，寫入“testdata/fuzz/FuzzXXX/自定義語(yǔ)料文件名”中。

使用時(shí)的注意點(diǎn)

目前Golang的模糊測(cè)試僅支持被測(cè)試的函數(shù)使用這些類型的參數(shù)：

[]byte, string, bool, byte, rune, float32, float64,
int, int8, int16, int32, int64, uint, uint8, uint16, uint32, uint64

Go的泛型

Golang在1.18中終于加入了對(duì)泛型的支持，有了泛型之后，我們可以這樣寫一些公共庫(kù)的代碼：

舊代碼（反射）：

func IsContainCommon(val interface{}, array interface{}) bool {
    switch reflect.TypeOf(array).Kind() {
    case reflect.Slice:
        lst := reflect.ValueOf(array)
        for index := 0; index &lt; lst.Len(); index++ {
            if reflect.DeepEqual(val, lst.Index(index).Interface()) {
                return true
            }
        }
    }
    return false
}

新代碼（泛型）：

func IsContainCommon[T any](val T, array []T) bool {
    for _, item := range array {
        if reflect.DeepEqual(val, item) {
            return true
        }
    }
    return false
}

泛型在Golang中增加了三個(gè)新的重要特性：

在定義函數(shù)和類型時(shí)，支持使用類型參數(shù)（Type parameters）
將接口（interface）重新定義為“類型的集合”
泛型支持類型推導(dǎo)

下面逐個(gè)對(duì)這些內(nèi)容進(jìn)行簡(jiǎn)單說(shuō)明。

類型參數(shù)（Type Parameters）

現(xiàn)在在定義函數(shù)和類型時(shí)，支持使用“類型參數(shù)”，類型參數(shù)的列表和函數(shù)參數(shù)列表很相似，只不過(guò)它使用的是方括號(hào)：

func Min[T constraints.Ordered](x, y T) T {
    if x &lt; y {
        return x
    }
    return y
}

上述的代碼中，給Min函數(shù)定義了一個(gè)參數(shù)類型T，這很類似于C++中的“template”，只不過(guò)在Golang中，可以為這種參數(shù)類型指定它需要滿足的“約束”。在這個(gè)例子中，使用的“約束”是“constraints.Ordered”。

然后就可以按照如下方式，使用這個(gè)函數(shù)了：

x := Min[int](1, 2)
y := Min[float64](1.1, 2.2)

為泛型函數(shù)指定類型參數(shù)的過(guò)程叫做“實(shí)例化（Instantiation）”，也可以將實(shí)例化后的函數(shù)保存成為函數(shù)對(duì)象，并且進(jìn)一步使用：

f := Min[int64] // 這一步保存了一個(gè)實(shí)例化的函數(shù)對(duì)象
n := f(123, 456)

同樣的，自定義的類型也支持泛型：

type TreeNode[T interface{}] struct {
    left, right *TreeNode[T]
    value T
}
func (t *TreeNode[T]) Find(x T) { ... }
var myBinaryTree TreeNode[int]

如上述代碼，struct類型在使用泛型時(shí)，支持自己的成員變量和自己持有同樣的泛型類型。

類型集合（Type Sets）

下面稍微深入的講一下上述例子提到的“約束”。上文的例子中的“int”“float64”“int64”在實(shí)例化時(shí)，實(shí)際上是被作為“參數(shù)”傳遞給了“類型參數(shù)列表”，即上文例子中的“[T constraints.Ordered]”。

就像傳遞普通參數(shù)需要校驗(yàn)參數(shù)的類型一樣，傳遞類型參數(shù)時(shí)也需要對(duì)被傳遞的類型參數(shù)進(jìn)行校驗(yàn)，檢查被傳遞的類型是否滿足要求。

例如上文例子中，使用“int”“float64”“int64”這幾個(gè)類型對(duì)Min函數(shù)進(jìn)行實(shí)例化時(shí)，編譯器都會(huì)檢查這些參數(shù)是否滿足“constraints.Ordered”這個(gè)約束。而這個(gè)約束描述了所有可以使用“<”進(jìn)行比較的類型的集合，這個(gè)約束本身也是一個(gè)interface。

在Go的泛型中，類型約束必須是一種interface，而“傳統(tǒng)”的Golang中對(duì)interface的定義是“一個(gè)接口定義了一組方法集合”，任何實(shí)現(xiàn)了這組方法集合的類型都實(shí)現(xiàn)了這個(gè)interface：

不過(guò)這里就出現(xiàn)了一個(gè)問題：“<”的比較顯然不是一個(gè)方法（Go當(dāng)中不存在C++的運(yùn)算符重載），而描述了這個(gè)約束的constraints.Ordered自身的確也是一個(gè)interface。

所以從1.18開始，Golang將Interface重新定義為“一組類型的集合”，按照以前對(duì)interface的看法，也可以將一個(gè)interface看成是“所有實(shí)現(xiàn)了這個(gè)interface的方法集合的類型所構(gòu)成的集合”：

其實(shí)兩種看法殊途同歸，但是后者顯然可以更靈活，直接將一組具體類型指定成一個(gè)interface，即使這些類型沒有任何的方法。

例如在1.18中，可以這樣定義一個(gè)interface：

type MyInterface interface {
    int|bool|string
}

這樣的定義表示int/bool/string都可以被當(dāng)作MyInterface進(jìn)行使用。

那么回到constraints.Ordered，它的定義實(shí)際上是：

type Ordered interface {
    Integer|Float|~string
}
type Float interface {
    ~float32|~float64
}
type Integer interface {
    Signed|Unsigned
}
type Signed interface {
    ~int|~int8|~int16|~int32|~int64
}
type Unsigned interface {
    ~uint|~uint8|~uint16|~uint32|~uint64
}

其中前置的“～”符號(hào)表示“任何底層類型是后面所跟著的類型的類型”，例如：

type MyString string

這樣定義的MyString是可以滿足“~string”的類型約束的。

類型推導(dǎo)（Type Inference）

最后，所有支持泛型的語(yǔ)言都會(huì)有的類型推導(dǎo)自然也不會(huì)缺席。類型推導(dǎo)功能可以允許使用者在調(diào)用泛型函數(shù)時(shí)，無(wú)需指定所有的類型參數(shù)。例如下面這個(gè)函數(shù)：

// 將F類型的slice變換為T類型的slice
// 關(guān)鍵字 any 等同于 interface{}
func Map[F, T any](src []F, f func(F) T) []T {
    ret := make([]T, 0, len(src))
    for _, item := range src {
        ret = append(ret, f(item))
    }
    return ret
}

在使用時(shí)可以這樣：

var myConv := func(i int)string {return fmt.Sprint(i)}
var src []int
var dest []string
dest = Map[int, string](src, myConv) // 明確指定F和T的類型
dest = Map[int](src, myConv) // 僅指定F的類型，T的類型交由編譯器推導(dǎo)
dest = Map(src, myConv) // 完全不指定類型，F(xiàn)和T都交由編譯器推導(dǎo)

泛型函數(shù)在使用時(shí)，可以不指定具體的類型參數(shù)，也可以僅指定類型參數(shù)列表左邊的部分類型。當(dāng)自動(dòng)的類型推導(dǎo)失敗時(shí)，編譯器會(huì)報(bào)錯(cuò)。

Golang泛型中的類型推導(dǎo)主要分為兩大部分：

函數(shù)參數(shù)類型推導(dǎo)：通過(guò)函數(shù)的入?yún)ⅲ瑢?duì)類型參數(shù)對(duì)應(yīng)的具體類型進(jìn)行推導(dǎo)。
約束類型推導(dǎo)：通過(guò)已知具體類型的類型參數(shù)，來(lái)推斷出未知類型參數(shù)的具體類型。

而這兩種類型推導(dǎo)，都依賴一種名為“類型統(tǒng)一化（Type Unification）”的技術(shù)。

類型統(tǒng)一化（Type Unification）

類型統(tǒng)一化是對(duì)兩個(gè)類型進(jìn)行比較，這兩個(gè)類型有可能本身是一個(gè)類型參數(shù)，也有可能包含一個(gè)類型參數(shù)。

比較的過(guò)程是對(duì)這兩個(gè)類型的“結(jié)構(gòu)”進(jìn)行對(duì)比，并且要求被比較的兩個(gè)類型滿足下列條件：

剔除類型參數(shù)后，兩個(gè)類型的“結(jié)構(gòu)”必須能夠匹配
剔除類型參數(shù)后，結(jié)構(gòu)中剩余的具體類型必須相同
如果兩者均不含類型參數(shù)，那么兩者的類型必須完全相同，或者底層數(shù)據(jù)類型完全相同

這里說(shuō)的“結(jié)構(gòu)”，指的是類型定義中的slice、map、function等等，以及它們之間的任意嵌套。

滿足這幾個(gè)條件時(shí)，類型統(tǒng)一性對(duì)比才算做成功，編譯器才能進(jìn)一步對(duì)類型參數(shù)進(jìn)行推測(cè)，例如：

如果我們此時(shí)有“T1”、“T2”兩個(gè)類型參數(shù)，那么“[]map[int]bool”可以匹配如下類型：

[]map[int]bool // 它本身
T1 // T1被推斷為 []map[int]bool
[]T1 // T1被推斷為 map[int]bool
[]map[T1]T2 // T1被推斷為 int, T2被推斷為 bool

作為反例，“[]map[int]bool”顯然無(wú)法匹配這些類型：

int
struct{}
[]struct{}
[]map[T1]string
// etc...

函數(shù)參數(shù)類型推導(dǎo)（Function Argument Type Inference）

函數(shù)參數(shù)類型推導(dǎo)，顧名思義是在泛型函數(shù)被調(diào)用時(shí)，如果沒有被完全指定所有的類型參數(shù)，那么編譯器就會(huì)根據(jù)函數(shù)實(shí)際入?yún)⒌念愋?，?duì)類型參數(shù)所對(duì)應(yīng)的具體類型進(jìn)行推導(dǎo)，例如本文最開始的Min函數(shù)：

func Min[T constraints.Ordered](x, y T) T {
    if x < y {
        return x
    }
    return y
}
ans := Min(1, 2) // 此時(shí)類型參數(shù)T被推導(dǎo)為int

和其他支持泛型的語(yǔ)言一樣，Golang的函數(shù)參數(shù)類型推導(dǎo)只支持“能夠從入?yún)⑼茖?dǎo)的類型參數(shù)”，如果類型參數(shù)用于標(biāo)記返回類型，那么在使用時(shí)必須明確指定類型參數(shù)：

func MyFunc[T1, T2, T3 any](x T1) T2 {
    // ...
    var x T3
    // ...
}
ans := MyFunc[int, bool, string](123) // 需要手動(dòng)指定

類似這樣的函數(shù)，部分的類型參數(shù)僅出現(xiàn)在返回值當(dāng)中（或者僅出現(xiàn)在函數(shù)體中，不作為入?yún)⒒虺鰠⒊霈F(xiàn)），就無(wú)法使用函數(shù)參數(shù)類型推導(dǎo)，而必須明確手動(dòng)指定類型。

推導(dǎo)算法與示例

還是拿Min函數(shù)作為例子，講解一下函數(shù)參數(shù)類型推導(dǎo)的過(guò)程：

func Min[T constraints.Ordered](x, y T) T {
    if x < y {
        return x
    }
    return y
}

先來(lái)看看第一種情況：

Min(1, 2)

此時(shí)兩個(gè)入?yún)⒕鶠闊o(wú)類型字面值常量，所以第一輪的類型統(tǒng)一化被跳過(guò)，且入?yún)⒌木唧w類型沒有被確定，此時(shí)編譯器嘗試使用兩個(gè)參數(shù)的默認(rèn)類型int，由于兩個(gè)入?yún)⒃诤瘮?shù)定義處的類型都是“T”，且兩者都使用默認(rèn)類型int，所以此時(shí)T被成功推斷為int。

然后來(lái)看第二種情況：

Min(1, int64(2))

此時(shí)第二個(gè)參數(shù)有一個(gè)明確的類型int64，所以在第一輪的類型統(tǒng)一化中，T被推斷為int64，且在嘗試為第一輪漏掉的第一個(gè)參數(shù)“1”確定類型時(shí)，由于“1”是一個(gè)合法的int64類型值，所以T被成功推斷為int64。

再來(lái)看第三種情況：

Min(1.5, int64(2))

此時(shí)第二個(gè)參數(shù)有一個(gè)明確的類型int64，所以在第一輪的類型統(tǒng)一化中，T被推斷為int64，且在嘗試為第一輪漏掉的第一個(gè)參數(shù)“1.5”確定類型時(shí)，由于“1.5”不是一個(gè)合法的int64類型值，類型推導(dǎo)失敗，此時(shí)編譯器報(bào)錯(cuò)。

最后看第四種情況：

Min(1, 2.5)

和第一種情況類似，第一輪的類型統(tǒng)一化被跳過(guò)，且兩個(gè)入?yún)⒌木唧w類型沒有被確定，此時(shí)編譯器開始嘗試使用默認(rèn)類型。兩個(gè)參數(shù)的默認(rèn)類型分別是int和float64，由于在類型推導(dǎo)中，同一個(gè)類型參數(shù)T只能被確定為一種類型，所以此時(shí)類型推導(dǎo)也會(huì)失敗。

約束類型推導(dǎo)（Constraints Type Inference）

約束類型推導(dǎo)是Golang泛型的另一個(gè)強(qiáng)大武器，它可以允許編譯器通過(guò)一個(gè)類型參數(shù)來(lái)推導(dǎo)另一個(gè)類型參數(shù)的具體類型，也可以通過(guò)使用類型參數(shù)來(lái)保存調(diào)用者的類型信息。

約束類型推導(dǎo)可以允許使用其他類型參數(shù)來(lái)為某個(gè)類型參數(shù)指定約束，這類約束被稱為“結(jié)構(gòu)化約束”，這種約束定義了類型參數(shù)必須滿足的數(shù)據(jù)結(jié)構(gòu)，例如：

// 將一個(gè)整數(shù)slice中的每個(gè)元素都x2后返回
func DoubleSlice[S ~[]E, E constraints.Integer](slice S) S {
    ret := make(S, 0, len(slice))
    for _, item := range slice {
        ret = append(ret, item + item)
    }
    return ret
}

在這個(gè)函數(shù)的定義中，“[]E”就是一個(gè)簡(jiǎn)寫的對(duì)S的結(jié)構(gòu)化約束，其完整寫法應(yīng)是“interface{[]E}”，即以類型集合的方式來(lái)定義的interface，且其中只包含一種定義“~[]E”，意為“底層數(shù)據(jù)類型是[]E的所有類型”。

注意，一個(gè)合法的結(jié)構(gòu)化約束所對(duì)應(yīng)的類型集合，應(yīng)該滿足下列任意一個(gè)條件：

類型集合中只包含一種類型
類型集合中所有類型的底層數(shù)據(jù)類型均完全相同

在這個(gè)例子中，S使用的結(jié)構(gòu)化約束中，所有滿足約束的類型的底層數(shù)據(jù)類型均為[]E，所以是一個(gè)合法的結(jié)構(gòu)化約束。

當(dāng)存在無(wú)法通過(guò)函數(shù)參數(shù)類型推導(dǎo)確定具體類型的類型參數(shù)，且類型參數(shù)列表中包含結(jié)構(gòu)化約束時(shí)，編譯器會(huì)嘗試進(jìn)行約束類型推導(dǎo)。

推導(dǎo)算法與示例

簡(jiǎn)單的例子

結(jié)合我們剛才的例子“DoubleSlice”函數(shù)，講一下約束類型推導(dǎo)的具體過(guò)程：

type MySlice []int
ans := DoubleSlice(MySlice{1, 2, 3})

在這個(gè)調(diào)用中，首先執(zhí)行的是普通的函數(shù)參數(shù)類型推導(dǎo)，這一步會(huì)得到一個(gè)這樣的推導(dǎo)結(jié)果：

S => MySlice

此時(shí)編譯器發(fā)現(xiàn)，還有一個(gè)類型參數(shù)E沒有被推導(dǎo)，且當(dāng)前存在一個(gè)使用結(jié)構(gòu)化約束的類型參數(shù)S，此時(shí)開始約束類型推導(dǎo)。

首先需要尋找已經(jīng)完成類型推導(dǎo)的類型參數(shù)，在這個(gè)例子里是S，它的類型已經(jīng)被推導(dǎo)出是MySlice。

然后會(huì)將S的實(shí)際類型“MySlice”，與S的結(jié)構(gòu)化約束“~[]E”進(jìn)行類型統(tǒng)一化，由于MySlice的底層類型是[]int，所以結(jié)構(gòu)化匹配之后，得到了這樣的匹配結(jié)果：

E => int

此時(shí)所有的類型參數(shù)都已經(jīng)被推斷，且符合各自的約束，類型推導(dǎo)結(jié)束。

一個(gè)更復(fù)雜的例子

假設(shè)有這樣一個(gè)函數(shù)：

func SomeComplicatedMethod[S ~[]M, M ~map[K]V, K comparable, V any](s S) {
    // comparable 是一個(gè)內(nèi)置的約束，表示所有可以使用 == != 運(yùn)算符的類型
}

然后我們這樣去調(diào)用它：

SomeComplicatedMethod([]map[string]int{})

編譯時(shí)產(chǎn)生的類型推導(dǎo)過(guò)程如下，首先是函數(shù)參數(shù)類型推導(dǎo)的結(jié)果：

S => []map[string]int

然后對(duì)S使用約束類型推導(dǎo)，對(duì)比 []map[string]int 和 ~[]M，得到：

M => map[string]int

再繼續(xù)對(duì)M使用約束類型推導(dǎo)，對(duì)比 map[string]int 和 ~map[K]V，得到：

K => string
V => int

至此類型推導(dǎo)成功完成。

使用約束類型推導(dǎo)保存類型信息

約束類型推導(dǎo)的另一個(gè)作用就是，它能夠保存調(diào)用者的原始參數(shù)的類型信息。

還是以這一節(jié)的“DoubleSlice”函數(shù)做例子，假設(shè)我們現(xiàn)在實(shí)現(xiàn)一個(gè)更加“簡(jiǎn)單”的版本：

func DoubleSliceSimple[E constraints.Integer](slice []E) []E {
    ret := make([]E, 0, len(slice))
    for _, item := range slice {
        ret = append(ret, item + item)
    }
    return ret
}

這個(gè)版本只有一個(gè)類型參數(shù)E。此時(shí)我們按照之前的方式去調(diào)用它：

type MySlice []int
ans := DoubleSliceSimple(MySlice{1, 2, 3}) // ans 的類型是 []int !!!

此時(shí)的類型推導(dǎo)僅僅是最基礎(chǔ)的函數(shù)參數(shù)類型推導(dǎo)，編譯器會(huì)對(duì)MySlice和[]E直接做結(jié)構(gòu)化比較，得出E的實(shí)際類型是int的結(jié)論。

此時(shí)DoubleSliceSimple這個(gè)函數(shù)返回的類型是[]E，也就是[]int，而不是調(diào)用者傳入的MySlice。而之前的DoubleSlice函數(shù)，通過(guò)定義了一個(gè)使用結(jié)構(gòu)化約束的類型參數(shù)S，并且直接用S去匹配入?yún)⒌念愋?，且返回值類型也是S，就可以保留調(diào)用者的原始參數(shù)類型。

泛型的使用局限

目前Golang泛型依然還有不少的局限，幾個(gè)主要的局限點(diǎn)包括：

成員函數(shù)無(wú)法使用泛型
不能使用沒在約束定義中指定的方法，即使類型集合里所有的類型都實(shí)現(xiàn)了該方法
不能使用成員變量，即使類型集合里所有的類型都擁有該成員

下面分別舉例：

成員函數(shù)無(wú)法使用泛型

type MyStruct[T any] struct {
    // ...
}
func (s *MyStruct[T]) Method[T2 any](param T2) { // 錯(cuò)誤：成員函數(shù)無(wú)法使用泛型
    // ...
}

在這個(gè)例子中，MyStruct[T]的成員函數(shù)Method定義了一個(gè)只屬于自己的函數(shù)參數(shù)T2，然而這樣的操作目前是不被編譯器支持的（今后也很可能不會(huì)支持）。

無(wú)法使用約束定義之外的方法

type MyType1 struct {
    // ...
}
func (t MyType1) Method() {}
type MyType2 struct {
    // ...
}
func (t MyType2) Method() {}
type MyConstraint interface {
    MyType1 | MyType2
}
func MyFunc[T MyConstraint](t T) {
    t.Method() // 錯(cuò)誤： MyConstraint 不包含 .Method() 方法
}

這個(gè)例子中，MyConstraint集合中的兩個(gè)成員MyType1和MyType2盡管都實(shí)現(xiàn)了.Method()函數(shù)，但是也無(wú)法直接在泛型函數(shù)中調(diào)用。

如果需要調(diào)用，則應(yīng)該將MyConstraint改寫為如下形式：

type MyConstraint interface {
    MyType1 | MyType2
    Method()
}

無(wú)法使用成員變量

type MyType1 struct {
    Name string
}
type MyType2 struct {
    Name string
}
type MyConstraint interface {
    MyType1 | MyType2
}
func MyFunc[T MyConstraint](t T) {
    fmt.Println(t.Name) // 錯(cuò)誤： MyConstraint 不包含 .Name 成員
}

在這個(gè)例子當(dāng)中，雖然MyType1和MyType2都包含了一個(gè)Name成員，且類型都是string，也依然無(wú)法以任何方式在泛型函數(shù)當(dāng)中直接使用。

因?yàn)轭愋图s束本身是一個(gè)interface，而interface的定義中只能包含類型集合，以及成員函數(shù)列表。

總結(jié)

Golang 1.18帶來(lái)了上述三個(gè)非常重要的新特性，其中：

工作區(qū)模式可以讓本地開發(fā)的工作流更加順暢。
模糊測(cè)試可以發(fā)現(xiàn)一些邊邊角角的情況，提升代碼的魯棒性。
泛型可以讓一些公共庫(kù)的代碼更加優(yōu)雅，避免像以前一樣，為了“通用性”不得不采用反射的方式，不僅寫起來(lái)難寫，讀起來(lái)難受，還增加了運(yùn)行期的開銷，因?yàn)榉瓷涫沁\(yùn)行時(shí)的動(dòng)態(tài)信息，而泛型是編譯期的靜態(tài)信息。

本文也是簡(jiǎn)單講了這幾方面的內(nèi)容，希望能讓大家對(duì)Golang中的這些新玩意兒有一個(gè)基本的了解。

參考文獻(xiàn)

《Go 1.18 is released!》

《An Introduction To Generics》

《Get familiar with workspaces》

《Tutorial: Getting started with fuzzing》

《Go 1.18新特性前瞻：原生支持Fuzzing測(cè)試》

以上就是Go 1.18新特性工作區(qū) 模糊測(cè)試泛型的使用詳解的詳細(xì)內(nèi)容，更多關(guān)于Go 1.18 工作區(qū)模糊測(cè)試泛型的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

您可能感興趣的文章: