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

Go 1.4 值得關注的改動：

• for-range 循環語法更加靈活。在 Go 1.4 之前，即使你只關心循環迭代本身，而不使用循環變量（index/value），也必須顯式地寫一個變量（通常是空白標識符 _），如 for _ = range x {}。Go 1.4 允許省略循環變量，可以直接寫成 for range x {}。雖然這種場景不常見，但在需要時能讓代碼更簡潔。
• 修復了編譯器允許對指向指針的指針（pointer-to-pointer）類型直接調用方法的問題。Go 語言規范允許對指針類型的值進行方法調用時自動插入一次解引用（dereference），但只允許一次。例如，若類型 T 有方法 M()，t 是 *T 類型，則 t.M() 合法。然而，Go 1.4 之前的編譯器錯誤地接受了對 **T 類型的變量 x 直接調用 x.M()，這相當于進行了兩次解引用，違反了規范。Go 1.4 禁止了這種調用，這是一個破壞性變更（breaking change），但預計實際受影響的代碼非常少。
• 擴展了對新操作系統和架構的支持。Go 1.4 引入了對在 ARM 處理器上運行 Android 操作系統的實驗性支持，可以構建 Go 應用或供 Android 應用調用的 .so 庫。此外，還增加了對 ARM 上的 Native Client (NaCl) 以及 AMD64 架構上的 Plan 9 操作系統的支持。
• Go 運行時（runtime）的大部分實現從 C 語言遷移到了 Go 語言。這次重構使得垃圾回收器（garbage collector）能夠精確地掃描運行時自身的棧，實現了完全精確的垃圾回收，從而減少了內存占用。同時，棧（stack）的實現改為連續棧（contiguous stacks），解決了棧熱分裂（hot split）問題，并為 Go 1.5 計劃中的并發垃圾回收（concurrent garbage collector）引入了寫屏障（write barrier）機制。
• 引入了 internal 包機制和規范導入路徑（canonical import path）檢查。internal 包提供了一種方式來定義只能被特定代碼樹內部導入的包，增強了大型項目代碼的封裝性。規范導入路徑通過在 package 聲明行添加特定注釋來指定唯一的導入路徑，防止同一個包被通過不同路徑導入，提高了代碼的可維護性。
• 修復了 bufio.Scanner 在處理文件結束符（EOF）時的行為。此修復確保了即使在輸入數據耗盡時，自定義的分割函數（split function）也會在文件結束符（EOF）處被最后調用一次。這使得分割函數有機會按預期生成一個最終的空令牌（token），但也可能影響依賴舊有錯誤行為的自定義分割函數。

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

Runtime 重構與核心變化

Go 1.4 的一個里程碑式的改動是將運行時的絕大部分代碼從 C 語言和少量匯編遷移到了 Go 語言實現。這次重構雖然龐大，但其設計目標是對用戶程序在語義上透明，同時帶來了幾個關鍵的技術進步和性能優化。

首先，這次遷移使得 Go 1.4 的垃圾回收器（GC）能夠實現 完全精確（fully precise） 的內存管理。精確 GC 意味著回收器能夠準確地識別內存中哪些是活躍的指針，哪些不是。在此之前，GC 可能存在保守掃描（conservative scanning）的情況，即把一些非指針的數據（比如整數）誤判為指針，導致這些數據引用的內存無法被回收（稱為“假陽性”）。精確 GC 消除了這種假陽性，能夠更有效地回收不再使用的內存，根據官方文檔，這使得程序的堆（heap）內存占用相比之前版本減少了 10%-30%。

其次，Goroutine 的 棧（stack）實現從分段棧（segmented stacks）改為了連續棧（contiguous stacks）。這一點在 Go 1.3 中也提及了：每個 Goroutine 的棧由多個小的、不連續的內存塊（段）組成。當一個函數調用需要的棧空間超過當前段的剩余空間時，會觸發“棧分裂”，分配一個新的棧段。這種機制的主要缺點是 “棧熱分裂（hot split）” 問題：如果一個函數調用頻繁地發生在棧段即將耗盡的邊界處，就會導致在循環中頻繁地分配和釋放新的棧段，帶來顯著的性能開銷，且性能表現難以預測。

