https://go.dev/doc/go1.14

Go 1.14 值得關(guān)注的改動(dòng)：

1. 接口嵌入 ：允許嵌入方法集重疊（方法名和簽名相同）的接口，解決了先前版本中存在的限制，特別是 接口菱形嵌入（diamond-shaped embedding graphs） 問(wèn)題。
2. 模塊與 Vendoring ：當(dāng)存在 vendor 目錄且 go.mod 指定 Go 1.14 或更高版本時(shí)，go 命令默認(rèn)啟用 vendor 模式；同時(shí)，模塊下載支持了 Subversion，并改進(jìn)了代理錯(cuò)誤信息的顯示。
3. 運(yùn)行時(shí)改進(jìn) ：defer 的性能開(kāi)銷大幅降低接近于零；Goroutine 實(shí)現(xiàn) 異步搶占式調(diào)度（asynchronously preemptible），解決了某些循環(huán)導(dǎo)致調(diào)度器阻塞或 GC 延遲的問(wèn)題（盡管這可能導(dǎo)致 Unix 系統(tǒng)上出現(xiàn)更多 EINTR 錯(cuò)誤）；頁(yè)面分配器和內(nèi)部計(jì)時(shí)器效率也得到了提升。
4. Go Modules 行為變更 ：在顯式啟用模塊感知模式（GO111MODULE=on）但無(wú) go.mod 文件時(shí)，多數(shù)命令功能受限；對(duì)于包含 go.mod 文件的模塊，go get 默認(rèn)不再自動(dòng)升級(jí)到不兼容的主版本。
5. 新增 hash/maphash 包 ：提供對(duì)字節(jié)序列的高性能、非加密安全的哈希函數(shù)，適用于哈希表等場(chǎng)景，其哈希結(jié)果在單進(jìn)程內(nèi)一致，跨進(jìn)程則不同。

下面是一些值得展開(kāi)的討論：

接口嵌入允許方法集重疊

Go 1.14 根據(jù) overlapping interfaces proposal[1]，放寬了接口嵌入的限制?，F(xiàn)在允許一個(gè)接口嵌入多個(gè)其他接口，即使這些被嵌入的接口包含了方法名和方法簽名完全相同的方法。

這一改動(dòng)主要解決了先前版本中存在的一個(gè)問(wèn)題，尤其是在接口構(gòu)成 接口菱形嵌入（diamond-shaped embedding graphs） 的場(chǎng)景下。

之前的限制 (Go < 1.14):

在 Go 1.14 之前，如果你嘗試嵌入兩個(gè)具有同名同簽名方法的接口，編譯器會(huì)報(bào)錯(cuò)。例如：

package main

import "fmt"

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

type Writer interface {
    Write(p []byte) (n int, err error)
    Close() error // 與 Reader 中的 Close 方法簽名相同
}

// 在 Go 1.14 之前，下面的定義會(huì)導(dǎo)致編譯錯(cuò)誤：
// "ambiguous selector io.ReadWriteCloser.Close" 或
// "duplicate method Close"
/*
type ReadWriter interface {
    Reader // 嵌入 Reader
    Writer // 嵌入 Writer (包含重復(fù)的 Close 方法)
}
*/

func main() {
    fmt.Println("Go 1.14 之前的接口嵌入限制示例")
    // 無(wú)法直接定義包含重復(fù)方法的嵌入接口
}

Go 1.14 的改進(jìn):

Go 1.14 允許這種情況。當(dāng)一個(gè)接口嵌入多個(gè)包含相同方法（名稱和簽名一致）的接口時(shí)，這些相同的方法在最終的接口方法集中只會(huì)出現(xiàn)一次。

package main

import (
    "fmt"
    "io" // 使用標(biāo)準(zhǔn)庫(kù)接口作為例子
)

// io.ReadCloser 定義
// type ReadCloser interface {
//     Reader
//     Closer
// }

// io.WriteCloser 定義
// type WriteCloser interface {
//     Writer
//     Closer // 與 ReadCloser 中的 Closer 方法簽名相同
// }

