Краткий ответ

Вызывающий код получит значение, которое именированный результат имел после выполнения всех отложенных функций. При возврате Go сначала вычисляет выражения возврата и записывает их в именированные результаты, затем выполняет defer в обратном порядке регистрации и только после этого фактически передаёт результаты вызывающему коду.

Исторический контекст

defer появился как языковой механизм для надёжного выполнения завершающих действий: закрытия ресурсов, освобождения блокировок и отката операций при любом пути выхода из функции. Это устраняет необходимость вручную дублировать очистку перед каждым return.

Связь defer с именированными результатами — следствие общей модели выполнения: именированный результат является локальной переменной функции, а отложенная функция может обратиться к этой переменной до фактического завершения вызова.

Постановка проблемы

Если разработчик считает, что return немедленно передаёт вычисленное значение вызывающему коду, он может неверно оценить результат функции. Особенно опасны функции, где defer изменяет ошибку, добавляет контекст или подменяет возвращаемое значение.

Такой код способен скрывать логику формирования результата: визуально значение возвращается в одном месте, но фактически меняется в отложенной функции. Это усложняет сопровождение и может привести к неожиданному подавлению ошибок.

Подробное решение

У именированной переменной результата есть обычное значение и область видимости внутри функции. При выполнении return выражение выражение вычисляется первым, его значение записывается в соответствующий результат, затем запускаются отложенные функции, и после этого функция завершается.

package main

import "fmt"

func value() (result int) {
    defer func() {
        result++
    }()
    return 10
}

func main() {
    fmt.Println(value())
}

Программа напечатает 11: число 10 сначала записывается в result, затем defer увеличивает эту переменную. Если бы отложенная функция получила значение как аргумент, аргумент вычислился бы в момент регистрации defer, а не перед выполнением отложенной функции.

Отложенные вызовы выполняются в порядке LIFO: последний зарегистрированный выполняется первым. Если defer вызывает panic, последующие отложенные функции текущей функции всё равно выполняются; если отложенная функция вызывает recover в допустимом контексте, она может остановить распространение паники.

Изменять именированные результаты в defer технически допустимо, но это создаёт скрытую связь между возвратом и завершающей логикой. Обычно такой приём оправдан для единообразного добавления контекста к ошибкам, а для обычных значений предпочтительнее явное вычисление результата перед return.

Важно различать изменение результата и изменение переменной, переданной аргументом отложенной функции. Аргументы defer вычисляются сразу, тогда как замыкание без явной передачи аргумента обращается к переменной во время фактического выполнения.

Ситуация из практики

В функции доступа к хранилищу нужно добавлять к любой возвращаемой ошибке имя операции. Рассматривались два варианта: явно оборачивать ошибку перед каждым return или использовать один defer с именированным результатом.

Явная обработка проще для локального чтения и не меняет результат скрыто, но при добавлении новых ветвей легко забыть обернуть ошибку. defer централизует правило и гарантирует единый формат, однако требует понимания именированного результата и может затруднить отладку.

Для небольшой функции с несколькими однотипными путями выхода допустим второй вариант, если его явно задокументировать и изменять только ошибку. В более сложной функции лучше выбрать явное формирование ошибки: предсказуемость обычно важнее сокращения повторяющегося кода.

Что кандидаты часто упускают

Что произойдёт, если defer зарегистрирован с аргументом, а не через замыкание?

Аргументы отложенного вызова вычисляются в момент выполнения оператора defer. Поэтому последующее изменение переменной не повлияет на уже вычисленную копию аргумента. Замыкание, напротив, обычно обращается к самой переменной при выполнении.
Может ли defer изменить результат функции без именированного результата?

Напрямую изменить возвращаемое значение через имя нельзя, если результат не имеет имени в сигнатуре. defer всё равно выполнится после вычисления выражений return, но для изменения результата ему пришлось бы использовать доступное внешнее состояние, указатель или другую косвенную связь. Это обычно менее прозрачно и потому редко оправдано.
Что произойдёт, если несколько defer изменяют один именированный результат?

Они выполнятся в обратном порядке регистрации, и каждое изменение увидит результат после предыдущего отложенного вызова. Поэтому итог зависит не только от содержимого функций, но и от порядка их регистрации. При наличии нескольких таких изменений следует считать порядок частью контракта функции или отказаться от скрытой модификации результата.