Go语言中通过error和panic/recover处理异常，error用于可预期错误，如文件不存在；panic用于不可恢复的严重错误。函数应优先返回error值，调用者通过判断error是否为nil处理错误。使用fmt.Errorf搭配%w可实现错误链包装，便于用errors.Is和errors.As追溯和判断错误类型。自定义错误类型可携带更多上下文信息，如UserNotFoundError包含UserID和Reason，支持细粒度错误处理。panic仅应用于程序无法继续的场景，如初始化失败、配置严重错误或断言失败，不应在库函数中随意使用，以免中断调用流程。正确区分二者是编写健壮Go程序的关键。
在Go语言中，处理程序中的异常情况主要通过两种机制：
error类型和
panic/recover。
error用于表示可预期的、程序可以处理并从中恢复的错误，例如文件找不到、网络请求超时等。而
panic则用于表示程序遇到了无法继续执行的严重、非预期错误，通常是编程逻辑上的缺陷或系统级崩溃，它会中断当前执行流程并向上层调用栈传播，直到被
recover捕获或导致程序崩溃。正确区分并使用它们，是编写健壮Go程序的关键。
Go语言的设计哲学鼓励显式错误处理，而非通过异常捕获来隐藏问题。因此，绝大多数情况下，我们都应该优先使用
error来传递和处理错误信息。
使用error
的场景与实践：
-
函数返回
error
: 当一个函数在正常执行路径中可能遇到问题时，它应该返回一个error
类型的值作为其最后一个返回值。调用者通过检查这个error
是否为nil
来判断操作是否成功。立即学习“go语言免费学习笔记（深入）”；
package main import ( "errors" "fmt" "os" ) func ReadFile(path string) ([]byte, error) { data, err := os.ReadFile(path) if err != nil { // 可以封装更具体的错误信息，使用%w进行错误链包装 return nil, fmt.Errorf("读取文件 %s 失败: %w", path, err) } return data, nil } func main() { // 调用示例 data, err := ReadFile("non_existent.txt") if err != nil { fmt.Println("处理错误:", err) // 这会打印完整的错误链 // 根据错误类型做不同处理 var pathErr *os.PathError if errors.As(err, &pathErr) { fmt.Printf("检测到文件路径错误：文件 %s 不存在或无法访问。\n", pathErr.Path) } else { fmt.Println("这是一个我们没有特定处理逻辑的错误类型。") } return } fmt.Println("文件内容:", string(data)) } 错误链（Error Wrapping）: 使用
fmt.Errorf
的%w
动词可以包装底层错误，保留原始错误信息，方便上层调用者通过errors.Is
和errors.As
进行错误类型判断。这对于构建可追溯的错误路径至关重要，它能帮助你在复杂调用栈中精准定位问题根源。-
自定义错误类型: 对于特定业务逻辑的错误，可以定义自定义错误类型，使其包含更多上下文信息，并允许调用者进行更细粒度的错误判断。
package main import ( "errors" "fmt" ) type UserNotFoundError struct { UserID string Reason string } func (e *UserNotFoundError) Error() string { return fmt.Sprintf("用户 %s 未找到: %s", e.UserID, e.Reason) } func GetUser(id string) (*string, error) { if id == "unknown" { return nil, &UserNotFoundError{UserID: id, Reason: "用户ID在数据库中不存在"} } userName := "Test User " + id return &userName, nil } func main() { // 调用 user, err := GetUser("unknown") if err != nil { var notFoundErr *UserNotFoundError if errors.As(err, ¬FoundErr) { fmt.Printf("处理用户未找到错误：ID为 %s 的用户缺失，具体原因：%s\n", notFoundErr.UserID, notFoundErr.Reason) } else { fmt.Println("其他类型的错误发生:", err) } return } fmt.Println("获取到用户:", *user) }
使用panic/recover
的场景与实践：
panic应该保留给那些程序无法继续执行的“异常”情况，通常是：
- 不可恢复的编程错误: 例如，数组越界访问、空指针解引用（在某些特定情况下，Go运行时会自动panic），或者在程序启动时发现配置严重错误导致无法运行。这些往往意味着程序逻辑存在根本性缺陷。
-
初始化失败: 如果一个包或模块在初始化时就发现自己处于无法工作的状态，可以
panic
。这通常意味着程序设计或部署存在根本性问题，继续运行下去只会导致更多不可预测的行为。 -
断言失败: 在开发或测试阶段，可以用
panic
来断言某些不应该发生的情况。这有助于在早期发现并修复bug。
panic
的正确使用姿势：
-
避免在库函数中
panic
: 库函数应该返回error
，让调用者决定如何处理。在库中panic
会强制中断调用者的流程，这通常是不友好的，并且难以被外部代码预料和处理。
