fmt.Sprintf("%s", err)会panic，因%s要求参数实现Stringer或为字符串/字节切片，而error接口的Error()方法不满足该要求；%v自动调用Error()，%w仅用于fmt.Errorf中包装支持Unwrap()的错误。
fmt 包本身不支持错误类型格式化，error 值必须实现 Error() 方法才能被 fmt 正确输出；直接用 fmt.Printf("%s", err) 会 panic，而 %v 或 %w 才是安全选择。
为什么 fmt.Sprintf("%s", err) 会 panic？
因为 err 是接口类型 error，而 %s 要求参数实现 Stringer 或是字符串/字节切片。Go 不会自动调用 Error() 方法来满足 %s——它只认 String()。试图强制转换或格式化会导致运行时 panic：
panic: interface conversion: error is *errors.errorString, not fmt.Stringer
-
%s：仅接受string、[]byte或实现了fmt.Stringer的类型 -
%v：对error自动调用Error()，最常用且安全 -
%w：仅用于fmt.Errorf中包装错误，不能用于fmt.Printf输出
fmt.Errorf 中的 %w 怎么用才不丢堆栈？
%w 是 Go 1.13 引入的动词，专用于在创建新错误时包装原有错误，但前提是原错误支持 Unwrap()（即由 fmt.Errorf(... "%w", ...)、errors.Unwrap 或 xerrors 构建）。否则包装后无法解包：
- 正确：
fmt.Errorf("failed to open file: %w", os.Open("x.txt")) - 错误：
fmt.Errorf("failed: %w", errors.New("no such file"))——errors.New返回的错误不支持Unwrap()，%w会被忽略，等价于%v - 验证是否可解包：
errors.Unwrap(err) != nil，或用errors.Is(err, targetErr)/errors.As(err, &e)
打印带上下文的错误时，该选 %v 还是 %+v？
%+v 只对由 github.com/pkg/errors 或 Go 1.17+ 的 fmt.Errorf（含 %w）构造的错误才显示堆栈；标准库 errors.New 和 fmt.Errorf（无 %w）用 %+v 和 %v 效果完全一样：
立即学习“go语言免费学习笔记（深入）”；
- 有堆栈：
fmt.Errorf("db timeout: %w", context.DeadlineExceeded)→%+v显示调用位置 - 无堆栈：
fmt.Errorf("invalid id")→%+v不额外输出任何内容 - 生产环境慎用
%+v：可能暴露内部路径或敏感调用链，日志中建议统一用%v
自定义错误类型如何让 fmt 输出更清晰？
只需实现 Error() string，但注意不要在其中拼接冗余前缀（如重复写 "error:"），因为上层调用者可能已加日志级别标记：
type ValidationError struct {
Field string
Value interface{}
}
func (e *ValidationError) Error() string {
return fmt.Sprintf("validation failed on field %q: %v", e.Field, e.Value)
}
- 避免在
Error()里调用fmt.Sprintf做复杂格式化——影响性能，尤其高频错误场景 - 若需结构化字段（如 HTTP 状态码、code 字段），不要塞进
Error()返回值，而是额外提供方法：e.Code()、e.Status() - 实现
Unwrap() error才能参与错误链传递，否则%w包装后会断链
真正难的不是怎么输出错误，而是决定哪些错误该被格式化、哪些该被吞掉、哪些该加 context 再抛出——fmt 只是最后那层薄薄的皮，底下得靠错误分类和传播策略撑住。
