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

Аргументы отложенного вызова вычисляются в момент выполнения оператора defer, а не при фактическом запуске функции во время обычного выхода или раскрутки после panic. Поэтому к моменту выполнения deferred-функции значения простых аргументов уже зафиксированы.

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

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

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

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

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

Неверное понимание механизма приводит к неправильным логам, очистке не того ресурса или диагностике устаревшего состояния. Отдельный случай — передача указателя: сам указатель фиксируется, но данные по этому адресу могут измениться до выполнения deferred-вызова.

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

При выполнении defer Go вычисляет функцию или метод, его receiver и все аргументы, после чего сохраняет отложенный вызов. Сам вызов выполняется позднее в обратном порядке регистрации — в том числе во время обработки panic.

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

package main

import "fmt"

func main() {
	defer func() { recover() }()
	id := "A"
	defer fmt.Println("аргумент:", id)
	defer func() { fmt.Println("замыкание:", id) }()
	id = "B"
	panic("stop")
}

Здесь сначала напечатается замыкание: B, затем аргумент: A: deferred-вызовы выполняются в обратном порядке, но аргумент id для fmt.Println был вычислен при регистрации. В deferred-замыкании чтение id произошло уже после изменения переменной.

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

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

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

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

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

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

Фиксируется ли объект при передаче указателя в defer?

Нет. Фиксируется значение указателя, то есть адрес объекта. Изменение полей объекта до выполнения deferred-вызова будет видно через этот указатель. Если нужен настоящий снимок, необходимо заранее скопировать нужные данные, а не только передать адрес.

Что происходит с receiver отложенного метода?

Receiver вычисляется при выполнении defer, как и обычные аргументы. Поэтому выбранный указатель или значение фиксируется сразу. Однако метод может прочитать изменяемое состояние объекта уже позднее, если receiver указывает на тот же объект.

Можно ли считать замыкание способом отложенного вычисления любого аргумента?

Да, если выражение поместить внутрь тела замыкания: тогда оно вычислится при запуске замыкания. Но захваченные переменные могут измениться, а доступ к ним из разных горутин должен быть синхронизирован. Поэтому замыкание не просто «откладывает аргумент», а меняет момент чтения состояния и потенциально добавляет требования к безопасности доступа.