08-函数

第8章函数

引言：函数是 Go 程序的基本构造块，本章从调用约定、参数语义到 defer/panic/recover 三件套，深入讲解函数在 Runtime 层的实现与工程实践要点。

参数传递

(1) 是什么

Go 中所有参数传递都是“值传递”——函数接收到的总是实参的一份拷贝，不存在引用传递。看起来像引用传递的 slice/map/channel，本质是它们的“描述符（descriptor）”被复制了一份，而描述符内部仍指向同一份底层数据。

(2) 为什么这样设计 / 底层实现

值传递让函数内部对参数的修改不会“溢出”到调用方，符合 Go “显式优于隐式”的哲学。
调用约定 (Calling Convention)：Go 1.17 起从基于栈的调用约定切换到基于寄存器的调用约定 (internal/abi)，参数优先放入寄存器（amd64 上是 RAX/RBX/RCX/RDI/RSI/R8/R9/R10/R11），溢出部分压栈；返回值同样优先用寄存器。这一改动让常见函数调用开销下降约 20%~30%。
不同类型在传参时的语义差异：

类型	传递内容	是否共享底层数据
int / float / bool	值拷贝	否
string	`{ptr, len}` 拷贝	字符串只读，共享底层字节数组（不可变，无副作用）
slice	`{ptr, len, cap}` 拷贝	是，共享底层数组
map	指向 `runtime.hmap` 的指针拷贝	是
channel	指向 `runtime.hchan` 的指针拷贝	是
interface	`{itab, data}` 拷贝	`data` 指针指向同一份数据
struct	整体按字段拷贝	取决于字段类型
pointer	指针值拷贝	是

slice 描述符的简化定义（runtime/slice.go）：

1
2
3
4
5
type slice struct {
    array unsafe.Pointer // 指向底层数组
    len   int
    cap   int
}

调用 func f(s []int) 时，s 的这三个字段被复制到 f 的栈帧/寄存器中；但因为 array 字段指向同一块底层数组，所以 s[0] = 99 这种通过下标写操作会影响外部调用方。

(3) 工程实践与常见坑

大 struct 拷贝开销：超过约 64 字节的 struct 传值会触发整体拷贝，热路径上应传指针。
在 for-range 中传 slice 元素时容易踩坑：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
package main

import "fmt"

type Big struct {
    data [1024]byte
}

func touch(b Big) { b.data[0] = 1 }

func main() {
    bs := make([]Big, 10)
    for i := range bs {
        touch(bs[i]) // 每次拷贝 1KB
    }
    fmt.Println(len(bs))
}

应改为 touch(&bs[i])，避免每次循环拷贝 1KB。

map/slice 看起来“自动同步”，容易让人误以为是引用传递，需要理解其描述符本质。
修改 slice 头部（len/cap）不会反映到外部：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
package main

import "fmt"

func grow(s []int) {
    s = append(s, 1) // 可能触发扩容，新底层数组
    fmt.Println("in grow:", len(s))
}

func main() {
    s := make([]int, 0, 1)
    grow(s)
    fmt.Println("in main:", len(s)) // 仍是 0
}

提示：要让函数“修改” slice 的 len/cap，必须返回新 slice 或传 *[]int。Go 标准库 append 之所以返回 slice，正是这个原因。

返回值

(1) 是什么

Go 函数可以返回一个或多个值。返回值分为“命名返回值”和“非命名返回值”。命名返回值在函数进入时被零值初始化，函数体内可对其赋值，return 时把当前值返回给调用方。

(2) 为什么这样设计 / 底层实现

返回值在函数栈帧中预留固定空间（基于寄存器约定时则是预定的寄存器槽）。
命名返回值的“零值初始化”在函数 prologue 阶段完成，因此即便中途 panic，命名返回值仍保留已赋值的状态——这正是 defer 能在 recover 前修改命名返回值的原因。
裸 return (naked return) 是命名返回值的语法糖：return 等价于 return <所有命名返回值>。

函数栈帧的简化模型：

1
2
3
4
5
6
7
type Frame struct {
    args   []byte   // 入参区域（寄存器约定下溢出参数存放于此）
    locals []byte   // 局部变量
    ret    []byte   // 返回值区域
    PC     uintptr  // 返回地址
    SP     uintptr  // 调用方栈指针
}

(3) 工程实践与常见坑

