Go 编译器崩溃背后：一个 append 函数引发的语言规范修正案

十一月 30, 2025

本文永久链接 – https://tonybai.com/2025/11/30/ice-assertion-failed-with-append

大家好，我是Tony Bai。

在软件开发中，我们有时会遇到一些“显而易见”的错误。对于 Go 开发者而言，append 内建函数的第一个参数必须是切片，似乎就是这样一个“常识”。然而，当一个本应产生清晰编译错误的“常识性”错误，却导致了 Go 1.25.4 编译器的内部崩溃 (Internal Compiler Error, ICE) 时，事情就变得不再简单。

近期，Go 社区报告的一个 Bug (#76220) 和 Go 核心团队的后续跟进 (#76226)，为我们上演了一出精彩的“技术侦探剧”。这个故事不仅关乎一个 Bug 的修复，更深刻地揭示了 Go 语言规范的演进哲学：在语言的设计中，没有不言自明的“常识”，只有需要被精确定义的“规范”。

案发现场：一个“不该发生”的内部编译器错误 (ICE)

故事始于一位开发者 (@anderseknert) 在重构代码时，无意中写下了一段临时性的、显然无效的代码：

package main

func main() {
    s := "hello"
    // 错误：append 的第一个参数是 untyped nil，而非 slice
    msg := append(nil, s...)
    print(msg)
}

所有 Gopher 都知道这段代码不应该通过编译。事实上，在 Go 1.24 中，编译器会给出一个清晰、正确的错误提示：

first argument to append must be a slice; have untyped nil

然而，在 Go 1.25.4 中，同样的代码却导致了编译器自身的恐慌 (panic)，抛出了一个致命的内部编译器错误 (ICE)。这是一个严重的回归 (Regression)，因为它破坏了工具链的健壮性：

$go run main.go
# command-line-arguments
<unknown line number>: internal compiler error: panic: cmd/compile/internal/types2/builtins.go:1093: assertion failed

Please file a bug report including a short program that triggers the error.

https://go.dev/issue/new

从修复 Bug 到修正规范：Griesemer 的深层思考

Go 核心团队的 Robert Griesemer 迅速认领并修复了这个 Bug。然而，他并没有止步于此。在修复的过程中，他敏锐地洞察到了这个 Bug 能够产生的深层原因——Go 语言规范中一处极其微妙的文本歧义。

他为此创建了一个新的 issue (#76226)，专门探讨 append 特殊用法的规范描述问题。

规范中的“漏洞”

append 有一个广为人知的特殊用法：可以将一个 string 的内容追加到一个 []byte 切片后。Go 语言规范中对这个特殊情况的描述（旧版）是：

As a special case, append also accepts a first argument assignable to type []byte with a second argument of string type…
(作为一个特例，append 也接受一个可赋值给 []byte 类型的第一个参数，以及一个字符串类型的第二个参数…)

Griesemer 指出，问题就出在这里：在 Go 中，预声明的标识符 nil 是可以赋值给任何切片类型的，包括 []byte。

因此，如果一个开发者（或者未来的 AI 代码生成器）严格地、像解析法律条文一样去解读这段规范，他完全有可能得出一个“合乎逻辑”的结论：append(nil, “string”…) 应该是合法的！

这种规范文本与编译器实际行为之间的“缝隙”，正是滋生 Bug 和混乱的温床。

“滴水不漏”的修正案

为了彻底消除这种歧义，Griesemer 提交了一份对语言规范的修改提案。

旧版描述:

…accepts a first argument assignable to type []byte…

新版描述 (Go 1.26):

…accepts a slice whose type is assignable to type []byte…
(…接受一个其类型可赋值给 []byte 的切片…)

这个改动极其微小，但意义重大。它通过明确加入 “slice” (切片) 这个词，将隐含的“常识”变成了明确的“规则”，从根本上堵住了任何可能的误读。

对 Go 开发者的影响与启示

这个从 Bug 修复到规范修正的完整闭环，为我们揭示了 Go 社区和核心团队工作的几个重要侧面：

严谨性高于一切：Go 团队追求的，不仅仅是让编译器“在大多数情况下做对的事”，而是让语言的规范、实现和用户直觉三者之间，达到尽可能的统一和精确。
社区报告的价值：一个开发者在日常工作中遇到的工具链崩溃，只要被清晰地报告出来，就可能成为推动语言本身进步的催化剂。这体现了 Go 社区开放、协作的强大力量。
Go 是一部“活的法典”：Go 语言规范并非一成不变的石碑。它在社区的共同监督和核心团队的精心维护下，持续地、审慎地进行着自我完善，以追求更高的清晰度和健壮性。