Go语言中，类型必须实现Error() string方法才能满足error接口并被当作错误使用；若未实现该方法，即使结构体含msg或code字段也无法参与错误处理。
需要。Go 语言中，只要类型实现了 Error() 方法（签名是 func() string），它就被视为一个错误（即满足 error 接口）。不实现该方法，就无法被当作 error 使用。
为什么必须实现 Error() 方法
Go 的 error 是一个内建接口：
type error interface {
Error() string
}
任何值要参与错误处理（比如用在 if err != nil、fmt.Println(err)、log.Fatal(err) 等场景），都必须满足这个接口。没有 Error() 方法，哪怕结构体字段里有 msg 或 code，也无法被识别为错误。
常见错误写法：只带字段，没方法
下面这种定义看似合理，但实际不能当 error 用：
立即学习“go语言免费学习笔记（深入）”；
type MyError struct {
Message string
Code int
}
它会直接导致编译错误或运行时 panic（比如传给 fmt.Errorf 的格式动词 %v 虽能打印结构体，但 fmt.Printf("%s", err) 会报错：cannot convert MyError to string）。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
正确做法是补上 Error() 方法：
func (e *MyError) Error() string {
return fmt.Sprintf("code=%d, message=%s", e.Code, e.Message)
}
- 注意接收者用指针
*MyError还是值MyError：如果结构体较大，建议用指针避免拷贝；若只含小字段（如string+int），值接收者也完全可接受 -
Error()方法必须返回string，不能是fmt.Sprintf失败时的空字符串或 panic —— 它应始终返回有意义的描述
是否必须用指针实例化？
不是强制，但和方法接收者类型强相关：
- 如果你定义的是
func (e *MyError) Error()，那么MyError{...}（值）调用Error()会被自动取地址，没问题；但var e MyError; e.Error()也没问题 - 但若你定义的是
func (e MyError) Error()（值接收者），那&MyError{...}也能调用，Go 会自动解引用 - 真正要注意的是：不要混用指针/值接收者去实现同一接口的多个方法，否则可能部分方法不可见
更推荐的做法：用 errors.New 或 fmt.Errorf 包装
如果只是加个上下文，没必要自定义结构体：
err := errors.New("failed to open file")
err = fmt.Errorf("while processing config: %w", err)
但如果需要携带额外字段（如 HTTP 状态码、重试次数、原始错误链），才值得定义结构体并实现 Error()。此时还应考虑实现 Unwrap()（用于错误链）和 Is()/As() 支持（用于类型断言），但这属于进阶需求。
最容易被忽略的一点：很多人写了 Error() 方法，却在返回字符串里漏掉关键信息（比如只返回 e.Message，但 e.Code 永远不出现），导致日志里看不出错误类型——这会让排查变成盲猜。