命名返回值 + 裸 return 在长函数中可读性差，建议只在短函数中使用裸 return。
误用命名返回值导致返回零值的经典 bug：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
package main

import "fmt"

func bad() (result int) {
    if true {
        return // 期望返回 1，实际返回 0
    }
    result = 1
    return
}

func main() {
    fmt.Println(bad()) // 0
}

命名返回值可与 defer 配合修改最终返回值：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
package main

import "fmt"

func f() (x int) {
    defer func() { x++ }()
    return 10 // x = 10，defer 修改为 11
}

func main() {
    fmt.Println(f()) // 11
}

注意：defer 修改非命名返回值无效，因为非命名返回值没有“具名存储位置”，return 时直接写到调用方栈帧，defer 无法定位并修改它。

多返回值

(1) 是什么

Go 原生支持多返回值，最常见的惯用法是 (value, error)。

(2) 为什么这样设计 / 底层实现

多返回值避免了 C 时代用 out 参数或全局 errno 的丑陋写法，让错误处理成为函数签名的一部分。
调用约定层面：返回值按声明顺序占用寄存器/栈位，与单返回值无本质区别；多返回值是 ABI 层面的“约定”而非“特殊机制”。
内置操作的 comma-ok 惯用法：
- 类型断言：v, ok := i.(T)
- map 查询：v, ok := m[k]
- channel 接收：v, ok := <-ch
- 类型 switch 不算多返回值，但语义相通。

(3) 工程实践与常见坑

error 一定要检查，不要 _ = foo()。可用 errcheck 工具排查漏检。
多返回值不能作为整体参与表达式，必须分开接收：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
package main

import "fmt"

func two() (int, int) { return 1, 2 }

func main() {
    // fmt.Println(two()) // 编译错误：multiple-value two() used in single-value context
    a, b := two()
    fmt.Println(a, b)
}

comma-ok 与零值：当 ok 为 false 时，第一个返回值是类型的零值，初学者易误用：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
package main

import "fmt"

func main() {
    m := map[string]int{"a": 1}
    v := m["b"] // 直接取，缺失时返回零值 0，无法区分"真的存了 0"和"不存在"
    fmt.Println(v)
    v2, ok := m["b"] // 正确做法
    fmt.Println(v2, ok)
}

defer

(1) 是什么

defer 语句用于注册一个在函数返回时执行的延迟调用，遵循 LIFO（后进先出）顺序。常用于资源释放、锁释放、panic 兜底等收尾工作。

(2) 为什么这样设计 / 底层数据结构与 Runtime 实现要点

设计目标：把“打开资源”和“释放资源”在代码上就近放置，避免遗忘释放。
Go 1.21 中 _defer 结构（runtime/runtime2.go，简化）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
type _defer struct {
    started   bool           // 是否已开始执行
    heap      bool           // 是否堆分配
    openDefer bool           // 是否开放编码式 defer
    sp        uintptr        // 注册 defer 时的栈指针
    pc        uintptr        // 注册 defer 时的程序计数器
    fn        func()         // 延迟函数
    _panic    *_panic        // 当前关联的 panic
    fd        unsafe.Pointer // 开放编码用
    varp      uintptr        // 保存的变量基址
    framepc   uintptr
    link      *_defer        // 链表 next 指针
}

逐字段解释：

started：防止 defer 在执行过程中被重复触发。
heap：标记该 _defer 是否在堆上分配。Go 1.13 起引入 defer 池复用堆上 _defer，降低 GC 压力。
openDefer：Go 1.14 引入的“开放编码式 defer”（open-coded defer）。对于不超过 8 个 defer 且无循环、无递归的函数，编译期直接内联生成“位图 + 跳转表”，不再分配 _defer 结构，开销近乎为零。
sp / pc：用于在函数返回时校验栈帧，确保 defer 在正确的函数上下文执行。
fn：实际要执行的延迟函数（已绑定闭包变量）。
_panic：当前关联的 panic，用于 panic/recover 交互。
link：函数内的 defer 通过链表组织，goroutine 的 _defer 字段指向链表头，新 defer 头插。

三种 defer 实现路径（按性能从高到低）：

路径	引入版本	触发条件	开销
开放编码 (open-coded)	1.14	函数 defer 数 ≤ 8，无循环/递归	接近 0
栈分配	1.13	不满足开放编码，但参数较简单	小，无需 GC
堆分配	早期	兜底	较大，需 GC

