错误处理
需要预先了解：
1. 错误处理
Go 把"可预期的失败"当作普通的返回值处理，而不是语言级的异常机制。这套设计的核心是 error 接口加 if err != nil 惯例。与之相对，panic 只用于"程序不该继续运行"的情况。这一篇把 error 的包装与解包、defer 的完整机制、panic/recover 的边界都讲清楚。
1.1 error 接口
error 是标准库里的一个接口，只有一个方法：
type error interface {
Error() string
}创建错误有两种常用方式：
err1 := errors.New("资源不存在")
err2 := fmt.Errorf("打开文件 %s 失败", "a.txt")errors.New 返回一个固定文本的错误；fmt.Errorf 可以格式化文本。两者都满足 error 接口。
if err != nil 惯例
Go 的错误处理惯例是"检查并提前返回"，而不是层层嵌套：
func find(id int) (string, error) {
if id != 1 {
return "", ErrNotFound
}
return "一撮灰", nil
}v, err := find(2)
if err != nil {
fmt.Println("查找失败:", err)
return
}
fmt.Println("找到:", v)把错误放在最后一个返回值，是 Go 的约定。调用方拿到错误后立刻判断、立刻返回，正常的代码路径保持在最左侧，不需要缩进。
注意：错误信息不要大写开头、不要以标点结尾（
errors.New("资源不存在")而不是errors.New("资源不存在。")），因为错误经常被拼接到更长的句子里。
1.2 自定义错误类型
需要携带上下文信息时，定义一个实现了 Error() 的结构体：
type PathError struct {
Path string
Err error
}
func (e *PathError) Error() string {
return e.Path + ": " + e.Err.Error()
}err := &PathError{Path: "/etc/app.yaml", Err: ErrNotFound}
fmt.Println(err) // /etc/app.yaml: 资源不存在命名建议以 Error 结尾，字段里保存原始错误和上下文数据。
1.3 错误包装（Go 1.13+）
包装的动机是：底层返回"资源不存在"，上层需要补充"在加载配置时出错"，但又不希望调用方失去判断底层错误的能力。
用 %w 包装：
func loadConfig() error {
return fmt.Errorf("加载配置失败: %w", &PathError{Path: "/etc/app.yaml", Err: ErrNotFound})
}%w 与 %v 的区别是：%w 会把被包装的错误记录下来，形成一个链条。
err := loadConfig()
fmt.Println("包装后的错误:", err) // 加载配置失败: /etc/app.yaml: 资源不存在errors.Is
errors.Is(err, target) 沿着包装链查找是否有等于 target 的错误：
fmt.Println("errors.Is(err, ErrNotFound):", errors.Is(err, ErrNotFound)) // true判断错误时不要用 ==，因为它只能比较最外层。errors.Is 会逐层 Unwrap 直到找到匹配。
errors.As
errors.As 用来把包装链中的某个具体错误类型提取出来：
var pe *PathError
if errors.As(err, &pe) {
fmt.Println("提取到 PathError, Path =", pe.Path) // /etc/app.yaml
}第二个参数必须是指向错误类型的指针，这样 errors.As 才能把值写进去。
errors.Unwrap
手动逐层拆开：
fmt.Println("第一层 Unwrap:", errors.Unwrap(err)) // /etc/app.yaml: 资源不存在
fmt.Println("第二层 Unwrap:", errors.Unwrap(errors.Unwrap(err))) // 资源不存在一个类型只要实现了 Unwrap() error，就能参与这条链：
func (e *PathError) Unwrap() error {
return e.Err
}errors.Join（Go 1.20+）
需要同时报告多个错误时：
joined := errors.Join(err1, err2)
fmt.Println(joined)第一个错误
第二个错误errors.Is 对 Join 出来的结果同样有效，任意一个匹配就返回 true。
1.4 defer 的完整机制
defer 的基本规则（LIFO、参数立即求值）在 函数 里讲过，这里补齐与错误处理相关的部分。
修改命名返回值
defer 在 return 赋值之后、函数真正返回之前执行，所以可以修改命名返回值：
func namedReturn() (result int, err error) {
defer func() {
if r := recover(); r != nil {
err = fmt.Errorf("捕获到 panic: %v", r)
result = -1
}
}()
panic("出问题了")
}fmt.Println(namedReturn()) // -1 捕获到 panic: 出问题了执行顺序是：panic → 运行 defer → recover 拦下 panic → defer 修改 err 和 result → 函数正常返回这两个值。
多个 defer 与 recover 的顺序
defer 按 LIFO 执行，recover 只对当前正在传播的 panic 生效。如果多个 defer 中都有 recover，只有最先执行的那个（也就是最后注册的）能拿到 panic 值：
defer func() { fmt.Println("第一个注册, 最后执行:", recover()) }()
defer func() { fmt.Println("第二个注册, 先执行:", recover()) }()
panic("boom")输出中先执行的那个会打印 boom，后执行的拿到 nil（因为 panic 已经被处理）。
defer 里的闭包引用
defer func() { ... }() 捕获的是变量本身，因此看到的是函数返回前的最终值；defer f(x) 的参数在注册时就求值。想同时拿到"当前值"和"最终值"时，利用这个差异：
func f() {
x := 1
defer fmt.Println("注册时的 x:", x) // 1
defer func() { fmt.Println("返回时的 x:", x) }() // 100
x = 100
}1.5 panic 与 recover
panic 中断当前函数的正常执行，开始逐层运行 defer，直到某个 defer 调用 recover 拦下它，或者整个程序崩溃。
func safeDiv(a, b int) (result int, err error) {
defer func() {
if r := recover(); r != nil {
err = fmt.Errorf("除法出错: %v", r)
}
}()
return a / b, nil
}r, err := safeDiv(10, 2)
fmt.Println(r, err) // 5 <nil>
r, err = safeDiv(10, 0)
fmt.Println(r, err) // 0 除法出错: runtime error: integer divide by zerorecover 的两个限制
1. 必须在 defer 的函数里直接调用。 把 recover 包一层再调用就拿不到 panic 值：
defer func() {
recover() // 这样写没有效果，返回值被丢弃
}()2. 只能捕获同一个 goroutine 的 panic。 主 goroutine 的 recover 无法拦住子 goroutine 里的 panic：
defer func() {
if r := recover(); r != nil {
fmt.Println("主 goroutine 的 recover:", r)
}
}()
go func() {
panic("子 goroutine 里的 panic")
}()
time.Sleep(200 * time.Millisecond)panic: 子 goroutine 里的 panic
goroutine 7 [running]:
main.main.func2()
.../main.go:16 +0x25整个进程直接退出。所以每个 goroutine 需要自己处理自己的 panic，通常在最外层包一个 defer + recover。
常见 panic 场景
try("数组越界", func() { a := [3]int{}; i := 5; _ = a[i] })
try("nil 指针解引用", func() { var p *int; _ = *p })
try("整数除零", func() { a, b := 1, 0; _ = a / b })
try("关闭已关闭 channel", func() { ch := make(chan int); close(ch); close(ch) })
try("向已关闭 channel 发送", func() { ch := make(chan int, 1); close(ch); ch <- 1 })
try("类型断言失败", func() { var i any = 1; _ = i.(string) })
try("切片越界写", func() { s := make([]int, 1); i := 5; s[i] = 1 })数组越界 -> panic: runtime error: index out of range [5] with length 3
nil 指针解引用 -> panic: runtime error: invalid memory address or nil pointer dereference
整数除零 -> panic: runtime error: integer divide by zero
关闭已关闭 channel -> panic: close of closed channel
向已关闭 channel 发送 -> panic: send on closed channel
类型断言失败 -> panic: interface conversion: interface {} is int, not string
切片越界写 -> panic: runtime error: index out of range [5] with length 1汇总成表：
| 场景 | panic 值 | 能否 recover |
|---|---|---|
| 数组/切片越界 | runtime error: index out of range |
可以 |
| nil 指针解引用 | runtime error: invalid memory address or nil pointer dereference |
可以 |
| 整数除零 | runtime error: integer divide by zero |
可以 |
| 关闭已关闭的 channel | close of closed channel |
可以 |
| 向已关闭的 channel 发送 | send on closed channel |
可以 |
| 类型断言失败 | interface conversion: ... |
可以 |
| nil map 写入 | assignment to entry in nil map |
可以 |
| 并发读写 map | fatal error: concurrent map writes |
不可以 |
| 栈溢出 | fatal error: stack overflow |
不可以 |
fatal error 是运行时直接终止进程的错误，recover 拦不住。
1.6 选型原则
| 情况 | 选择 |
|---|---|
| 可预期的失败（文件不存在、参数非法、网络超时） | error |
| 程序性 bug（不可能出现却出现了的状态） | panic |
| 库函数遇到调用方违反前置条件 | 可以 panic，并在文档里写清楚 |
| 主程序处理请求 | 最外层 recover 兜底，转成 500 响应并记录日志 |
库代码应尽量返回 error，把"要不要崩"的决定权交给调用方。只有在"继续运行下去状态已经不可信"时才用 panic。
re-panic
有时需要在 recover 后补充上下文再抛出去：
defer func() {
if r := recover(); r != nil {
// 记录日志或补充信息
panic(fmt.Errorf("处理请求时崩溃: %v", r))
}
}()这样既留下了原始信息，又让上层的 recover 能识别出这是被包装过的 panic。注意包装后的 panic 值不再是原来的类型，上层如果依赖具体类型需要保留原始值。
1.7 练习
- 定义
ErrPermission和ErrTimeout两个哨兵错误，写一个函数随机返回其中一个，用errors.Is分别判断。 - 定义一个携带错误码的自定义错误类型，用
errors.As从中取出错误码。 - 写一个
safeGo(f func())函数，用defer + recover包裹传给它的函数，并在子 goroutine 中调用，验证它确实能拦住子 goroutine 的 panic。
相关推荐
2026-09-09
调度器：GMP 模型深入
需要预先了解： goroutine 与并发初探 channel 调度器：GMP 模型深入 goroutine 与并发初探 里给出了 GMP 的概览。这一篇展开内部结构：G 里存了什么、调度器怎么选下一个 G、work stealing 和 hand-off 如何工作、抢占是怎么实现的，以及为什么网络 IO 不会占住线程。 G、M、P 的职责 G G G G G = goroutine（任务：栈 + 状态 + 调度信息） | | | | v v v v +---------------+ P = 逻辑处理器（本地队列 + 资源配额） | P runq | +---------------+ | v +---------------+ M = 内核线程（真正执行指令） | M | +---------------+ 结构 内容 G 栈指...
2026-09-09
标准库（二）：JSON 与 HTTP 服务
需要预先了解： 结构体与指针 标准库（一）：IO 与系统交互 context 标准库（二）：JSON 与 HTTP 服务 encoding/json 和 net/http 是写服务端程序的两块基石。这一篇从"结构体怎么变成 JSON"讲到"一个带中间件、超时和优雅关闭的迷你 REST 服务"，把 反射与 unsafe 里看到的 tag 机制落到实际用法上。 encoding/json 基础 两个函数覆盖 90% 的场景： b, err := json.Marshal(v) // 值 -> JSON 字节切片 err = json.Unmarshal(data, &v) // JSON -> 值（必须传指针） u := User{Name: "一撮灰", Score: 98.5, Created: time.Date(2026, 9, 9, 12, 0, 0, 0, time.UTC)} b, _ := json.Marshal(u) fmt.Println...
2026-09-09
context
需要预先了解： channel sync 包与原子操作 context 一个请求往往要派生多个 goroutine：查数据库、调下游服务、写日志。如果其中一步超时或客户端断开，其他步骤需要尽快停下。context 就是用来统一传递取消信号、截止时间和请求范围内的元数据的标准机制。 需求引入 假设一个函数要并发做三件事，任何一件失败或超时就整体放弃。如果每个 goroutine 各自用 done channel，代码会变成一堆手写的通知逻辑： done1 := make(chan struct{}) done2 := make(chan struct{}) // 谁来关闭？超时怎么办？取消要不要级联？ context 把这些问题标准化：它是一棵可级联取消的树，父节点取消时所有子节点都会收到通知。 Context 接口 type Context interface { Deadline() (deadline time.Time, ok bool) Done() <-chan struct{...
2026-09-09
channel
需要预先了解： goroutine 与并发初探 channel channel 是 goroutine 之间传递数据的管道，也是 Go 并发模型的核心。它同时承担两件事：传递数据和同步。这一篇讲清楚无缓冲与有缓冲的差别、close 的规则、select 的多路复用，以及几个会让程序直接崩溃的操作。 设计哲学 Go 的并发信条是： 不要通过共享内存来通信，而要通过通信来共享内存。 意思是：与其让多个 goroutine 抢着读写同一块内存（然后用锁保护），不如让数据在 goroutine 之间传过来，同一时刻只有一方持有它。channel 就是传递的载体。 无缓冲 channel：同步语义 make(chan T) 创建的是无缓冲 channel。它的发送和接收必须同时就位才能完成——发送方会一直阻塞，直到有接收方来取： ch := make(chan int) go func() { fmt.Println("发送前") ch <- 1 fmt.Println("发送完成") }() time.Sleep(100 * ti...
2026-09-09
接口与 channel 的底层实现
需要预先了解： 接口 channel 内存分配与逃逸分析 接口与 channel 的底层实现 接口 里留下的 nil 陷阱、channel 里"收发是拷贝"的结论，都可以从运行时结构上得到解释。这一篇看 eface/iface/itab 和 hchan 的真实字段，以及一次发送、一次接收、一次关闭在底层分别发生了什么。 eface 与 iface 空接口和非空接口在运行时是两种结构： type eface struct { // 空接口 any / interface{} _type *_type // 动态类型 data unsafe.Pointer // 指向动态值的指针 } type iface struct { // 带方法的接口 tab *itab // 类型 + 方法表 data unsafe.Pointer // 指向动态值的指针 } 两者都是两个指针宽，在 64 位平台上是 16...
2026-09-09
方法
需要预先了解： 结构体与指针 方法 **方法（method）**是带接收者的函数。接收者写在 func 和函数名之间，把方法和某个类型绑定起来。方法看起来只是多了一个参数，但"值接收者还是指针接收者"这个选择会直接影响方法能否修改对象，以及该类型能否满足某个接口。 定义 type Counter struct { n int } func (c Counter) Get() int { return c.n } (c Counter) 就是接收者。调用时用点号： c := Counter{n: 5} fmt.Println(c.Get()) // 5 方法名不能与字段名冲突。 值接收者 vs 指针接收者 值接收者拿到的是调用者的副本，修改副本不影响原对象；指针接收者拿到的是地址，可以修改原对象： func (c Counter) IncrVal() { c.n++ } // 改副本 func (c *Counter) IncrPtr() { c....
