Go defer 参数为什么在 defer 语句执行时就求值

Go 的 defer 延迟的是函数调用本身。执行到 defer 语句时，被调用的函数值、接收者和参数表达式已经求值并保存；等外层函数退出，才使用保存的值调用它。因此，后面修改整数、字符串或 error 变量，不会改变已经保存的参数。

生产日志需要先确定记录口径：入口参数通常适合立即保存，最终错误与耗时通常适合在延迟闭包体内读取或计算。资源关闭则应绑定当时取得的资源，避免变量复用后关错对象。

Go 官方地址：https://go.dev/

语言规范：https://go.dev/ref/spec#Defer_statements

日志为什么总是记录初始状态

设想一个批处理函数：开始时状态为 pending，完成后改为 done，结束日志却仍为 pending。先看 defer 调用括号中的实参，不要先怀疑日志库缓存。

func process() {
    status := "pending"
    // status 在此处作为字符串值保存，Println 本身稍后调用。
    defer fmt.Println("saved status:", status)
    status = "done"
    fmt.Println("current status:", status)
}

这个片段需要放在已导入 fmt 的 Go 文件中。按语言语义推导，普通调用读取 done，延迟调用保存 pending。这里没有运行输出截图，也没有实测日志。保存参数使清理调用不受后续变量重新赋值影响，但它不自动替你选择“入口”还是“结束”口径。

可把代码理解为保存一份待调用记录：函数值属于调用目标，参数值属于调用数据，外层函数属于退出边界。实际实现不必采用某种固定栈结构，文章也不依赖编译器如何优化 defer。

用显式参数和闭包选择记录口径

如果需要最终状态，把读取动作放入闭包体。闭包仍在 defer 处作为函数值保存，但闭包体里面的表达式要等调用时才执行。显式传入闭包的参数仍然立即求值，不能只凭代码出现 func 就认定读取最终值。

func recordStatus() {
    status := "pending"
    // 没有传入 status，闭包体读取共享的局部变量。
    defer func() {
        fmt.Println("final status:", status)
    }()
    // 传入参数仍会保存入口值，匿名函数不会改变这条规则。
    defer func(saved string) {
        fmt.Println("entry status:", saved)
    }(status)
    status = "done"
}

上述两个延迟调用退出时逆序执行，先打印入口口径，再打印最终口径。重点是数据来自参数还是闭包中的变量，而不是日志文本的先后。

耗时也有同类问题：defer logDuration(time.Since(start)) 在登记调用时就计算了耗时。要记录完整函数耗时，可以写成延迟闭包，在闭包体中执行 time.Since(start)。初始时间 start 保持不变，结束时读取当前时间，才符合这个指标的定义。

指针和切片并不等于完整快照

“参数已经保存”只保证按 Go 的值传递规则保存参数值，不保证整个可达对象被深拷贝。指针参数保存地址，之后修改该地址指向的字段，延迟函数解引用时仍能读到修改。切片参数保存切片值，底层数组中的元素仍可能共享。

func sliceCase() {
    values := []int{10, 20}
    // 保存的切片仍引用同一个底层数组。
    defer func(saved []int) {
        fmt.Println("shared element:", saved[0])
    }(values)
    // 只复制元素，供本例的 int 切片保存独立快照。
    snapshot := append([]int(nil), values...)
    defer func(saved []int) {
        fmt.Println("copied element:", saved[0])
    }(snapshot)
    values[0] = 99
}

语义推导中，复制元素的版本读取 10，共享数组的版本读取 99。这里的元素是 int；若元素含指针、切片或 map，上述复制仍不等于递归深拷贝。要保存日志快照，应明确复制哪些字段，避免复制无关的大对象。

map 参数同样可能共享内容；接口参数保存接口值，但接口中持有的指针仍可能通向可变对象。闭包访问被其他 goroutine 修改的数据时还需要同步，defer 本身没有提供并发保护。

资源关闭应绑定取得的那个对象

日志常常想读取最终状态，关闭资源却通常想保存取得时的对象。defer f.Close() 会绑定当时的方法接收者；如果后来给 f 赋另一个文件，不会把这个延迟调用的目标换掉。相反，直接闭包引用 f，会在退出时读取 f 当时持有的值。

下面把资源作为闭包参数传入，同时在闭包体处理关闭错误。片段需放在导入 fmt、io 和 os 的文件中。

func readLocal(name string) (data []byte, err error) {
    f, err := os.Open(name)
    if err != nil {
        return nil, err
    }
    // 参数锁定当前资源，闭包体处理 Close 的返回错误。
    defer func(opened *os.File) {
        if closeErr := opened.Close(); err == nil && closeErr != nil {
            err = fmt.Errorf("close file: %w", closeErr)
        }
    }(f)
    data, err = io.ReadAll(f)
    return data, err
}

这里优先保留读取错误，读取成功时才返回关闭错误。err 是命名结果，延迟函数在结果已经设置、尚未返回调用方时修改它。这是明确的错误策略；若业务需要同时保留两类错误，可另行设计组合方式。资源只有成功取得后才登记关闭，不能把 defer 放在错误判断前面。

把资源传入参数只是绑定对象，不会让它提前释放；defer 仍属于外层函数退出范围。循环中资源过多时，考虑把单次处理拆成小函数，使资源生命周期与业务单元一致。

用完整例子区分三种日志写法

下面的 main.go 可独立保存使用，包含入口快照、结束状态和结束耗时三个口径，不依赖网络、文件权限或外部服务。示例没有在本次写作环境执行，结果描述是依据语义推导。

package main

import (
    "fmt"
    "time"
)

func inspectTask() {
    status := "pending"
    started := time.Now()
    // 显式参数保存入口状态。
    defer func(saved string) {
        fmt.Println("entry:", saved)
    }(status)
    // 结束时读取 status，并在函数体内计算耗时。
    defer func() {
        fmt.Println("exit:", status)
        fmt.Println("elapsed:", time.Since(started))
    }()
    status = "done"
    fmt.Println("body:", status)
}

func main() {
    // 仅演示登记参数与闭包读取的区别。
    inspectTask()
}

# 在保存 main.go 的目录运行；耗时随机器与调度而变化。
go run main.go

预期普通调用的 body 为 done，接着退出闭包读取 done 并打印耗时，最后入口快照仍为 pending。不要把耗时写死成某个毫秒数；这个例子没有人为等待，数值可以很小。比较目标是读取口径，不是性能基准。

上线前核对参数表达式与错误出口

上线修改时，逐个看括号内是否包含读文件、构造对象或有副作用的函数。这些实参表达式会立即执行；如果它们 panic，尚未成功登记的当前 defer 不会成为后续清理保障。也应检查每个提前 return 分支是否在资源成功获取后已经登记清理。

defer 后面的函数变量重新赋值会换目标吗？

不会。调用的函数值也会保存；需要动态选择目标时，应在闭包体中明确读取并检查它。

传入指针能读取最终值吗？

可以读取所保存地址指向的状态，但保存的是当时的地址；原指针变量后来改指向别处，不会跟着切换。并发读写仍须同步。

所有退出路径都会调用 defer 吗？

正常返回及 panic 导致的栈展开会调用已登记的延迟函数，但不能把它当成所有进程终止情形下的落盘保证。进程被强制终止等情况需要独立的持久化设计。

延伸阅读：https://go.dev/doc/effective_go#defer；https://go.dev/ref/spec#Function_literals。规范定义求值与调用规则，Effective Go 解释资源清理用途；本文示例按日志和资源所有权场景独立编写。