Go语言处理错误的方式与其他主流语言有显著区别。它没有采用try/catch/finally这类异常捕获语法，而是把error当作一个普通的接口类型，由函数通过返回值显式传递。调用方必须立即决定如何处理错误，通常是在if语句中检查err是否为nil。这种设计让错误处理路径变得清晰直接，避免了异常在调用栈中隐式传播带来的不确定性。error接口的定义非常精简，仅包含一个Error() string方法，任何类型只要实现该方法，就可以被当作错误返回。
基础语法：error接口与返回错误检查
Go标准库中的error接口定义如下：
type error interface {
Error() string
}这个接口没有额外的约束，只要类型实现Error() string方法，就能参与错误传递。函数通常把error作为最后一个返回值，当调用成功时返回nil，失败时返回一个非nil的error实例。下面是一个除法函数的例子，它在除数为零时返回错误：
package main
import (
"errors"
"fmt"
)
func divide(a, b int) (int, error) {
if b == 0 {
return 0, errors.New("division by zero")
}
return a / b, nil
}
func main() {
result, err := divide(10, 0)
if err != nil {
fmt.Println("error:", err)
return
}
fmt.Println("result:", result)
}errors.New是创建基础错误的最简单方式，它接收一个字符串并返回error接口值。这个字符串就是Error()方法的返回值，通常要求小写开头、不含标点结尾，以保持错误信息的风格统一。调用方拿到错误后，最常见的处理方式是立即用if err != nil进行判断，然后返回或记录日志。由于Go不支持异常抛出，错误不会打断程序执行流程，开发人员必须逐层向上传递，这就是所谓的显式错误处理模式。
这种模式虽然代码量有所增加，但优点在于错误传播路径完全透明。一个函数是否可能失败，从签名上就能直接看出来；调用者无法忽略返回值，因为Go编译器会对未使用的局部变量报错，而err如果被赋值后不检查，虽然不会编译失败，但合格的代码审查会将其视为问题。对于需要快速失败的脚本或初始化逻辑，可以结合panic来简化流程，不过常规业务代码仍然建议使用error返回。
错误包装与错误链：errors.Is和errors.As
实际项目中，错误往往需要携带更多上下文。一个文件打开失败的错误，如果只返回permission denied，调用方很难知道是哪个路径、哪一步操作导致。fmt.Errorf从Go 1.13开始支持%w动词，可以在创建新错误时包装原始错误，形成错误链。例如：
package main
import (
"errors"
"fmt"
)
var ErrNotFound = errors.New("not found")
func findUser(id int) error {
return fmt.Errorf("find user %d: %w", id, ErrNotFound)
}
func main() {
err := findUser(42)
if errors.Is(err, ErrNotFound) {
fmt.Println("user not found")
}
fmt.Println(err)
}上面的代码中，findUser返回的错误表面信息是find user 42: not found，但它通过%w把底层的ErrNotFound包裹了起来。errors.Is会沿着错误链逐层比较，看是否存在与目标错误相等的节点。这样上层调用者不需要知道错误被包装了多少层，也能准确识别最初的错误原因。需要注意的是，%w只能包装一个错误，并且同一个错误链中最好不要重复包装相同的底层错误，否则errors.Is的行为会变得复杂。
当需要从错误链中提取某个具体类型的错误实例时，可以使用errors.As。比如HTTP请求失败时，错误可能被多层包装成HTTPError类型，调用方想获取状态码，就可以把errors.As的目标指向一个HTTPError变量。如果匹配成功，As会返回true并把目标变量设置为链中第一个匹配的错误。与类型断言不同，As能够穿透包装层级，非常适合处理自定义错误类型。
此外，fmt.Errorf还可以使用%v来格式化错误信息而不进行包装。这样表面上信息看起来一样，但errors.Is和errors.As无法穿透。因此在需要保留原始错误以便上层判断时，必须使用%w，否则会切断错误链。很多错误处理失败的问题都源于误用%v，导致上层无法用errors.Is匹配到根因。
panic与recover：处理不可恢复错误
Go语言中的panic与recover看起来类似其他语言的异常，但设计目标完全不同。panic用于报告程序无法继续执行的严重错误，例如数组越界、空指针引用、除数为零的整数除法。当panic发生时，Go会立即停止当前函数的正常执行，转而运行该函数的所有延迟调用defer，然后向调用栈上层传播，直到程序退出或遇到recover。
recover只能在defer函数中直接调用才有效。下面是一个典型的panic恢复模式：
package main
import "fmt"
func safeCall() {
defer func() {
if r := recover(); r != nil {
fmt.Println("recovered from panic:", r)
}
}()
panic("something went wrong")
}
func main() {
safeCall()
fmt.Println("program continues")
}在上面的代码里，safeCall函数中的panic会触发defer中的匿名函数执行，recover捕获了panic值，程序得以继续执行main函数中的最后一行。如果不做recover，程序会在打印panic信息后崩溃退出。recover返回的值是interface{}，可以是字符串、error或其他任何类型，通常需要结合类型断言来判断panic的来源。
需要特别强调的是，panic和recover不应该被用来做普通的控制流处理。把本应通过error返回的业务失败改成panic，会让调用方无法优雅降级，只能靠recover兜底，代码可读性和性能都会变差。它们更适合在库的边界处使用，例如HTTP框架内部对单个请求的handler做recover，避免某个请求的panic导致整个服务进程退出。同时，在recover之后，错误日志中应该记录完整的堆栈信息，便于定位根因。
自定义错误类型与最佳实践
标准库提供的errors.New只能携带静态字符串，无法存储错误码、HTTP状态码、字段信息等结构化数据。对于需要被上层程序识别并做出不同处理的错误，应该自定义错误类型。实现方式仍然很简单：定义一个结构体，添加Error() string方法即可。例如：
package main
import (
"errors"
"fmt"
)
type HTTPError struct {
StatusCode int
Message string
}
func (e *HTTPError) Error() string {
return fmt.Sprintf("HTTP %d: %s", e.StatusCode, e.Message)
}
func request(url string) error {
return &HTTPError{StatusCode: 404, Message: "resource not found"}
}
func main() {
err := request("/api/user")
var httpErr *HTTPError
if errors.As(err, &httpErr) {
fmt.Println("status code:", httpErr.StatusCode)
}
fmt.Println(err)
}在request函数中，返回的是*HTTPError指针，这允许调用方通过errors.As把error接口还原为具体类型，然后访问StatusCode字段。如果返回的是值类型而非指针，As的目标类型需要相应调整，同时要小心值拷贝可能带来的问题。自定义错误类型通常建议实现为指针接收者，以便在错误链中保留同一个实例。
编写Go错误处理代码时，有几条值得遵循的实践原则。第一，错误信息应该描述发生了什么以及为什么失败，而不是提示调用者该做什么，因为上层可能有不同的处理策略。第二，单个错误在向上传递时只需包装一次上下文，避免重复添加相同前缀。第三，不要忽略错误，即使认为某个操作不可能失败，也应该返回错误或记录日志，否则后续排查问题会非常困难。第四，对于公开库的错误，应该导出哨兵错误变量，让使用方能够用errors.Is进行判断，而不是依赖字符串比较。
总结来看，Go的错误处理语法由error接口、多返回值、fmt.Errorf包装、errors.Is与errors.As判断以及panic/recover兜底几个部分组成。它强调显式、简单和可组合性，虽然会让代码中出现大量if err != nil，但换来的是错误路径的完全可控。与异常机制相比，Go的方式在大型并发系统中更容易推理错误来源，也避免了异常抛出带来的栈展开开销。