Go 1.4 采用的連續棧則為每個 Goroutine 分配一塊連續的內存作為其棧。當棧空間不足時，運行時會分配一塊更大的新連續內存，將舊棧的全部內容（所有活躍的棧幀）復制到新棧，并更新棧內部指向自身的指針。這個過程依賴于 Go 的逃逸分析（escape analysis）保證，即指向棧上數據的指針通常只存在于棧自身內部（向下傳遞），使得復制和指針更新成為可能。雖然復制棧有成本，但它是一次性的（直到下一次增長），避免了熱分裂問題，使得性能更加穩定和可預測。正如 Go 1.3 的設計文檔（Contiguous Stacks design document）中所討論的，這種方式解決了分段棧的核心痛點。

由于連續棧消除了熱分裂帶來的性能懲罰，Goroutine 的 初始棧大小得以顯著減小。Go 1.4 將 Goroutine 的默認初始棧大小從 8192 字節（8KB）降低到了 2048 字節（2KB），這有助于在創建大量 Goroutine 時節省內存。

再次，為了給 Go 1.5 計劃引入的 并發垃圾回收（concurrent garbage collector） 做準備，Go 1.4 引入了 寫屏障（write barrier）。寫屏障是一種機制，它將程序中對堆（heap）上指針值的寫入操作從直接的內存寫入，改為通過一個運行時函數調用來完成。在 Go 1.4 中，這個屏障本身可能還沒有太多實際的 GC 協調工作，主要是為了測試其對編譯器和程序性能的影響。在 Go 1.5 中，當 GC 與用戶 Goroutine 并發運行時，寫屏障將允許 GC 介入和記錄這些指針寫入操作，以確保 GC 的正確性（例如，防止 GC 錯誤地回收被用戶代碼新近引用的對象）。

此外，接口值（interface value）的內部實現也發生了改變。在早期版本中，接口值內部根據存儲的具體類型（concrete type）是持有指向數據的指針，還是直接存儲單字大小的標量值（如小整數）。這種雙重表示給 GC 處理帶來了復雜性。從 Go 1.4 開始，接口值 始終 存儲一個指向實際數據的指針。對于大多數情況（接口通常存儲指針類型或較大的結構體），這個改變影響很小。但對于將小整數等非指針類型的值存入接口的場景，現在會觸發一次額外的堆內存分配，以存儲這個值并讓接口持有指向它的指針。

最后，關于 無效指針檢查。Go 1.3 引入了一個運行時檢查，如果發現內存中本應是指針的位置包含明顯無效的值（如 3），程序會崩潰。這旨在幫助發現將整數錯誤地當作指針使用的 bug。然而，一些（不規范的）代碼確實可能這樣做。為了提供一個過渡方案，Go 1.4 增加了 GODEBUG 環境變量 invalidptr=0。設置該變量可以禁用這種崩潰。但官方強調這只是一個臨時解決方法，不能保證未來版本會繼續支持，正確的做法是修改代碼，避免將整數和指針混用（類型別名）。

Internal 包：增強封裝性

Go 語言通過導出（exported, 首字母大寫）和未導出（unexported, 首字母小寫）標識符提供了基本的代碼封裝能力。對于一個獨立的包來說，這通常足夠了。但是，當一個大型項目（比如一個復雜的庫或應用程序）本身需要被拆分成多個內部協作的包時，問題就出現了。如果這些內部包之間需要共享一些公共函數或類型，按照 Go 的可見性規則，這些共享的標識符必須是導出的（首字母大寫）。但這會導致一個不希望的副作用：這些本應只在項目內部使用的 API，也意外地暴露給了項目的最終用戶。外部用戶可能會開始依賴這些內部實現細節，使得項目維護者未來重構或修改內部結構變得困難，因為需要考慮對這些“非官方”用戶的兼容性。

為了解決這種“要么全公開，要么全包內私有”的二元限制，Go 1.4 引入了一個由 go 工具鏈強制執行的約定： internal 包 。

核心規則：

如果一個目錄名為 internal，那么位于這個 internal 目錄（及其子目錄）下的所有包，只能被 直接包含 該 internal 目錄的 父目錄 及其 子樹 中的代碼所導入。任何處于這個父目錄樹之外的代碼都無法導入該 internal 包。