// Go 1.14 及之后版本，下面的定義是合法的
type ReadWriteCloser interface {
    io.ReadCloser // 嵌入 io.ReadCloser (包含 Close)
    io.WriteCloser // 嵌入 io.WriteCloser (包含 Close)
    // 最終的 ReadWriteCloser 接口包含 Read, Write, 和 一個(gè) Close 方法
}

type myReadWriteCloser struct{}

func (m *myReadWriteCloser) Read(p []byte) (n int, err error) {
    fmt.Println("Reading...")
    return 0, nil
}

func (m *myReadWriteCloser) Write(p []byte) (n int, err error) {
    fmt.Println("Writing...")
    return len(p), nil
}

func (m *myReadWriteCloser) Close() error {
    fmt.Println("Closing...")
    return nil
}

func main() {
    var rwc ReadWriteCloser
    rwc = &myReadWriteCloser{}

    rwc.Read(nil)
    rwc.Write([]byte("test"))
    rwc.Close() // 調(diào)用的是同一個(gè) Close 方法

    // 檢查是否同時(shí)滿足 io.ReadCloser 和 io.WriteCloser
    var rc io.ReadCloser = rwc
    var wc io.WriteCloser = rwc
    fmt.Printf("rwc is ReadCloser: %t\n", rc != nil)
    fmt.Printf("rwc is WriteCloser: %t\n", wc != nil)
}

在這個(gè)例子中，ReadWriteCloser 嵌入了 io.ReadCloser 和 io.WriteCloser。兩者都包含了一個(gè) Close() error 方法。在 Go 1.14 中，這是允許的，ReadWriteCloser 接口最終只包含一個(gè) Close 方法。任何實(shí)現(xiàn)了 ReadWriteCloser 的類型，其 Close 方法必須同時(shí)滿足 io.ReadCloser 和 io.WriteCloser 的要求。

重要提示： 這個(gè)改動(dòng)只適用于 嵌入 的接口。如果在一個(gè)接口定義中 顯式聲明 了同名同簽名的方法，或者顯式聲明的方法與嵌入接口中的方法沖突，依然會(huì)和以前一樣導(dǎo)致編譯錯(cuò)誤。

package main

import "io"

// 這個(gè)定義仍然是錯(cuò)誤的，因?yàn)?Close 被顯式聲明了兩次
/*
type BadInterface interface {
    Close() error
    Close() error // compile error: duplicate method Close
}
*/

// 這個(gè)定義也是錯(cuò)誤的，因?yàn)轱@式聲明的 Close 與嵌入的 Close 沖突
/*
type AnotherBadInterface interface {
    io.Closer // 嵌入 io.Closer (包含 Close() error)
    Close() error // compile error: duplicate method Close
}
*/

func main() {}

這個(gè)改進(jìn)使得接口設(shè)計(jì)，尤其是在構(gòu)建復(fù)雜的接口層次結(jié)構(gòu)時(shí)更加靈活。

模塊與 Vendoring 行為變更

Go 1.14 對(duì) Go Modules 的 vendor 機(jī)制和模塊下載進(jìn)行了一些重要的調(diào)整和改進(jìn)。

默認(rèn)啟用 -mod=vendor:

最顯著的變化是 go 命令（如 go build, go test, go run 等接受 -mod 標(biāo)志的命令）在特定條件下的默認(rèn)行為。

• 條件：

1. 你的主模塊（項(xiàng)目根目錄）包含一個(gè)名為 vendor 的頂層目錄。
2. 你的主模塊的 go.mod 文件中指定了 go 1.14 或更高的 Go 版本 (go 1.14, go 1.15, 等等)。

• 行為：如果滿足以上兩個(gè)條件，go 命令現(xiàn)在會(huì) 默認(rèn) 使用 -mod=vendor 標(biāo)志。這意味著構(gòu)建、測(cè)試等操作會(huì)優(yōu)先使用 vendor 目錄中的依賴包，而不是去模塊緩存（$GOPATH/pkg/mod）中查找。

對(duì)比 (Go < 1.14 或 無(wú) vendor 目錄):

在 Go 1.14 之前，或者即使在 Go 1.14+ 但沒(méi)有 vendor 目錄，或者 go.mod 指定的版本低于 1.14，go 命令默認(rèn)的行為類似于 -mod=readonly，它會(huì)使用模塊緩存中的依賴。

