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

Go 1.14 值得關注的改動：

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

下面是一些值得展開的討論：

接口嵌入允許方法集重疊

Go 1.14 根據 overlapping interfaces proposal[1]，放寬了接口嵌入的限制。現在允許一個接口嵌入多個其他接口，即使這些被嵌入的接口包含了方法名和方法簽名完全相同的方法。

這一改動主要解決了先前版本中存在的一個問題，尤其是在接口構成 接口菱形嵌入（diamond-shaped embedding graphs） 的場景下。

之前的限制 (Go < 1.14):

在 Go 1.14 之前，如果你嘗試嵌入兩個具有同名同簽名方法的接口，編譯器會報錯。例如：

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 之前，下面的定義會導致編譯錯誤：
// "ambiguous selector io.ReadWriteCloser.Close" 或
// "duplicate method Close"
/*
type ReadWriter interface {
    Reader // 嵌入 Reader
    Writer // 嵌入 Writer (包含重復的 Close 方法)
}
*/

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

Go 1.14 的改進:

Go 1.14 允許這種情況。當一個接口嵌入多個包含相同方法（名稱和簽名一致）的接口時，這些相同的方法在最終的接口方法集中只會出現一次。

package main

import (
    "fmt"
    "io" // 使用標準庫接口作為例子
)

// 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, 和 一個 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() // 調用的是同一個 Close 方法

    // 檢查是否同時滿足 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)
}

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

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

package main

import "io"

// 這個定義仍然是錯誤的，因為 Close 被顯式聲明了兩次
/*
type BadInterface interface {
    Close() error
    Close() error // compile error: duplicate method Close
}
*/

// 這個定義也是錯誤的，因為顯式聲明的 Close 與嵌入的 Close 沖突
/*
type AnotherBadInterface interface {
    io.Closer // 嵌入 io.Closer (包含 Close() error)
    Close() error // compile error: duplicate method Close
}
*/

func main() {}

這個改進使得接口設計，尤其是在構建復雜的接口層次結構時更加靈活。

模塊與 Vendoring 行為變更

Go 1.14 對 Go Modules 的 vendor 機制和模塊下載進行了一些重要的調整和改進。

默認啟用 -mod=vendor:

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

• 條件：

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

• 行為：如果滿足以上兩個條件，go 命令現在會 默認 使用 -mod=vendor 標志。這意味著構建、測試等操作會優先使用 vendor 目錄中的依賴包，而不是去模塊緩存（$GOPATH/pkg/mod）中查找。

對比 (Go < 1.14 或 無 vendor 目錄):

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

新的 -mod=mod 標志:

為了應對默認行為的改變，Go 1.14 引入了一個新的 -mod 標志值：-mod=mod。如果你滿足了默認啟用 vendor 模式的條件，但又想強制 go 命令使用模塊緩存（就像沒有 vendor 目錄時那樣），你可以顯式地使用 -mod=mod 標志。

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

# Go 1.14+ 默認行為，等同于 go build -mod=vendor
go build

# 強制使用 module cache，忽略 vendor/ 目錄
go build -mod=mod

vendor/modules.txt 校驗:

當 -mod=vendor 被設置時（無論是顯式設置還是默認啟用），go 命令現在會校驗主模塊下的 vendor/modules.txt 文件是否與其 go.mod 文件保持一致。如果不一致，命令會報錯。這有助于確保 vendor 目錄的內容確實反映了 go.mod 文件中聲明的依賴。

go list -m 行為變更:

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

模塊下載改進:

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

這些改動使得 vendor 模式更加健壯和符合預期，同時也提升了模塊下載的兼容性和問題診斷能力。

運行時性能改進和 Goroutine 搶占

Go 1.14 在運行時（runtime）層面引入了多項重要的性能改進和機制變化。

defer 性能大幅提升:

Go 1.14 顯著優化了 defer 語句的實現。對于大多數使用場景，defer 的開銷已經降低到幾乎為零，與直接調用被延遲的函數相差無幾。

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

雖然很難用簡單的代碼示例直接 展示 性能差異（需要基準測試），但可以想象在舊版本中可能避免的寫法：

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

        // ... 處理 item ...
        if item.needsSpecialHandling() {
             // 在 Go 1.14 之前，可能會因為性能考慮，在這里手動 Unlock
             // mu.Unlock() 
             handleSpecial(item)
             // continue // 或者 return，需要確保 Unlock 被調用
             // 并且在循環正常結束時也需要 Unlock，代碼更復雜
             // mu.Lock() // 如果 continue 后還需要鎖
        }
    }
}

Goroutine 異步搶占式調度:

這是一個重要的底層調度機制變化。Goroutine 現在是 異步搶占（asynchronously preemptible） 的。

• 機制：在此之前，Go 的調度器是協作式的，搶占點主要發生在函數調用時。如果一個 Goroutine 執行一個沒有函數調用的密集計算循環（例如 for {}），它可能會長時間霸占 CPU，導致其他 Goroutine 無法運行，甚至可能阻塞調度器或顯著延遲垃圾回收（GC）。
• 改進：Go 1.14 引入了基于信號的異步搶占機制。這意味著即使 Goroutine 正在執行一個沒有函數調用的循環，運行時也可以發送信號來中斷它，讓調度器有機會運行其他 Goroutine 或執行 GC。
• 影響：

a.提高了程序的公平性和響應性，避免了某些類型的死鎖或調度延遲。

b.密集計算循環不再容易餓死其他 Goroutine 或 GC。

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

import "syscall"
import "fmt"

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

        // 如果錯誤是 EINTR，說明系統調用被信號中斷了（可能是搶占信號）
        // 我們應該重試這個操作
        if err == syscall.EINTR {
            fmt.Println("Syscall interrupted (EINTR), retrying...")
            continue 
        }

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

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

Go 1.14 的頁面分配器（Page Allocator）效率更高，并且在高 GOMAXPROCS 值（即使用大量 CPU 核心時）顯著減少了鎖競爭。

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

內部計時器 (Internal Timers) 效率提升:

運行時內部使用的計時器（被 time.After, time.Tick, net.Conn.SetDeadline 等標準庫函數依賴）也得到了優化。

• 影響 ：減少了鎖競爭和上下文切換次數。這是一個內部性能改進，理論上不會導致用戶可見的行為變化，但會提升依賴這些計時器的操作的整體性能。

總的來說，Go 1.14 在運行時層面帶來了顯著的性能提升和調度魯棒性增強，但也引入了需要開發者注意的 EINTR 錯誤處理要求。

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

Go 1.14 對 Go Modules 在特定場景下的行為進行了調整，旨在提高構建的確定性和可復現性。

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

當顯式啟用模塊感知模式（通過設置環境變量 GO111MODULE=on），但當前目錄及所有父目錄中都 沒有 找到 go.mod 文件時，大多數與模塊相關的 go 命令（如 go build, go run, go test 等）的功能會受到限制。

• 限制 ：在沒有 go.mod 的情況下，這些命令只能構建：

a.標準庫中的包 (e.g., fmt, net/http)。

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

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

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

      b.不可復現 ：不同時間或不同環境下執行相同的命令，可能會因為依賴的最新版本發生變化而得到不同的結果，甚至構建失敗。

      c.Go 1.14 的改變 ：為了強制實現可復現構建，Go 1.14 限制了在無 go.mod 時隱式解析和下載依賴的能力。你需要一個 go.mod 文件來明確管理你的項目依賴。

不受影響的命令:

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

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

# 確保模塊模式開啟
export GO111MODULE=on

# 創建一個沒有 go.mod 的目錄
mkdir /tmp/no_gomod_test
cd /tmp/no_gomod_test