文件樹示例：

假設我們有如下的項目結構：

/home/user/
└── myproject/
    ├── go.mod
    ├── cmd/
    │   └── myapp/
    │       └── main.go       <- 可以導入 internal/util, *不能* 導入 pkg/internal/core
    ├── pkg/
    │   ├── api/
    │   │   └── handler.go    <- 可以導入 internal/util 和 pkg/internal/core
    │   └── internal/         <- 這是 pkg 目錄下的 internal
    │       └── core/
    │           └── core.go   <- 定義內部核心功能
    ├── internal/             <- 這是項目根目錄下的 internal
    │   └── util/
    │       └── util.go       <- 定義項目范圍的內部工具
    └── vendor/               <- (無關)
    └── anotherpkg/           <- 一個與 pkg 平級的目錄
        └── service.go        <- *不能* 導入 internal/util 或 pkg/internal/core
/home/user/
└── otherproject/
    └── main.go               <- *不能* 導入 myproject/internal/util 或 myproject/pkg/internal/core

根據上述規則和示例：

1. myproject/internal/util 包：

• 它的父目錄是 myproject/。
• 因此，只有 myproject/ 目錄及其所有子目錄中的代碼（如 myproject/cmd/myapp/main.go, myproject/pkg/api/handler.go）可以導入 myproject/internal/util。
• myproject/anotherpkg/service.go 因為不在 myproject/ 的子樹中（雖然在同一個項目下，但 internal 的直接父級是 myproject，anotherpkg 與 internal 平級），所以不能導入它。
• 外部項目 otherproject/main.go 顯然也不能導入。

2. myproject/pkg/internal/core 包：

• 它的父目錄是 myproject/pkg/。
• 因此，只有 myproject/pkg/ 目錄及其所有子目錄中的代碼（如 myproject/pkg/api/handler.go）可以導入 myproject/pkg/internal/core。
• 位于 myproject/cmd/myapp/main.go 的代碼，雖然也在 myproject 項目內，但它不屬于 myproject/pkg/ 的子樹，所以 不能 導入 myproject/pkg/internal/core。
• 外部項目和 myproject/anotherpkg 同理，也不能導入。

總結： internal 目錄就像一道屏障，它允許其“直系親屬”（父目錄及其后代）訪問內部成員，但阻止了所有“外人”（包括同一項目中的非后代包以及其他項目）的訪問。

這個檢查是由 go build, go test 等 go 命令在編譯時強制執行的。在 Go 1.4 中，此規則首先應用于 Go 標準庫（$GOROOT）自身的組織，從 Go 1.5 開始，該規則被推廣到所有用戶的 GOPATH 和后來的 Go Modules 項目中。

規范導入路徑：確保唯一性與可維護性

在 Go 中，開發者可以使用 go get 工具方便地獲取和安裝托管在公共服務（如 github.com）上的代碼。包的導入路徑通常就反映了其托管位置，例如 github.com/user/repo。然而，Go 也提供了一種機制，允許開發者設置 自定義導入路徑（custom/vanity import paths），比如使用自己的域名 mycompany.com/mylib，并通過在 mycompany.com/mylib 這個 URL 提供特定的 HTML <meta> 標簽，將 go get 工具重定向到實際的代碼倉庫（例如 github.com/user/repo）。

這種自定義路徑很有用，它可以：

• 為包提供一個穩定的、與托管服務無關的名稱。即使未來將代碼庫從 GitHub 遷移到 GitLab，只要更新 mycompany.com/mylib 的重定向，使用者的導入路徑無需更改。
• 支持使用 go 工具不直接識別的版本控制系統或服務器。

但這也帶來了一個問題：同一個包現在可能有兩個有效的導入路徑：自定義路徑 (mycompany.com/mylib) 和實際托管路徑 (github.com/user/repo)。這會導致：

