fmt.Stringer 不生效主因是接收者类型不匹配，必须确保 String() 定义在指针或值类型上与调用实例一致；禁止 panic、阻塞或 I/O；嵌套结构需手动调用子项 String()；%#v 优先使用 GoStringer。
为什么 fmt.Stringer 有时不生效？
直接给结构体实现 String() 方法却没看到效果，大概率是因为你忘了：这个方法必须定义在**指针类型**上，而调用方传入的是值类型。Go 的接口匹配是严格按接收者类型来的——type T struct{} 和 *T 是两个完全不同的类型。
常见错误现象：fmt.Printf("%v", myStruct) 仍输出字段内容，而不是你写的 String() 返回值。
实操建议：
- 检查
String()方法的接收者：必须是func (t *MyType) String() string（如果常以指针形式使用）或func (t MyType) String() string（如果值类型足够轻量且不会被取地址） - 确认调用时传入的是同一类型：若方法在
*MyType上，就别对MyType{}值直接调用fmt.Println—— 它不会自动取地址 - 用
fmt.Printf("%+v", &myStruct)快速验证指针是否触发了String()
String() 方法里不能 panic 或阻塞
fmt 包在内部调用 String() 时不做 recover，一旦 panic 就直接崩溃；同时，如果该方法做了网络请求、锁等待或复杂计算，会拖慢所有日志、调试和错误打印，尤其在 error 类型嵌套或 HTTP handler 中被隐式调用时更危险。
实操建议：
- 把耗时逻辑移出
String()，只做纯内存格式化（如拼接字段、加前缀） - 避免在
String()中调用其他可能 panic 的函数，比如json.Marshal（它可能因循环引用 panic） - 若需调试复杂状态，可额外提供
DebugString()方法，显式调用，不走fmt.Stringer
和 fmt.GoStringer 混用时要注意优先级
当一个类型同时实现了 fmt.Stringer 和 fmt.GoStringer，%v 和 %s 用前者，但 %#v 会优先用后者——这是 Go 的硬编码规则，不是可配置行为。
使用场景：你想让 fmt.Printf("%#v", x) 输出类似 Go 字面量的结构（如 &MyType{Name:"foo"}），而 %v 输出可读摘要（如 "[User: foo]"）。
实操建议：
- 不要指望
GoStringer替代Stringer，它们定位不同：String()面向用户/日志，GoString()面向开发者调试 - 若只实现一个，优先实现
String()；GoStringer属于进阶需求，且容易写错（比如返回非法 Go 语法） - 注意
GoString()返回值必须是合法 Go 表达式，否则%#v可能输出意外结果
嵌套结构中 String() 不会自动递归调用
如果 A 结构体字段里嵌了 B 类型，而 B 实现了 Stringer，但 A 没实现，那么 fmt.Printf("%v", A{}) 依然会原样打印 B 的字段，不会调用 B 的 String() —— fmt 只对最外层接口值做一次判断，不深入字段。
性能影响：手动在 A 的 String() 里调用 b.String() 是安全的，但要注意避免无限递归（比如 A 和 B 相互引用，又都在 String() 中调对方）。
实操建议：
- 若字段类型已实现
Stringer，在父结构的String()中显式调用它，而非依赖自动展开 - 对可能为空的指针字段，先判空再调
.String()，否则 panic - 避免在
String()中深度遍历 slice/map 并逐个调子项String()，这会让日志变慢且难以控制长度
真正麻烦的不是怎么写 String()，而是它会在你完全没意识到的地方被调用——比如 HTTP 错误日志、pprof 栈追踪、test 输出。越早统一规范（比如禁止在 String() 中做任何 I/O 或锁操作），后期排查越省力。
