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

Несколько блоков defer выполняются в обратном порядке их регистрации: последняя зарегистрированная очистка запускается первой. Поэтому порядок — LIFO: «последним вошёл — первым вышел».

Например, если сначала зарегистрированы first, затем second, при выходе сначала выполнится second, а потом first.

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

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

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

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

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

Неверное предположение о порядке defer особенно опасно потому, что код очистки находится далеко от места фактического выхода и может выполняться не только при обычном return.

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

Каждый достигнутый оператор defer регистрирует действие для текущей области видимости. При выходе из этой области Swift выполняет зарегистрированные действия от последнего к первому.

func process() {
    defer { print("освободить внешний ресурс") }
    defer { print("закрыть внутренний ресурс") }
    print("работа")
}

process()
// работа
// закрыть внутренний ресурс
// освободить внешний ресурс

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

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

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

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

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

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

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

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

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

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

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

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

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