Go String 方法里调用 fmt 为什么可能无限递归

给 Go 类型实现 String() string，通常是为了让日志和调试输出更易读。但有一类代码表面上只是“用 fmt 拼一下字符串”，运行时却会不断回到同一个 String()。根因不是 Sprintf 自己递归，而是 fmt 会检查实参的动态类型；当这个值实现了 fmt.Stringer，并且当前格式化路径允许使用字符串表示时，它会再次调用 String()。

消息是什么：问题出在接口分派重新进入 String

fmt.Stringer 只有一个方法：

type Stringer interface {
    // String 返回值的可读文本表示
    String() string
}

实现它之后，值传给 fmt.Print、fmt.Sprintf 或使用适合字符串的格式化动词时，fmt 可能调用这个方法。危险写法是在方法内部又把仍然具有同一动态类型的接收者交还给 fmt：

package main

import "fmt"

type Label string

func (l Label) String() string {
    // 错误：%s 会再次把 Label 当成 Stringer 处理
    return fmt.Sprintf("Label(%s)", l)
}

func main() {
    // 这里第一次进入 Label.String
    fmt.Println(Label("ready"))
}

调用链可以概括为：fmt.Println 看到 Label 实现了 Stringer，调用 Label.String；方法内部的 Sprintf 又看到同一个 Label，于是再次调用 Label.String。终止条件从未出现，最终会因调用栈持续增长而失败。

图1：原接收者未经类型转换又进入 fmt 时形成的递归闭环。它是静态说明图，不是运行时截图。

适用场景：最容易藏在日志与调试代码里

这类问题常见于三处：为枚举或命名字符串补可读前缀、为结构体生成日志摘要、在 String() 内记录异常。第三种尤其隐蔽，因为日志库通常最终仍使用 fmt；即使源码里没有直接写 Sprintf，记录接收者本身也可能绕一圈重新调用 String()。

判断标准很简单：沿着 String() 内部调用向下看，只要同一个接收者以仍实现 Stringer 的动态类型进入格式化链，就存在回到当前方法的可能。反过来，把它转换成不带该方法的类型，或者完全不再使用接口格式化，就能切断闭环。

快速试用：命名基础类型先转回底层类型

对于 type Label string 这类命名基础类型，最直接的修复是显式转换为内置 string。转换后传给 fmt 的动态类型不再是 Label，因此也不再拥有它的 String() 方法。

func (l Label) String() string {
    // 正确：转换后是内置 string，不再实现 Label.String
    return fmt.Sprintf("Label(%s)", string(l))
}

官方《Effective Go》对同类问题给出的核心建议也是先转换接收者。这里关键的不是换一个格式化动词，而是改变传入值的方法集。仅把 %s 换成另一个仍会走 Stringer 的格式，不能从根本上解决问题。

结构体方案：用无方法别名隔离 Stringer

结构体不能转换成内置字符串，可以定义一个底层结构相同、但没有 String() 方法的新类型，再转换后格式化：

type User struct {
    ID   int
    Name string
}

type userRaw User

func (u User) String() string {
    // 转成无方法的新类型，避免再次调用 User.String
    return fmt.Sprintf("User%+v", userRaw(u))
}

userRaw 是新定义的类型，不会继承 User 的方法，因此外层递归被切断。不过还要检查字段：如果某个字段本身实现了有问题的 Stringer，格式化字段时仍可能进入它自己的递归。对日志格式有严格要求时，逐字段拼接通常更容易控制。

和旧方案对比：手工拼接控制力最高

当输出字段固定，直接用 strings.Builder 和 strconv 生成文本，可以完全绕开对接收者的接口分派：

func (u User) String() string {
    var b strings.Builder
    // 手工写入固定结构，不再把 u 整体交给 fmt
    b.WriteString("User{ID:")
    b.WriteString(strconv.Itoa(u.ID))
    b.WriteString(", Name:")
    b.WriteString(u.Name)
    b.WriteByte('}')
    return b.String()
}

三种方案的取舍是：底层类型转换最短，适合命名基础类型；无方法新类型适合快速输出结构体；手工拼接代码稍长，但输出稳定、边界清楚，也不会因为给接收者新增格式化方法而改变行为。

图2：三条切断递归的路径，以及 go vet 在提交前承担的复查位置。

采用风险：方法集和格式化动词都要看

如果 String() 使用值接收者，T 与 *T 都满足 fmt.Stringer；如果使用指针接收者，通常只有 *T 满足接口。于是“同一份数据”以值或指针传入 fmt，可能走不同路径。排查时应看接口中的实际动态类型，不能只看变量声明。

不同格式化动词也会影响分派。比如 %T 用于查看类型，%p 用于查看指针；%#v 还可能涉及 GoStringer。因此不要把“换动词”当作通用修复。可靠做法仍是：在 String() 内不再把原类型整体送回可调用其格式化方法的路径。

最后运行静态检查。Go 的 vet 测试用例专门覆盖了 String 和 Error 方法中的递归格式化调用：

# 检查当前模块内可能的格式化与 Stringer 递归问题
go vet ./...

go vet 是提交前的补充，不替代代码审查。还应检查间接调用：String() 调日志函数、日志函数格式化接收者，同样能形成闭环。

结论

String() 里调用 fmt 并非一律错误；真正危险的是把仍然实现当前 String() 的接收者原样传回格式化系统。命名基础类型转成底层类型，结构体转成无方法新类型，复杂输出改用手工拼接，再配合 go vet ./...，就能把这类无限递归变成可识别、可审查的普通代码问题。