• 意外的重復導入：如果一個程序的不同部分不小心通過不同的路徑導入了同一個包，編譯器會認為它們是兩個不同的包，導致代碼冗余，甚至可能因為狀態不共享而引發 bug。
• 更新問題：用戶可能一直使用非官方的托管路徑導入，如果包作者只維護自定義路徑的重定向，用戶可能無法及時獲知更新。
• 破壞兼容性：如果包作者遷移了倉庫并更新了自定義路徑的重定向，那些仍然使用舊托管路徑的用戶代碼會直接編譯失敗。

為了解決這些問題，Go 1.4 引入了 規范導入路徑（canonical import path） 檢查機制。

工作方式： 包的作者可以在其源代碼文件的 package 聲明行的末尾添加一個特定格式的注釋，來聲明該包的 唯一 官方導入路徑。

語法：

package pdf // import "rsc.io/pdf"

或者使用塊注釋：

package pdf /* import "rsc.io/pdf" */

效果： 當 go 命令（如 go build, go install）編譯一個導入了帶有此種注釋的包時，它會檢查導入時使用的路徑是否與注釋中聲明的規范路徑完全一致。如果不一致，go 命令將 拒絕編譯 導入方代碼。

示例： 如果 rsc.io/pdf 包中包含了 package pdf // import "rsc.io/pdf" 的注釋，那么任何試圖 import "github.com/rsc/pdf" 的代碼在編譯時都會失敗。這強制所有使用者都必須使用 rsc.io/pdf 這個規范路徑。

重要提示： 這個檢查是在 構建時（build time） 進行的，而不是在 go get 下載時。這意味著，如果 go get github.com/rsc/pdf 成功下載了代碼，但在后續編譯時因為規范路徑檢查失敗，你需要手動刪除本地 GOPATH 或 Go Modules 緩存中通過錯誤路徑下載的包副本。

相關改進： 為了配合這個特性，go get -u（更新包）命令也增加了一項檢查：它會驗證本地已下載包的遠程倉庫地址是否與其自定義導入路徑解析出的地址一致。如果包的實際托管位置自上次下載后發生了改變（可能意味著倉庫遷移），go get -u 會失敗，防止意外更新。可以使用新的 -f 標志來強制覆蓋此檢查。

子倉庫路徑遷移： Go 官方也借此機會宣布，其下的子倉庫（如 code.google.com/p/go.tools 等）將統一使用 golang.org/x/ 前綴的自定義導入路徑（如 golang.org/x/tools），并計劃在未來（約 2015 年 6 月 1 日）為這些包添加規范導入路徑注釋。屆時，使用 Go 1.4 及更高版本的用戶如果還在使用舊的 code.google.com 路徑，編譯將會失敗。官方強烈建議所有開發者更新其代碼，改用新的 golang.org/x/ 路徑導入這些子倉庫包。好消息是，舊版本的 Go (Go 1.0+) 也能識別和使用新的 golang.org/x/ 路徑，所以更新導入路徑不會破壞對舊 Go 版本的兼容性。

bufio.Scanner EOF 行為變更

bufio.Scanner 是 Go 標準庫中用于方便地讀取輸入流（如文件、網絡連接或字符串）并將其分割成一個個“令牌（token）”的工具。默認情況下，它可以按行或按 UTF-8 單詞分割，但它也允許用戶提供自定義的分割邏輯，即 分割函數（SplitFunc）。

SplitFunc 的類型簽名是：

type SplitFunc func(data []byte, atEOF bool) (advance int, token []byte, err error)

• data: 當前 Scanner 緩沖區中剩余未處理的數據。
• atEOF: 一個布爾值，指示是否已經到達輸入流的末尾（End Of File）。**true 表示底層 reader 不會再提供更多數據了**。
• advance: SplitFunc 應該告訴 Scanner 消耗掉 data 中的多少字節。
• token: 這次調用找到的令牌。如果還沒找到完整的令牌，可以返回 nil。
• err: 如果遇到錯誤，返回非 nil 的 error。

Go 1.4 之前的行為與問題：

在 Go 1.4 之前，Scanner 在處理 EOF 時存在一個微妙的問題。當輸入流恰好在最后一個有效令牌的分隔符之后結束時，或者當輸入流為空時，SplitFunc 可能無法可靠地生成一個預期的、位于流末尾的 空令牌。文檔承諾了可以做到這一點，但實際行為有時不一致。

