本系列旨在梳理 Go 的 release notes 与发展史，来更加深入地理解 Go 语言设计的思路。
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 包。
文件树示例：
假设我们有如下的项目结构：
[code]/home/user/└── myproject/ ├── go.mod ├── cmd/ │ └── myapp/ │ └── main.go |
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