新的 -mod=mod 標(biāo)志:

為了應(yīng)對(duì)默認(rèn)行為的改變，Go 1.14 引入了一個(gè)新的 -mod 標(biāo)志值：-mod=mod。如果你滿足了默認(rèn)啟用 vendor 模式的條件，但又想強(qiáng)制 go 命令使用模塊緩存（就像沒(méi)有 vendor 目錄時(shí)那樣），你可以顯式地使用 -mod=mod 標(biāo)志。

# 假設(shè)項(xiàng)目滿足條件 (go.mod >= 1.14, vendor/ 存在)

# Go 1.14+ 默認(rèn)行為，等同于 go build -mod=vendor
go build

# 強(qiáng)制使用 module cache，忽略 vendor/ 目錄
go build -mod=mod

vendor/modules.txt 校驗(yàn):

當(dāng) -mod=vendor 被設(shè)置時(shí)（無(wú)論是顯式設(shè)置還是默認(rèn)啟用），go 命令現(xiàn)在會(huì)校驗(yàn)主模塊下的 vendor/modules.txt 文件是否與其 go.mod 文件保持一致。如果不一致，命令會(huì)報(bào)錯(cuò)。這有助于確保 vendor 目錄的內(nèi)容確實(shí)反映了 go.mod 文件中聲明的依賴。

go list -m 行為變更:

在 vendor 模式下 (-mod=vendor)，go list -m 命令不再會(huì)靜默地忽略那些在 vendor 目錄中找不到對(duì)應(yīng)包的 傳遞性依賴（transitive dependencies）。如果請(qǐng)求信息的模塊沒(méi)有在 vendor/modules.txt 文件中列出，go list -m 現(xiàn)在會(huì)明確地報(bào)錯(cuò)失敗。

模塊下載改進(jìn):

• Subversion 支持 ：go 命令在模塊模式下現(xiàn)在支持從 Subversion (SVN) 版本控制系統(tǒng)下載模塊。
• 更清晰的錯(cuò)誤信息 ：當(dāng)從模塊代理（Module Proxies）或其他 HTTP 服務(wù)器下載模塊遇到錯(cuò)誤時(shí)，go 命令現(xiàn)在會(huì)嘗試包含一部分來(lái)自服務(wù)器的純文本錯(cuò)誤信息片段。這有助于診斷下載問(wèn)題。只有當(dāng)錯(cuò)誤信息是有效的 UTF-8 編碼，并且只包含圖形字符和空格時(shí)，才會(huì)被顯示。

這些改動(dòng)使得 vendor 模式更加健壯和符合預(yù)期，同時(shí)也提升了模塊下載的兼容性和問(wèn)題診斷能力。

運(yùn)行時(shí)性能改進(jìn)和 Goroutine 搶占

Go 1.14 在運(yùn)行時(shí)（runtime）層面引入了多項(xiàng)重要的性能改進(jìn)和機(jī)制變化。

defer 性能大幅提升:

Go 1.14 顯著優(yōu)化了 defer 語(yǔ)句的實(shí)現(xiàn)。對(duì)于大多數(shù)使用場(chǎng)景，defer 的開(kāi)銷已經(jīng)降低到幾乎為零，與直接調(diào)用被延遲的函數(shù)相差無(wú)幾。

• 影響：這意味著開(kāi)發(fā)者可以在性能敏感的代碼路徑中（例如，循環(huán)內(nèi)部）更自由地使用 defer 來(lái)進(jìn)行資源清理（如 Unlock 互斥鎖、關(guān)閉文件句柄等），而不必過(guò)分擔(dān)心其帶來(lái)的性能損耗。
• 對(duì)比 (Go < 1.14) ：在舊版本中，defer 會(huì)帶來(lái)一定的固定開(kāi)銷，可能導(dǎo)致開(kāi)發(fā)者在性能關(guān)鍵區(qū)域避免使用它，轉(zhuǎn)而采用手動(dòng)調(diào)用清理函數(shù)的方式。