Go 1.4 的修復與新行為：

Go 1.4 修復了這個問題。現在的行為更加明確和可靠：**當輸入流耗盡后，SplitFunc 保證會被最后調用一次，并且這次調用時 atEOF 參數為 true**。這次調用給予了 SplitFunc 處理輸入結束狀態的最后機會，使其能夠根據需要生成最后一個令牌，即使這個令牌是空的。

代碼示例：

假設我們要實現一個按逗號分割的 SplitFunc，并且希望正確處理末尾的空字段（例如 "a,b," 應該產生三個令牌："a", "b", ""）。下面是一個能體現 Go 1.4 行為的實現：

package main

import (
"bufio"
"bytes"
"fmt"
"strings"
)

// customSplit: 按逗號分割，能處理末尾空字段
func customSplit(data []byte, atEOF bool) (advance int, token []byte, err error) {
// 查找第一個逗號
if i := bytes.IndexByte(data, ','); i >= 0 {
// 找到逗號，返回逗號之前的部分
return i + 1, data[:i], nil
 }

// 沒有找到逗號
if atEOF {
// 如果是 EOF，無論 data 是否為空，都認為掃描結束。
        // data 中剩余的部分（如果非空）是最后一個 token。
iflen(data) == 0 {
   // 沒有剩余數據且已達 EOF，停止掃描。
   return0, nil, nil
  }
// 如果有剩余數據，返回它作為最后一個 token。
returnlen(data), data, nil
 }

// 沒有逗號，也沒到 EOF，請求 Scanner 讀取更多數據
return0, nil, nil
}

func main() {
 inputs := []string{
"a,b,c",     // 標準情況
"a,b,",      // 末尾有逗號，應有空字段
"",          // 空輸入
"a",         // 單個字段
",a,b",      // 開頭有逗號，應有空字段
"a,,b",      // 中間有逗號，應有空字段
 }

for _, input := range inputs {
  fmt.Printf("Scanning input: %q\n", input)
  scanner := bufio.NewScanner(strings.NewReader(input))
  scanner.Split(customSplit)

  count := 0
for scanner.Scan() {
   count++
   fmt.Printf("  Token %d: %q\n", count, scanner.Text())
  }

if err := scanner.Err(); err != nil {
   fmt.Printf("  Error during scan: %v\n", err)
  }
  fmt.Println("---")
 }
}

預期輸出 (Go 1.4 及以后):

Scanning input: "a,b,c"
  Token 1: "a"
  Token 2: "b"
  Token 3: "c"
---
Scanning input: "a,b,"
  Token 1: "a"
  Token 2: "b"
  Token 3: ""
---
Scanning input: ""
---
Scanning input: "a"
  Token 1: "a"
---
Scanning input: ",a,b"
  Token 1: ""
  Token 2: "a"
  Token 3: "b"
---
Scanning input: "a,,b"
  Token 1: "a"
  Token 2: ""
  Token 3: "b"
---

主要的區別在于輸入 "a,b,"。在 Go 1.4 之前的版本中，由于 bufio.Scanner 的 bug，最后一個由結尾逗號產生的空令牌 "" 無法被正確掃描出來，導致輸出只有 "a" 和 "b"。而 Go 1.4 修復了這個 bug，使得輸出能正確包含 "a", "b" 和 ""。其他不涉及嚴格在 EOF 產生空令牌的情況，輸出行為通常是一致的。

解釋:

在 Go 1.4 及以后版本，對于輸入 "a,b,"：

• SplitFunc 找到第一個逗號，返回 "a"。
• SplitFunc 找到第二個逗號，返回 "b"。
• SplitFunc 找到第三個逗號，返回 "" (空字符串)。
• 此時 data 變為 ""，Scanner 讀取發現已到 EOF。
• Scanner 最后一次調用 SplitFunc，傳入 data 為 []byte("") 且 atEOF 為 true。
• customSplit 函數根據邏輯，因為 len(data) 為 0，返回 (0, nil, nil)。
• Scanner 接收到 (0, nil, nil) 且 atEOF 為 true，知道掃描結束。關鍵在于，第三步已經成功返回了末尾的空令牌 ""。