本系列旨在梳理 Go 的 release notes 与发展史，来更加深入地理解 Go 语言设计的思路。
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
根据上述规则和示例：
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显然也不能导入。
- 它的父目录是
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。
if len(data) == 0 {
// 没有剩余数据且已达 EOF，停止扫描。
return 0, nil, nil
}
// 如果有剩余数据，返回它作为最后一个 token。
return len(data), data, nil
}
// 没有逗号，也没到 EOF，请求 Scanner 读取更多数据
return 0, 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，知道扫描结束。关键在于，第三步已经成功返回了末尾的空令牌""。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。