Ответ.

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

История вопроса:

Defer взято из других языков и сильно упрощает жизнь go-разработчика. Сочетание defer и замыкания стало стандартом для обеспечения очистки файлов, соединений и любых внешних ресурсов в блоках, где может быть много выходов (return, panic).

Проблема:

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

Решение:

Использовать defer с анонимной функцией (closure), чтобы:

Изолировать область видимости переменных,
Безопасно обрабатывать ошибки при закрытии,
Управлять накоплением сообщений/сбором мусора.

Пример кода:

package main
import (
    "fmt"
    "os"
)

func WriteFileDemo(filename string) (err error) {
    f, err := os.Create(filename)
    if err != nil { return }
    defer func() {
        cerr := f.Close()
        if cerr != nil && err == nil {
            err = cerr
        }
    }()
    // Рабочая логика с файлом
    fmt.Fprintln(f, "Hello world")
    return // defer выполнится даже если здесь return
}

func main() {
    if err := WriteFileDemo("test.txt"); err != nil {
        fmt.Println("Error:", err)
    }
}

Ключевые особенности:

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

Вопросы с подвохом.

Когда переменные, используемые внутри отложенного замыкания, фиксируются — в момент объявления defer или при фактическом вызове?

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

for i := 0; i < 3; i++ {
    defer func() { fmt.Println(i) }() // напечатает 2, 2, 2
}

Можно ли передавать значения в замыкание через параметры, чтобы избежать захвата по ссылке?

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

for i := 0; i < 3; i++ {
    defer func(n int) { fmt.Println(n) }(i) // напечатает 2, 1, 0
}

Что делать, если в отложенном замыкании обнаружена паника? Как обработать её?

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

defer func() {
    if r := recover(); r != nil {
        log.Println("Recovered:", r)
    }
}()

Типовые ошибки и анти-паттерны

Захват переменных цикла по ссылке в отложенном замыкании
Неучитывание ошибок внутри замыкания (ошибки теряются)
Нарушение порядка вызова defer (LIFO: последний defer первым)

Пример из жизни

Негативный кейс

Код открывает несколько файлов, но забывает поставить defer f.Close(). При возникновении ошибки возвращает управление, и часть файлов остаётся неочищенной, возникают утечки ресурсов.

Плюсы:

Меньше кода

Минусы:

Утечки памяти или файловых дескрипторов, нестабильная работа

Позитивный кейс

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