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

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

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

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

Ключевая особенность состоит в том, что defer выполняется позже, поэтому важно понимать не только момент его запуска, но и правила захвата состояния, к которому обращается его тело.

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

Если переменная изменяется после объявления defer, разработчик может ошибочно ожидать, что отложенное действие увидит старое значение. Это способно привести к неверному журналированию, неправильному статусу транзакции или очистке не того ресурса.

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

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

Без списка захвата изменяемая локальная переменная захватывается как общее хранилище. Все последующие изменения этой переменной будут видны в defer:

func process() {
    var status = "started"
    defer { print(status) }
    status = "finished"
}

process() // finished

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

func process() {
    var status = "started"
    defer { [status] in print(status) }
    status = "finished"
}

process() // started

Это различие не связано с throws: defer выполнится как при обычном выходе, так и при передаче ошибки наружу, но значение внутри его тела определяется правилами захвата. Для изменяемого состояния обычно нужен актуальный итог, а для аудита исходных параметров — явная копия через список захвата.

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

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

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

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

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

Что изменится при использовании списка захвата для переменной-значения?

Список захвата создаёт снимок значения в момент создания тела defer. Последующие присваивания исходной переменной не повлияют на захваченную копию. Для структур, строк и других типов-значений это обычно означает независимое значение.
Как ведёт себя захваченная ссылка на объект, если объект изменяется?

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

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