# 創建一個簡單的 main.go
echo 'package main; import "fmt"; func main() { fmt.Println("Hello from main.go") }' > main.go

# 1. 構建標準庫包 (可以)
# (這個命令本身意義不大，只是演示可以訪問標準庫)
# go build fmt 

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

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

# 4. 嘗試直接運行需要外部依賴的包 (Go 1.14+ 會報錯)
# go run rsc.io/quote/cmd/quote # Go 1.14+ 報錯

# 5. 使用 go get 下載特定版本 (仍然可以)
go get rsc.io/quote@v1.5.2 
# 現在再運行上面的 go build need_dep.go 或 go run ... 可能會成功，因為它在緩存里了
# 但這仍然不是推薦的工作方式，因為它沒有被 go.mod 記錄

cd ..
rm -rf /tmp/no_gomod_test

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

Go Modules 使用語義化版本（Semantic Versioning）。主版本號（Major Version）的改變通常意味著不兼容的 API 變更。Go 1.14 對 go get 和 go list 處理不兼容主版本的方式進行了調整。

• 條件 ：當你嘗試獲取或更新一個模塊，并且該模塊的 最新版本 已經包含了 go.mod 文件時。
• go get 的行為 ：

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

b.它只會升級到當前主版本內的最新兼容版本（例如，從 v1.4.0 升級到 v1.5.2）。

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

• go list 的行為 ：

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

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

這個改變有助于防止意外引入破壞性的 API 變更，使得依賴管理更加安全和可控。對于那些在引入 Go Modules 之前就已經發布了 v2+ 版本但沒有遵循模塊路徑約定的模塊，Go 會使用 +incompatible 標記（例如 example.com/mod v2.0.1+incompatible）來標識它們。

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

# 當前項目的 go.mod 文件:
# module myproject
# go 1.14
# require example.com/mod v1.4.0

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

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

新增 hash/maphash 包

Go 1.14 標準庫中增加了一個新的包：hash/maphash。這個包提供了一種用于對字節序列（[]byte 或 string）進行哈希計算的函數。

主要用途:

hash/maphash 主要設計用于實現 哈希表（hash tables, 在 Go 中通常指 map）或其他需要將任意字符串或字節序列映射到 64 位無符號整數（uint64）上，并期望結果具有良好均勻分布的數據結構。

核心特性:

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

a.密碼哈希存儲

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

c.數字簽名

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

4. 進程內穩定，跨進程不穩定:

• 對于一個給定的字節序列，在 同一個 Go 進程 的單次執行過程中，其 maphash 哈希值是 穩定不變 的。
• 但是，對于同一個字節序列，在 不同的 Go 進程 中，或者 同 一個程序的多次不同執行 中，計算出的 maphash 哈希值 幾乎肯定會不同。

為什么跨進程不穩定？

這是故意設計的。maphash 使用一個 哈希種子（seed） 來初始化其內部狀態。這個種子在每個 Go 程序啟動時由運行時隨機生成（通過 maphash.MakeSeed()）。這意味著每次運行程序時，哈希函數都會使用不同的種子，從而產生不同的哈希序列。

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

基本用法:

package main

import (
    "fmt"
    "hash/maphash"
)

func main() {
    // 1. 創建一個 maphash.Hash 實例
    // 它會自動使用當前進程的隨機種子進行初始化
    var h maphash.Hash

    // 如果需要對同一個哈希對象計算多個哈希值，需要 Reset
    // (或者為每個值創建新的 Hash 對象)

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

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

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


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


    // 6. 再次計算第一個值，驗證進程內穩定性
    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.

如果你運行上面的程序多次，你會發現每次運行時輸出的哈希值都不同，但每次運行內部 hash1 和 hash4 的值總是相同的。

hash/maphash 為 Go 開發者提供了一個內置的、快速且適合用于哈希表實現的哈希函數，同時通過隨機種子避免了潛在的安全風險。

參考資料

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