Go语言错误处理强调显式处理，通过定义哨兵错误、自定义错误类型和统一错误码提升可维护性，使用%w包装错误传递上下文，避免滥用panic，仅在不可恢复场景使用，recover用于API入口兜底。
Go语言的错误处理不是异常流程，而是程序逻辑的核心部分。它的设计哲学是让开发者显式地面对每一个可能出错的地方，而不是用try-catch隐藏起来。要优雅地处理error，关键在于提供清晰的上下文、建立统一的规范，并正确区分可恢复与不可恢复的错误。基本上就这些。
定义明确的错误类型与统一错误码
使用字符串错误（如errors.New("something failed")）虽然简单，但在大型项目中难以判断和处理。为了精确识别错误并返回给前端一致的信息，应该定义结构化的错误类型或使用统一的错误码。
-
预定义哨兵错误：对于特定、常见的错误条件，定义全局的错误变量，便于调用方精准判断。
var ErrNotFound = errors.New("resource not found")
后续可以用errors.Is(err, ErrNotFound)来检查，比字符串比较更安全可靠。 -
自定义错误类型：当需要携带额外信息（如错误码、状态码）时，创建一个实现了Error()方法的struct。
type AppError struct { Code int Message string } func (e *AppError) Error() string { return fmt.Sprintf("[%d] %s", e.Code, e.Message) } - 统一错误码管理：在项目中预先定义好各业务模块的错误码范围，避免混乱。例如，1000-1999为用户模块错误，2000-2999为订单模块错误。这样前后端对接时能快速定位问题，也方便日志监控和告警。
使用错误包装（Wrapping）传递上下文
在多层函数调用中，如果只返回原始错误，顶层很难知道错误发生在哪个环节。Go 1.13+引入的错误包装机制可以解决这个问题，它像堆栈一样记录错误的传播路径。
- 使用fmt.Errorf配合%w动词来包装错误。
例如，在B函数中调用C函数失败：
if err != nil { return fmt.Errorf("failed in B: %w", err) } - 这样做之后，最终的错误信息会包含完整的调用链，比如"failed in A: failed in B: resource not found"，极大地方便了调试和日志分析。
- 需要时，可以使用errors.Unwrap、errors.Is或errors.As来解包错误，检查底层是否包含某个特定类型的错误或哨兵错误，实现针对性的处理逻辑。
谨慎使用panic和recover
panic在Go中被视为“意外的、不可恢复的”程序崩溃，比如数组越界、空指针解引用。在正常的业务逻辑中，应该通过返回error来处理所有可预见的问题，而不是滥用panic。
立即学习“go语言免费学习笔记（深入）”；
-
panic的适用场景：通常只用于程序启动阶段，例如配置文件解析失败、关键服务无法初始化等，此时程序本就无法正常运行。
if err := loadConfig(); err != nil { panic(err) } -
recover的兜底作用：在暴露给外部的API入口（如HTTP handler）或独立的goroutine中，可以使用defer + recover来捕获意外的panic，防止整个程序退出，并返回一个通用的服务器错误响应。
defer func() { if r := recover(); r != nil { log.Printf("Panic recovered: %v", r) http.Error(w, "Internal Server Error", 500) } }() - 禁止在业务逻辑中主动panic：像数据库查询失败、网络请求超时这类情况都是可预见的，必须通过error返回，由上层决定重试、降级还是提示用户，而不是让程序直接崩溃。
