go 中，当一个类型同时满足 error 和 fmt.stringer 接口时，fmt 包默认优先调用 error() 方法而非 string()；本文详解其原因，并提供通过指针/值接收器分离实现的可靠方案。

go 中，当一个类型同时满足 error 和 fmt.stringer 接口时，fmt 包默认优先调用 error() 方法而非 string()；本文详解其原因，并提供通过指针/值接收器分离实现的可靠方案。

在 Go 的格式化机制中，fmt 包对输出行为有明确的接口优先级规则：当一个值同时实现了 error 和 fmt.Stringer，fmt（如 fmt.Println、fmt.Sprintf）会无条件优先使用 error.Error() 方法进行字符串化，完全忽略 String() 方法。这不是 bug，而是设计使然——error 接口被赋予了语义上的特殊地位，代表“可报告的错误状态”，因此 fmt 将其视为更高优先级的格式化依据。

这意味着，以下代码不会按预期打印 "Custom string"：

type MyErr struct{ msg string }
func (e MyErr) Error() string { return "error: " + e.msg }
func (e MyErr) String() string { return "Custom string" }

fmt.Println(MyErr{"oops"}) // 输出：error: oops（而非 Custom string）

✅ 可行解法：利用接收器类型差异实现“双接口共存”

Go 的接口实现判定基于方法集（method set）：

• 类型 T 的值接收器方法属于 T 和 *T 的方法集；
• 但 *T 的指针接收器方法*仅属于 `T的方法集，不属于T` 的方法集**。

因此，我们可以将 error 实现绑定到值接收器（让 MyErr 类型本身满足 error），而将 fmt.Stringer 实现绑定到指针接收器（让 *MyErr 满足 Stringer，但 MyErr 不满足）。这样，当传入值类型（如 MyErr{}）时，fmt 只看到 Error()，调用它；当显式传入指针（如 &MyErr{}）时，fmt 同时看到 Error() 和 String()，但仍优先 Error() —— 所以真正关键在于：避免让同一个实例同时满足两个接口。

更实用的策略是：让 error 实现用值接收器，Stringer 实现用指针接收器，并在需要自定义格式时显式传指针：

type MyErr struct{ msg string }

func (e MyErr) Error() string { return "err: " + e.msg }     // ✅ MyErr 满足 error
func (e *MyErr) String() string { return "→ " + e.msg }    // ✅ *MyErr 满足 Stringer

// 使用示例：
e := MyErr{"timeout"}
fmt.Println(e)        // → "err: timeout" （只识别 Error）
fmt.Println(&e)       // → "→ timeout"    （识别 String()，因 *MyErr 有 String，且未实现 error？等等！）

// ⚠️ 注意：*MyErr 也隐含满足 error（因 *MyErr 的方法集包含 MyErr.Error()）
// 所以 &e 仍会触发 Error() —— 这正是问题所在。

因此，上述方式仍不彻底。真正可靠的模式是：将 error 实现放在指针上，Stringer 放在值上，并确保 error 方法不暴露给值类型：

type MyErr struct{ msg string }

func (e *MyErr) Error() string { return "err: " + e.msg } // ✅ *MyErr 满足 error
func (e MyErr) String() string { return "str: " + e.msg } // ✅ MyErr 满足 Stringer

// 现在：
var e MyErr = MyErr{"failed"}
fmt.Println(e)   // → "str: failed" （MyErr 满足 Stringer，但不满足 error → 用 String）
fmt.Println(&e)  // → "err: failed" （*MyErr 满足 error → 用 Error）

// ✅ 成功分离：值类型走 Stringer，指针类型走 error

该方案的核心在于：MyErr 值类型不实现 error（因 Error() 是指针接收器），所以 fmt 对 e 只能找到 String()；而 &e 是指针类型，同时满足 error（优先）和 Stringer，故调用 Error()。

? 注意事项与最佳实践

• 永远不要依赖“同时实现两个接口并期望 fmt 选 Stringer”：这是反模式，Go 明确禁止覆盖 error 的优先级。
• 推荐场景：当你需要同一数据结构在不同上下文中呈现不同格式（如日志中显示详细调试信息 String()，而返回给调用方时作为标准错误 Error()），应显式控制传入的是值还是指针。
• 构造函数建议：提供 NewMyErr() 返回 *MyErr（符合 error 惯例），同时允许用户直接使用字面量 MyErr{} 触发 String()。
• nil 安全性：若 String() 使用指针接收器，需检查 e == nil；本方案中 String() 是值接收器，天然安全。

综上，Go 中 error 的格式化优先级不可绕过，但通过精准控制接收器类型，可优雅实现“一数两用”：值类型用于可读展示，指针类型用于错误传播。