(3) 工程实践与常见坑

defer 参数在 defer 语句执行时求值，不是在真正调用时：

1
2
3
4
5
6
7
8
9
package main

import "fmt"

func main() {
    i := 1
    defer fmt.Println(i) // 输出 1，而非 2
    i = 2
}

defer 闭包捕获变量按引用：

1
2
3
4
5
6
7
8
9
package main

import "fmt"

func main() {
    i := 1
    defer func() { fmt.Println(i) }() // 输出 2
    i = 2
}

defer 在循环中累积注册，可能造成资源迟迟不释放：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
package main

import "os"

func main() {
    paths := []string{"a", "b", "c"}
    // 反例：所有 f 直到 main 返回才关闭
    for _, path := range paths {
        f, _ := os.Open(path)
        defer f.Close()
        _ = f
    }
}

应重构为独立函数：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
package main

import "os"

func processFile(path string) {
    f, err := os.Open(path)
    if err != nil {
        return
    }
    defer f.Close() // 在函数返回时立即释放
    _ = f
}

func main() {
    paths := []string{"a", "b", "c"}
    for _, path := range paths {
        processFile(path)
    }
}

defer 会修改命名返回值，但无法修改非命名返回值（见“返回值”小节）。
在 hot path 中若 defer 开销不可忽略（如每秒百万级调用），可手动调用释放而非 defer；但绝大多数业务代码无需关心。
即便 deferred 函数 panic，剩余 defer 仍会执行——defer 链不会被一个 panic 中断。

panic

(1) 是什么

panic 是 Go 中表示“不可恢复错误”的运行时机制。一旦 panic 触发，当前函数立即停止执行，沿调用栈依次执行各函数的 defer，最终进程崩溃（除非被 recover）。

(2) 为什么这样设计 / 底层数据结构与 Runtime 实现要点

设计哲学：error 用于可预期的错误，panic 用于“程序出 bug”或“不变量被破坏”。库代码不应主动 panic 给调用方；调用方代码 panic 通常表示编程错误。
_panic 结构（runtime/runtime2.go，简化）：

1
2
3
4
5
6
7
8
9
type _panic struct {
    argp      unsafe.Pointer // defer 的参数指针，用于 recover 校验
    arg       any            // panic 的参数
    link      *_panic        // 链表 next（panic 中再 panic）
    pc        uintptr        // recover 后恢复执行的 PC
    sp        unsafe.Pointer // recover 后恢复执行的 SP
    recovered bool           // 是否被 recover
    goexit    bool           // 是否由 runtime.Goexit 触发
}

逐字段解释：

argp：指向当前 defer 调用栈上参数的位置；runtime.gorecover 据此判断 recover 是否合法。
arg：panic(v) 中的 v，被 recover() 返回。
link：多个 panic 可链式存在（panic 中又 panic），goroutine 的 _panic 指向链表头。
pc / sp：recover 后从哪里继续执行。
recovered：runtime.gorecover 把它置为 true，后续 defer 处理逻辑据此退出 panic 流程。
goexit：标记是 runtime.Goexit 触发的“伪 panic”，不应被 recover。

panic 执行流程（简化）：

panic(v) 调用 runtime.gopanic(v)。
分配 _panic，链入 goroutine 的 _panic 链表头。
遍历 goroutine 的 _defer 链表，逐个执行：
- 在执行 deferred 函数前，把 _defer._panic 指向当前 _panic。
- 执行 deferred 函数；若函数内调用 recover()，gorecover 检查 _panic 是否是链表头，若是则置 recovered = true。
- deferred 函数返回后，检查 recovered：若 true，移除当前 _panic，恢复到调用方继续执行。
若 defer 链表走完仍未 recover，调用 runtime.fatalpanic 打印堆栈并 exit(2)。

(3) 工程实践与常见坑

不要用 panic 做正常的错误处理。库代码 panic 后用户难以 recover，应返回 error。
常见自动 panic 场景：除零、slice 越界访问、nil 指针解引用、关闭已关闭的 channel、向已关闭 channel 写、类型断言失败（非 comma-ok 形式）、goroutine 内未 recover 的 panic 会崩溃整个进程。
panic 中再次 panic：第二个 panic 会“覆盖”前一个的 recover 机会，行为复杂，应避免。
panic 携带的值可以是任意类型，但建议用 error 值，便于 recover 后用 errors.Is/As 判断：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
package main

