Go 标准库提供一个“Must” 函数？社区关于“断言式初始化”的思考

本文永久链接 – https://tonybai.com/2025/10/07/proposal-must-do

大家好，我是Tony Bai。

if err != nil 不仅是 Go 代码中最常见的片段，更是其错误处理哲学的基石。它强制开发者在每一个可能出错的地方，都必须直面失败的可能性。然而，当一个错误在理论上可能发生，但在实践中（尤其是在处理静态、已知的常量时）又“不可能”发生时，这种严谨性是否就变成了一种冗余的样板代码？

这种在便利性与哲学纯粹性之间的张力并非新生事物。Go 标准库自身，就在特定场景下为我们提供了“捷径”。例如，text/template 包就提供了一个 Must 函数：

func Must(t *Template, err error) *Template

它接收一个 (*Template, error)，并在 error 不为 nil 时直接 panic。这正是为了简化那些基于静态字符串、本不应失败的模板解析过程。

这种“我断言此操作必不失败，否则就是程序级错误”的模式，可以被称为“断言式初始化” (Assertive Initialization)。

这一既有模式，正是最近一个被Go技术负责人Austin Clements纳入到Active阶段的提案（#54297）的灵感来源。该提案由前Go团队成员 Brad Fitzpatrick 发起，其核心问题是：我们是否应该将这种模式从特定包的“特例”，提升为一个通用的、由标准库提供的泛型函数？

这个看似微小的提议，却在 Go 社区引发了一场关于便利性、最佳实践与语言哲学的深度辩论，在这篇文章中，我们就一起来看看这场辩论的过程，并看看是否能从中学习到一些值得借鉴的东西。

问题的缘起：那些“不可能失败”的失败

Brad Fitzpatrick 最初的痛点非常具体而普遍：在初始化一个 httputil.ReverseProxy 时，你需要一个 *url.URL。而创建一个 *url.URL 的标准方式是调用 url.Parse，这是一个会返回 error 的函数：

// 常见的初始化代码
var proxy *httputil.ReverseProxy

func init() {
    targetURL, err := url.Parse("http://localhost:8080")
    if err != nil {
        panic(fmt.Sprintf("failed to parse URL: %v", err))
    }
    proxy = httputil.NewSingleHostReverseProxy(targetURL)
}

问题在于，url.Parse(“http://localhost:8080″) 这样一个使用硬编码、静态已知的字符串的调用，在实践中是不可能失败的。为了处理这个理论上存在、但现实中永不发生的 error，我们不得不编写 3-4 行错误处理的样板代码。

社区的“最佳实践”：Tailscale 的 must.Get

Brad Fitzpatrick 在提案中顺便分享了他所在的创业公司Tailscale 内部广泛使用的一个 must 包的实现，其核心函数 Get 极其简洁：

package must

// Get 返回 v。如果 err 不为 nil，它会 panic。
func Get[T any](v T, err error) T {
    if err != nil {
        panic(err)
    }
    return v
}

有了这个函数，之前的初始化代码可以被简化为一行优雅的表达式：

var targetURL = must.Get(url.Parse("http://localhost:8080"))

这个小小的辅助函数，其核心价值并不仅仅是减少了代码行数。正如一位评论者所指出的：

“它更大的影响是，使得返回 error 的函数能够被用在表达式中。这常常能将一个冗长的 10-20 行过程，转换为一个 2-3 行的声明。”

争议与权衡：一个“潘多拉魔盒”？

尽管社区中许多开发者都分享了他们自己实现的、类似的 must 包，证明了其广泛的现实需求，但将其引入标准库的提议，依然引发了深刻的担忧。

担忧一：滥用的风险

Ian Lance Taylor 等核心团队成员表达了他们的顾虑：如果标准库提供了一个官方的 must包及相关函数，它是否会被新手或图方便的开发者滥用作常规的错误处理机制？

// 滥用的例子：在处理动态、不可信的用户输入时使用 must
func handleRequest(r *http.Request) {
    // 错误的做法！这里的 err 应该被妥善处理，而不是直接 panic
    body := must.Get(io.ReadAll(r.Body))
    // ...
}

这种滥用，将与 Go 语言核心的错误处理哲学背道而驰，让本应健壮的程序变得脆弱不堪。这正是社区在讨论中反复强调的：must 模式的合法使用场景非常狭窄，它应该仅限于“断言式初始化”的范畴。