雖然很難用簡(jiǎn)單的代碼示例直接 展示 性能差異（需要基準(zhǔn)測(cè)試），但可以想象在舊版本中可能避免的寫(xiě)法：

// 在 Go 1.14+ 中，即使在循環(huán)內(nèi)部，使用 defer 的性能開(kāi)銷也大大降低
func processItems(items []Item, mu *sync.Mutex) {
    for _, item := range items {
        mu.Lock()
        // 在 Go 1.14+，這里的 defer 開(kāi)銷很小
        defer mu.Unlock() 

        // ... 處理 item ...
        if item.needsSpecialHandling() {
             // 在 Go 1.14 之前，可能會(huì)因?yàn)樾阅芸紤]，在這里手動(dòng) Unlock
             // mu.Unlock() 
             handleSpecial(item)
             // continue // 或者 return，需要確保 Unlock 被調(diào)用
             // 并且在循環(huán)正常結(jié)束時(shí)也需要 Unlock，代碼更復(fù)雜
             // mu.Lock() // 如果 continue 后還需要鎖
        }
    }
}

Goroutine 異步搶占式調(diào)度:

這是一個(gè)重要的底層調(diào)度機(jī)制變化。Goroutine 現(xiàn)在是 異步搶占（asynchronously preemptible） 的。

• 機(jī)制：在此之前，Go 的調(diào)度器是協(xié)作式的，搶占點(diǎn)主要發(fā)生在函數(shù)調(diào)用時(shí)。如果一個(gè) Goroutine 執(zhí)行一個(gè)沒(méi)有函數(shù)調(diào)用的密集計(jì)算循環(huán)（例如 for {}），它可能會(huì)長(zhǎng)時(shí)間霸占 CPU，導(dǎo)致其他 Goroutine 無(wú)法運(yùn)行，甚至可能阻塞調(diào)度器或顯著延遲垃圾回收（GC）。
• 改進(jìn)：Go 1.14 引入了基于信號(hào)的異步搶占機(jī)制。這意味著即使 Goroutine 正在執(zhí)行一個(gè)沒(méi)有函數(shù)調(diào)用的循環(huán)，運(yùn)行時(shí)也可以發(fā)送信號(hào)來(lái)中斷它，讓調(diào)度器有機(jī)會(huì)運(yùn)行其他 Goroutine 或執(zhí)行 GC。
• 影響：

a.提高了程序的公平性和響應(yīng)性，避免了某些類型的死鎖或調(diào)度延遲。

b.密集計(jì)算循環(huán)不再容易餓死其他 Goroutine 或 GC。