import (
    "errors"
    "fmt"
)

var ErrInvalid = errors.New("invalid")

func main() {
    defer func() {
        if r := recover(); r != nil {
            if err, ok := r.(error); ok && errors.Is(err, ErrInvalid) {
                fmt.Println("recovered invalid:", err)
            } else {
                fmt.Println("recovered other:", r)
            }
        }
    }()
    panic(fmt.Errorf("wrapped: %w", ErrInvalid))
}

性能：panic 涉及栈展开和 defer 链遍历，开销远大于普通 error 返回，热路径上禁用。

recover

(1) 是什么

recover 是内置函数，仅在 deferred 函数内有效，用于“捕获”当前 panic，使程序从 panic 中恢复，返回 panic(v) 的 v。

(2) 为什么这样设计 / Runtime 实现要点

recover 必须在 defer 内调用——因为 panic 触发后只有 deferred 函数还在执行。在普通函数中调用 recover 永远返回 nil。
runtime.gorecover 的核心逻辑（伪代码）：

1
2
3
4
5
6
7
8
9
func gorecover(argp uintptr) any {
    gp := getg()
    p := gp._panic
    if p != nil && !p.goexit && !p.recovered && argp == uintptr(p.argp) {
        p.recovered = true
        return p.arg
    }
    return nil
}

逐行解释：

p := gp._panic：取当前 goroutine 的最新 panic。
!p.goexit：区分 runtime.Goexit 触发的“伪 panic”，Goexit 不应被 recover。
!p.recovered：防止重复 recover。
argp == uintptr(p.argp)：最关键的校验——只有“直接”被 defer 注册、当前正被 gopanic 调用的那个 deferred 函数内调用 recover 才生效。recover() 被包装到其它函数里再被 defer 调用就无效（因为 argp 不匹配）。
设置 recovered = true，返回 p.arg。后续 gopanic 检测到 recovered 后退出 panic 流程。

(3) 工程实践与常见坑

recover 必须直接放在 defer 函数体内：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
package main

import "fmt"

func doRecover() {
    _ = recover() // 无效！返回 nil
}

func main() {
    defer func() {
        doRecover() // recover 被包装，argp 不匹配
        fmt.Println("done")
    }()
    panic("boom")
}

正确写法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
package main

import "fmt"

func main() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("recovered:", r)
        }
    }()
    panic("boom")
}

HTTP 服务、RPC handler、goroutine 入口都应有 recover，否则单个请求 panic 会拖垮整个进程：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
package main

import (
    "log"
    "net/http"
    "runtime/debug"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        defer func() {
            if e := recover(); e != nil {
                log.Printf("panic: %v\n%s", e, debug.Stack())
                http.Error(w, "internal error", 500)
            }
        }()
        panic("boom")
    })
    http.ListenAndServe(":8080", nil)
}

recover 之后，被 recover 的函数仍然“返回”了，但其返回值是命名返回值的当前值（或非命名的零值）。因此 recover 后通常需要在 defer 中显式设置错误返回值：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
package main

import (
    "fmt"
)

func safeRun() (err error) {
    defer func() {
        if r := recover(); r != nil {
            err = fmt.Errorf("recovered: %v", r)
        }
    }()
    panic("fail")
}

func main() {
    err := safeRun()
    fmt.Println(err)
}

recover 不能跨 goroutine：goroutine 内 panic 只能由该 goroutine 内的 defer recover。
不要 recover 了之后什么都不做（吞掉错误），应至少记录日志，否则 bug 难以定位。

本章小结

Go 函数的所有参数都是值传递，slice/map/channel 的“引用感”来自其描述符共享底层数据。
返回值分命名与非命名，命名返回值可与 defer 配合修改最终结果。
多返回值是 ABI 约定，是 Go error 处理惯用法的基石。
defer 在 Go 1.21 已高度优化：开放编码、栈分配、堆分配三档，绝大多数场景开销可忽略。
panic/recover 是异常机制而非错误处理机制，库代码应返回 error 而非 panic；recover 必须直接位于 deferred 函数内。

第8章 函数

参数传递

返回值

多返回值

defer

panic

recover

本章小结

第8章函数