问题的历史
defer 语句自 Go 的首次发布以来就是其核心特性，旨在确保资源清理在函数返回的任何路径下都能执行。在 Go 的早期开发中，团队认识到允许延迟函数检查和修改命名结果参数的实用性，尤其是在日志记录、错误包装和资源状态验证时。这个能力并非偶然，而是一个有意的设计决策，旨在支持诸如事务回滚错误报告等模式，而无需复杂的样板代码。
问题描述
考虑一个返回 (result int, err error) 的函数。当函数执行 return 42, nil 时，值被分配给命名返回变量 result 和 err。然而，如果一个延迟函数在这个赋值之后但在函数真正返回给调用者之前运行，它能改变调用者收到的内容吗？如果返回值是未命名的（例如，func calculate() int），延迟函数就没有手柄可以访问返回槽。矛盾之处在于理解返回值何时被最终确定，以及延迟闭包如何捕获这些变量。
解决方案
Go 允许延迟函数修改命名返回值，因为这些名称作为在函数的栈帧（或如果逃逸则在堆上的）分配的局部变量。当 return 语句执行时，它计算表达式并将值分配给命名结果变量。随后，Go 以后进先出顺序执行延迟函数。如果延迟函数引用了命名返回变量（例如，err），它在相同的内存位置操作。因此，在延迟函数内对 err 的任何赋值都会覆盖 return 语句设置的值。未命名的返回值缺乏这种可寻址位置，无法被延迟函数修改。
func example() (result int) { defer func() { result++ // 修改命名返回值 }() return 10 // result 被设置为 10，defer 递增至 11 }
问题描述
我们正在构建一个支付处理服务，其中一个函数 ProcessPayment 会扣除资金并记录交易。该函数返回 (txnID string, err error)。出现了一个重要需求：如果数据库事务成功提交，但随后的审计日志写入失败，我们需要返回交易 ID（成功）和表示审计失败的错误。然而，如果支付扣除本身失败，我们需要回滚并返回该错误。挑战在于确保函数返回最严重的错误，同时在部分成功时保留交易 ID。
考虑的不同解决方案
解决方案 1：通过多个返回聚合错误
我们考虑将签名更改为 ProcessPayment() (string, []error) 以收集所有错误。这种方法提供了完整的透明性，但违反了习惯用法 Go 的错误处理，因为它期望只有一个错误。它迫使每个调用者实现错误优先级逻辑，大大复杂化了 API 表面，增加了代码维护的难度。
解决方案 2：基于结构的返回类型
另一种方法是创建一个 PaymentResult 结构体，包含 TxnID、Err 和 AuditErr 字段。虽然这封装了数据，但它要求调用者检查结构字段，而不是使用简单的 if err != nil 检查。这种模式对于一个频繁调用的操作来说感觉沉重，偏离了标准的 Go 约定，降低了代码在代码库中的可读性。
解决方案 3：通过 defer 操作命名返回值
我们利用了一个命名返回值 err error，并延迟了一个在主逻辑之后执行的函数。这个延迟函数检查是否生成了交易 ID（表示成功扣除），但在审计日志记录时发生了错误。然后它将现有错误包装上审计上下文，或根据严重性优先考虑审计失败。这保持了干净的 (string, error) 签名，同时允许内部进行复杂的错误状态管理。
选择的解决方案和结果
我们选择了解决方案3。通过声明 func ProcessPayment() (txnID string, err error) 并延迟一个引用 err 的闭包，我们能够在主执行路径完成后拦截并修改最终错误。如果支付成功（txnID 被赋值）但审计失败，则延迟函数将 err 更新为反映审计失败，同时保留 txnID。这种方法使 API 保持习惯，避免了对错误切片的分配，并将错误优先级逻辑集中在函数内部。最终结果是呼叫位置的样板代码减少了 40%，并在整个服务中保持了一致的错误处理模式。
为什么传递给延迟函数的参数立即评估，而命名返回的修改则发生在稍后？
许多候选人混淆了延迟函数参数的评估与延迟函数体的执行。当写 defer fmt.Println(count) 时，count 会立即评估并存储。然而，当写 defer func() { result++ }() 时，result 仅在执行时被评估；如果 result 是命名返回，则它指的是将被返回的同一个变量。
答案：
Go 的规范说明，延迟函数调用的参数会立即评估，但函数调用本身被延迟。在闭包的情况下（func() { ... }），没有参数传递给延迟调用本身，因此没有参数在延迟站点被捕获。相反，闭包通过引用捕获变量。命名返回变量在函数前言中分配一次。当 return 执行时，它写入这些变量。然后延迟闭包执行并修改相同的内存地址。对于非闭包的延迟，例如 defer f(x)，x 会立即复制到一个临时位置，因此即使 x 后来发生变化，延迟调用也使用原始值。
当 panic 和 recover 与在 defer 中修改的命名返回值互动时，会发生什么？
候选人往往难以解释恢复的 panic 是否允许命名返回的修改持续存在。
答案：
当发生 panic 时，Go 开始展开堆栈，执行延迟函数。如果一个延迟函数调用 recover()，它会停止 panic。如果那个延迟函数还修改了命名返回值，修改将持续存在，因为命名返回变量在整个 panic 恢复过程中保持分配。然而，如果函数正常返回（没有 panic），但一个延迟函数 panic，任何由较早的延迟函数对命名返回的修改将被丢弃，因为新的 panic 替换了正常的返回路径。关键的见解是 recover 将控制权返回给调用者，就好像函数正常返回，因此所做的对命名结果的任何更改在恢复之前或期间对调用者是可见的。
单独使用命名返回来启用 defer 修改的性能开销是多少，以及何时逃逸分析迫使堆分配？
候选人常常忽视命名返回有时相比未命名返回迫使堆分配。
答案： 命名返回值通常表现得像局部变量。然而，如果一个延迟函数引用了一个命名返回（或任何局部变量），逃逸分析会判断该变量的生命周期超出了函数的正常执行范围。因此，Go 会在堆上而不是在栈上分配该变量。这种分配会造成垃圾收集的压力。在热路径中，避免命名返回（当不需要 defer 修改时）可以减少分配。编译器优化简单情况，但如果延迟闭包通过引用捕获了命名返回，堆分配是不可避免的。这种权衡在正确性和清晰 API 设计之间而不是微优化之间当 profiling 确定瓶颈时优先考虑。