• 平臺(tái)支持：此功能在發(fā)布時(shí)支持除 windows/arm, darwin/arm, js/wasm, plan9/* 之外的所有平臺(tái)。
• 副作用 (EINTR 錯(cuò)誤) ：這種基于信號(hào)的搶占實(shí)現(xiàn)有一個(gè)副作用：在 Unix 系統(tǒng)（包括 Linux 和 macOS）上，用 Go 1.14 構(gòu)建的程序可能會(huì)比舊版本接收到更多的信號(hào)。這會(huì)導(dǎo)致那些進(jìn)行 慢系統(tǒng)調(diào)用（slow system calls） 的代碼（例如，使用 syscall 或 golang.org/x/sys/unix 包進(jìn)行網(wǎng)絡(luò)讀寫(xiě)、文件操作等）更頻繁地遇到 EINTR (Interrupted system call) 錯(cuò)誤。
• 應(yīng)對(duì)：程序 必須 正確處理 EINTR 錯(cuò)誤，通常的做法是簡(jiǎn)單地重試該系統(tǒng)調(diào)用。

import "syscall"
import "fmt"

// 示例：處理可能因搶占信號(hào)而中斷的系統(tǒng)調(diào)用
func readFileWithRetry(fd int, buf []byte) (int, error) {
    for {
        n, err := syscall.Read(fd, buf) // Read 是一個(gè)可能被信號(hào)中斷的系統(tǒng)調(diào)用

        // 如果錯(cuò)誤是 EINTR，說(shuō)明系統(tǒng)調(diào)用被信號(hào)中斷了（可能是搶占信號(hào)）
        // 我們應(yīng)該重試這個(gè)操作
        if err == syscall.EINTR {
            fmt.Println("Syscall interrupted (EINTR), retrying...")
            continue 
        }

        // 如果是其他錯(cuò)誤，或者沒(méi)有錯(cuò)誤 (n >= 0)
        // 則返回結(jié)果
        return n, err
    }
}

內(nèi)存分配器 (Page Allocator) 效率提升:

Go 1.14 的頁(yè)面分配器（Page Allocator）效率更高，并且在高 GOMAXPROCS 值（即使用大量 CPU 核心時(shí)）顯著減少了鎖競(jìng)爭(zhēng)。

• 影響 ：這主要體現(xiàn)在并行執(zhí)行大量大內(nèi)存分配（large allocations）時(shí)，可以觀察到更低的延遲和更高的吞吐量。

內(nèi)部計(jì)時(shí)器 (Internal Timers) 效率提升:

運(yùn)行時(shí)內(nèi)部使用的計(jì)時(shí)器（被 time.After, time.Tick, net.Conn.SetDeadline 等標(biāo)準(zhǔn)庫(kù)函數(shù)依賴）也得到了優(yōu)化。

• 影響 ：減少了鎖競(jìng)爭(zhēng)和上下文切換次數(shù)。這是一個(gè)內(nèi)部性能改進(jìn)，理論上不會(huì)導(dǎo)致用戶可見(jiàn)的行為變化，但會(huì)提升依賴這些計(jì)時(shí)器的操作的整體性能。

總的來(lái)說(shuō)，Go 1.14 在運(yùn)行時(shí)層面帶來(lái)了顯著的性能提升和調(diào)度魯棒性增強(qiáng)，但也引入了需要開(kāi)發(fā)者注意的 EINTR 錯(cuò)誤處理要求。

Go Modules: 無(wú) go.mod 文件及不兼容版本處理

Go 1.14 對(duì) Go Modules 在特定場(chǎng)景下的行為進(jìn)行了調(diào)整，旨在提高構(gòu)建的確定性和可復(fù)現(xiàn)性。

模塊感知模式下無(wú) go.mod 文件的行為:

當(dāng)顯式啟用模塊感知模式（通過(guò)設(shè)置環(huán)境變量 GO111MODULE=on），但當(dāng)前目錄及所有父目錄中都 沒(méi)有 找到 go.mod 文件時(shí)，大多數(shù)與模塊相關(guān)的 go 命令（如 go build, go run, go test 等）的功能會(huì)受到限制。

• 限制 ：在沒(méi)有 go.mod 的情況下，這些命令只能構(gòu)建：

a.標(biāo)準(zhǔn)庫(kù)中的包 (e.g., fmt, net/http)。

b.在命令行上直接指定的 .go 文件。

• 原因 ：在 Go 1.14 之前，即使沒(méi)有 go.mod，go 命令也會(huì)嘗試解析包路徑，并隱式地去下載和使用它能找到的最新版本的模塊。然而，這種方式 不會(huì)記錄 下來(lái)具體使用了哪個(gè)模塊的哪個(gè)版本。這導(dǎo)致了兩個(gè)問(wèn)題：

      a.構(gòu)建速度慢 ：每次構(gòu)建可能都需要重新解析和下載。

      b.不可復(fù)現(xiàn) ：不同時(shí)間或不同環(huán)境下執(zhí)行相同的命令，可能會(huì)因?yàn)橐蕾嚨淖钚掳姹景l(fā)生變化而得到不同的結(jié)果，甚至構(gòu)建失敗。

      c.Go 1.14 的改變 ：為了強(qiáng)制實(shí)現(xiàn)可復(fù)現(xiàn)構(gòu)建，Go 1.14 限制了在無(wú) go.mod 時(shí)隱式解析和下載依賴的能力。你需要一個(gè) go.mod 文件來(lái)明確管理你的項(xiàng)目依賴。

不受影響的命令:

需要注意的是，以下命令的行為基本保持不變，即使在沒(méi)有 go.mod 的模塊感知模式下：

• go get <path>@<version>：仍然可以用于下載指定版本的模塊到模塊緩存。
• go mod download <path>@<version>：同上。
• go list -m <path>@<version>：仍然可以查詢指定版本模塊的信息。

# 確保模塊模式開(kāi)啟
export GO111MODULE=on

# 創(chuàng)建一個(gè)沒(méi)有 go.mod 的目錄
mkdir /tmp/no_gomod_test
cd /tmp/no_gomod_test

# 創(chuàng)建一個(gè)簡(jiǎn)單的 main.go
echo 'package main; import "fmt"; func main() { fmt.Println("Hello from main.go") }' > main.go

# 1. 構(gòu)建標(biāo)準(zhǔn)庫(kù)包 (可以)
# (這個(gè)命令本身意義不大，只是演示可以訪問(wèn)標(biāo)準(zhǔn)庫(kù))
# go build fmt 

# 2. 構(gòu)建命令行指定的 .go 文件 (可以)
go build main.go 
./main # 輸出: Hello from main.go

# 3. 嘗試構(gòu)建一個(gè)需要外部依賴的 .go 文件 (如果依賴未下載則會(huì)失敗)
# echo 'package main; import "rsc.io/quote"; func main() { println(quote.Go()) }' > need_dep.go
# go build need_dep.go  # Go 1.14+ 會(huì)報(bào)錯(cuò)，無(wú)法找到 rsc.io/quote

# 4. 嘗試直接運(yùn)行需要外部依賴的包 (Go 1.14+ 會(huì)報(bào)錯(cuò))
# go run rsc.io/quote/cmd/quote # Go 1.14+ 報(bào)錯(cuò)

# 5. 使用 go get 下載特定版本 (仍然可以)
go get rsc.io/quote@v1.5.2 
# 現(xiàn)在再運(yùn)行上面的 go build need_dep.go 或 go run ... 可能會(huì)成功，因?yàn)樗诰彺胬锪?# 但這仍然不是推薦的工作方式，因?yàn)樗鼪](méi)有被 go.mod 記錄

cd ..
rm -rf /tmp/no_gomod_test

處理不兼容的主版本 (+incompatible):

Go Modules 使用語(yǔ)義化版本（Semantic Versioning）。主版本號(hào)（Major Version）的改變通常意味著不兼容的 API 變更。Go 1.14 對(duì) go get 和 go list 處理不兼容主版本的方式進(jìn)行了調(diào)整。

• 條件 ：當(dāng)你嘗試獲取或更新一個(gè)模塊，并且該模塊的 最新版本 已經(jīng)包含了 go.mod 文件時(shí)。
• go get 的行為 ：

a.默認(rèn)情況下，go get 將 不再 自動(dòng)將你的依賴升級(jí)到一個(gè) 不兼容的主版本 (例如，從 v1.x.y 升級(jí)到 v2.0.0 或更高版本)。

b.它只會(huì)升級(jí)到當(dāng)前主版本內(nèi)的最新兼容版本（例如，從 v1.4.0 升級(jí)到 v1.5.2）。

如果你確實(shí) 需要 升級(jí)到不兼容的主版本，你必須 顯式 地指定該版本（例如 go get example.com/mod@v2.0.0），或者該不兼容版本已經(jīng)是你項(xiàng)目依賴圖中某個(gè)其他模塊所必需的依賴。

• go list 的行為 ：

      a.當(dāng) go list 直接從版本控制系統(tǒng)（如 Git）獲取模塊信息時(shí)，它通常也會(huì)忽略那些被視為不兼容的主版本（相對(duì)于當(dāng)前已知的版本）。

      b.但是，如果信息是從模塊代理獲取的，代理可能會(huì)報(bào)告所有可用的版本，包括不兼容的主版本，這時(shí) go list 可能會(huì)包含它們。

這個(gè)改變有助于防止意外引入破壞性的 API 變更，使得依賴管理更加安全和可控。對(duì)于那些在引入 Go Modules 之前就已經(jīng)發(fā)布了 v2+ 版本但沒(méi)有遵循模塊路徑約定的模塊，Go 會(huì)使用 +incompatible 標(biāo)記（例如 example.com/mod v2.0.1+incompatible）來(lái)標(biāo)識(shí)它們。

# 假設(shè) example.com/mod 有以下版本:
# v1.5.0 (有 go.mod)
# v2.1.0 (有 go.mod)

# 當(dāng)前項(xiàng)目的 go.mod 文件:
# module myproject
# go 1.14
# require example.com/mod v1.4.0

# 運(yùn)行 go get 更新依賴
go get example.com/mod 
# 在 Go 1.14+, 這通常會(huì)將 go.mod 更新到 require example.com/mod v1.5.0
# 而不會(huì)跳到 v2.1.0

# 如果確實(shí)想使用 v2.1.0，必須顯式指定
go get example.com/mod@v2.1.0
# 這會(huì)將 go.mod 更新到 require example.com/mod/v2 v2.1.0 (如果 v2 遵循了模塊路徑約定)
# 或者 require example.com/mod v2.1.0+incompatible (如果 v2 沒(méi)有遵循約定)

新增 hash/maphash 包

Go 1.14 標(biāo)準(zhǔn)庫(kù)中增加了一個(gè)新的包：hash/maphash。這個(gè)包提供了一種用于對(duì)字節(jié)序列（[]byte 或 string）進(jìn)行哈希計(jì)算的函數(shù)。

主要用途:

hash/maphash 主要設(shè)計(jì)用于實(shí)現(xiàn) 哈希表（hash tables, 在 Go 中通常指 map）或其他需要將任意字符串或字節(jié)序列映射到 64 位無(wú)符號(hào)整數(shù)（uint64）上，并期望結(jié)果具有良好均勻分布的數(shù)據(jù)結(jié)構(gòu)。

核心特性:

1. 高性能: 該哈希算法經(jīng)過(guò)優(yōu)化，執(zhí)行速度非常快。
2. 抗碰撞性 (Collision-Resistant): 算法設(shè)計(jì)旨在最小化不同輸入產(chǎn)生相同哈希值的概率（哈希碰撞），使得哈希值分布均勻。這對(duì)于哈希表的性能至關(guān)重要。
3. 非加密安全 (Not Cryptographically Secure): 極其重要 的一點(diǎn)是，hash/maphash不是 加密安全的哈希函數(shù)。你不應(yīng)該將它用于任何安全相關(guān)的目的，例如：

a.密碼哈希存儲(chǔ)

b.生成消息認(rèn)證碼 (MAC)

c.數(shù)字簽名

任何需要抵抗惡意攻擊者尋找碰撞或原像的場(chǎng)景 對(duì)于這些場(chǎng)景，應(yīng)該使用 crypto/sha256, crypto/sha512, golang.org/x/crypto/bcrypt 等加密哈希庫(kù)。

4. 進(jìn)程內(nèi)穩(wěn)定，跨進(jìn)程不穩(wěn)定:

• 對(duì)于一個(gè)給定的字節(jié)序列，在 同一個(gè) Go 進(jìn)程 的單次執(zhí)行過(guò)程中，其 maphash 哈希值是 穩(wěn)定不變 的。
• 但是，對(duì)于同一個(gè)字節(jié)序列，在 不同的 Go 進(jìn)程 中，或者 同 一個(gè)程序的多次不同執(zhí)行 中，計(jì)算出的 maphash 哈希值 幾乎肯定會(huì)不同。

為什么跨進(jìn)程不穩(wěn)定？

這是故意設(shè)計(jì)的。maphash 使用一個(gè) 哈希種子（seed） 來(lái)初始化其內(nèi)部狀態(tài)。這個(gè)種子在每個(gè) Go 程序啟動(dòng)時(shí)由運(yùn)行時(shí)隨機(jī)生成（通過(guò) maphash.MakeSeed()）。這意味著每次運(yùn)行程序時(shí)，哈希函數(shù)都會(huì)使用不同的種子，從而產(chǎn)生不同的哈希序列。

這種設(shè)計(jì)的主要目的是 **防止 哈希洪水攻擊 (Hash Flooding Attacks)**。這類攻擊依賴于攻擊者能夠預(yù)測(cè)哈希函數(shù)對(duì)于特定輸入的輸出，從而構(gòu)造大量會(huì)導(dǎo)致哈希碰撞的輸入，使得哈希表性能急劇下降（從 O(1) 退化到 O(n)），導(dǎo)致拒絕服務(wù)（Denial of Service, DoS）。由于種子在每次運(yùn)行時(shí)都不同，攻擊者無(wú)法預(yù)先構(gòu)造出在特定運(yùn)行實(shí)例中必然會(huì)碰撞的輸入。

基本用法:

package main

import (
    "fmt"
    "hash/maphash"
)

func main() {
    // 1. 創(chuàng)建一個(gè) maphash.Hash 實(shí)例
    // 它會(huì)自動(dòng)使用當(dāng)前進(jìn)程的隨機(jī)種子進(jìn)行初始化
    var h maphash.Hash

    // 如果需要對(duì)同一個(gè)哈希對(duì)象計(jì)算多個(gè)哈希值，需要 Reset
    // (或者為每個(gè)值創(chuàng)建新的 Hash 對(duì)象)

    // 2. 添加數(shù)據(jù) (string 或 []byte)
    s1 := "hello maphash"
    h.WriteString(s1)

    // 3. 計(jì)算 64 位哈希值
    hash1 := h.Sum64()
    fmt.Printf("Hash of \"%s\": %d (0x%x)\n", s1, hash1, hash1)

    // 4. Reset 并計(jì)算另一個(gè)值
    h.Reset()
    s2 := []byte("hello maphash") // 相同內(nèi)容，不同類型
    h.Write(s2)
    hash2 := h.Sum64()
    // 注意：即使內(nèi)容相同，直接比較 []byte 和 string 的哈希值通常也需要確保它們字節(jié)表示一致
    fmt.Printf("Hash of []byte(\"%s\"): %d (0x%x)\n", string(s2), hash2, hash2)
    // 在這個(gè)例子中，string 和 []byte 的內(nèi)容完全相同，所以哈希值也應(yīng)該相同
    fmt.Printf("Hash values match: %t\n", hash1 == hash2)


    // 5. 計(jì)算第三個(gè)值
    h.Reset()
    s3 := "another value"
    h.WriteString(s3)
    hash3 := h.Sum64()
    fmt.Printf("Hash of \"%s\": %d (0x%x)\n", s3, hash3, hash3)


    // 6. 再次計(jì)算第一個(gè)值，驗(yàn)證進(jìn)程內(nèi)穩(wěn)定性
    h.Reset()
    h.WriteString(s1)
    hash4 := h.Sum64()
    fmt.Printf("Hash of \"%s\" again: %d (0x%x)\n", s1, hash4, hash4)
    fmt.Printf("Process-local stability check (hash1 == hash4): %t\n", hash1 == hash4)

    fmt.Println("\nRun this program again, the hash values will likely be different.")

    // 你也可以顯式管理種子，但這通常只在特殊情況下需要
    // seed := maphash.MakeSeed()
    // h.SetSeed(seed)
    // ...
}

輸出：

Hash of "hello maphash": 16786359967769308781 (0xe8f52173e6ba2e6d)
Hash of []byte("hello maphash"): 16786359967769308781 (0xe8f52173e6ba2e6d)
Hash values match: true
Hash of "another value": 14091924103374798602 (0xc390924f4f6b7f0a)
Hash of "hello maphash" again: 16786359967769308781 (0xe8f52173e6ba2e6d)
Process-local stability check (hash1 == hash4): true

Run this program again, the hash values will likely be different.

如果你運(yùn)行上面的程序多次，你會(huì)發(fā)現(xiàn)每次運(yùn)行時(shí)輸出的哈希值都不同，但每次運(yùn)行內(nèi)部 hash1 和 hash4 的值總是相同的。

hash/maphash 為 Go 開(kāi)發(fā)者提供了一個(gè)內(nèi)置的、快速且適合用于哈希表實(shí)現(xiàn)的哈希函數(shù)，同時(shí)通過(guò)隨機(jī)種子避免了潛在的安全風(fēng)險(xiǎn)。

參考資料

[1] overlapping interfaces proposal: https://go.googlesource.com/proposal/+/master/design/6977-overlapping-interfaces.md