Что из этого следует

• Есть тип функции: type Handler func(w http.ResponseWriter, r *http.Request). Типы совместимы по сигнатуре, а не по имени.
• Функции тут значения, поэтому работают таблицы функций: map[string]func(int) int вместо длинного switch.
• Работают функции высшего порядка: sort.Slice(s, less), http.HandlerFunc, middleware вида func(next Handler) Handler.
• Есть анонимные функции и замыкания, то есть анонимные функции, захватившие переменные окружения.

// Функция как значение
var op func(int, int) int = func(a, b int) int { return a + b }

// Таблица вместо switch
var ops = map[string]func(int, int) int{
    "+": func(a, b int) int { return a + b },
    "*": func(a, b int) int { return a * b },
}

// Функция, возвращающая функцию (генератор middleware)
func WithTimeout(d time.Duration) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            ctx, cancel := context.WithTimeout(r.Context(), d)
            defer cancel()
            next.ServeHTTP(w, r.WithContext(ctx))
        })
    }
}

// Приём "тип-функция реализует интерфейс"
type HandlerFunc func(http.ResponseWriter, *http.Request)
func (f HandlerFunc) ServeHTTP(w http.ResponseWriter, r *http.Request) { f(w, r) }

Чего в Go нет

Нет перегрузки функций, нет параметров по умолчанию, нет именованных аргументов при вызове. Обходят это тремя способами: структура опций, functional options (func(*Server)) или отдельные функции NewX / NewXWithY.

Механика

Анонимная функция сослалась на локальную переменную внешней функции: escape-анализ решит, что переменная убегает в кучу, и замыкание получит на неё указатель. Все замыкания, захватившие одну переменную, смотрят в одну ячейку памяти и видят правки друг друга. Захват «по значению» получается только явно: передать параметром или снять копию через x := x.

func counter() func() int {
    n := 0                 // n убегает в кучу
    return func() int { n++; return n }
}
c := counter()
c(); c(); fmt.Println(c())  // 3 - состояние живёт в замыкании

// Два замыкания делят одну переменную
func pair() (inc, get func() int) {
    n := 0
    return func() int { n++; return n }, func() int { return n }
}

Ловушка цикла и Go 1.22

До Go 1.22 переменная, объявленная в for i := 0; ... или for i, v := range ..., создавалась один раз на весь цикл. Классика: for i := 0; i < 3; i++ { go func(){ print(i) }() } печатала 3 3 3. С Go 1.22 такие переменные живут одну итерацию, и код печатает 0 1 2 в произвольном порядке.

На что ещё ловят

• Ловушка живёт не в одних горутинах: тот же эффект при сохранении замыканий в слайс или при defer func(){ use(v) }() в цикле.
• Изменение не касается переменных, объявленных до цикла: i := 0; for ; i < 3; i++ { ... } ведёт себя по-старому.
• Цена небольшая, но есть: новая переменная на итерацию даёт аллокацию, если её захватило замыкание. В обычном цикле без замыканий компилятор её не делает.
• Старый приём v := v в 1.22+ безвреден, но избыточен; go vet в новых версиях больше не ругается на loopclosure для новых модулей.

Механика

Вариативный параметр обязан быть последним, и он только один. При вызове sum(1,2,3) компилятор аллоцирует временный массив из трёх элементов и передаёт слайс на него. При sum(s...) копии нет: функция получает заголовок исходного слайса и, изменив элемент, изменит его у вызывающего.

func sum(nums ...int) int {        // внутри nums имеет тип []int
    t := 0
    for _, n := range nums { t += n }
    return t
}

sum()            // nums не []int{} длины 0, а nil
sum(1, 2, 3)     // компилятор собрал слайс
s := []int{1,2,3}
sum(s...)        // тот же слайс, без копирования

// Подвох: функция может испортить твой слайс
func spoil(xs ...int) { if len(xs) > 0 { xs[0] = -1 } }
spoil(s...)      // s[0] == -1

// Подвох: append в вариативный параметр пишет в твой массив, если у него есть запас cap
func addOne(xs ...int) []int { return append(xs, 1) }
buf := make([]int, 2, 10)
_ = addOne(buf...) // единица легла в массив buf: buf[:3][2] == 1

Частые ошибки

• sum(s...) и sum(s) это разные вещи; второе не скомпилируется (кроме случая ...[]int).
• Смешивать нельзя: sum(1, s...) даёт ошибку компиляции.
• При len(args) == 0 параметр равен nil, а не пустому слайсу. len и range с ним работают нормально, но args != nil будет ложью.
• ...any (как в fmt.Println) заставляет боксировать каждый аргумент в интерфейс, а это аллокации. Отсюда и совет не звать fmt.Sprintf в горячем цикле.

Три правила

1. LIFO. Отложенные вызовы кладутся в стек: последний объявленный выполнится первым. Ровно это и нужно для парного захвата ресурсов: открыл A, открыл B, закроется B, потом A.
2. Аргументы вычисляются сразу. defer fmt.Println(i) при i == 0 напечатает 0, даже если дальше i = 42. Откладывается только вызов, не вычисление операндов. Получатель метода тоже аргумент: defer b.String() вычислит b.String() немедленно.
3. Работает на уровне функции. Ни if, ни for, ни блок {} defer не запускают. Только return, паника или конец тела.

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

func trap() {
    i := 0
    defer fmt.Println("A:", i)          // A: 0 - i скопирован сейчас
    defer func(){ fmt.Println("B:", i) }()  // B: 42 - замыкание видит переменную
    i = 42
}
// вывод: B: 42, затем A: 0

Чем плох defer в цикле

Он копится: цикл на 100 000 файлов зарегистрирует 100 000 отложенных Close(), и все они выполнятся только в конце функции. Ресурсы (дескрипторы, соединения, блокировки) держатся всё это время, и приложение упирается в too many open files. Плюс defer в цикле отключает open-coded оптимизацию: количество вызовов неизвестно на этапе компиляции, и компилятор откатывается на записи _defer в стеке.

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

func a() int      { x := 1; defer func(){ x = 99 }(); return x }   // 1
func b() (x int)  { x = 1; defer func(){ x = 99 }(); return x }    // 99
func c() (x int)  { defer func(){ x++ }(); return 5 }              // 6

В a() defer меняет локальную x, но значение уже скопировано в анонимный слот результата, и эффекта нет. В b() и c() именованная x и есть слот результата, поэтому правка видна.

Три практических применения

• Транзакции. Один defer решает, коммитить или откатывать, потому что видит итоговую err. И может вернуть ошибку самого Commit().
• Обогащение ошибки контекстом. Один defer оборачивает любую ошибку функции, не трогая десяток return err.
• Конверсия паники в error на границе пакета: без именованного результата ошибку из recover не вернуть.

func transfer(ctx context.Context, db *sql.DB, from, to int64, amount int64) (err error) {
    tx, err := db.BeginTx(ctx, nil)
    if err != nil { return fmt.Errorf("begin: %w", err) }
    defer func() {
        if p := recover(); p != nil {
            _ = tx.Rollback()
            panic(p)                        // не глотаем чужую панику
        }
        if err != nil {
            if rbErr := tx.Rollback(); rbErr != nil && !errors.Is(rbErr, sql.ErrTxDone) {
                err = errors.Join(err, fmt.Errorf("rollback: %w", rbErr))
            }
            return
        }
        err = tx.Commit()                   // ошибка коммита попадёт наружу
    }()

    if _, err = tx.ExecContext(ctx, `UPDATE accounts SET balance=balance-$1 WHERE id=$2`, amount, from); err != nil {
        return fmt.Errorf("debit: %w", err)
    }
    if _, err = tx.ExecContext(ctx, `UPDATE accounts SET balance=balance+$1 WHERE id=$2`, amount, to); err != nil {
        return fmt.Errorf("credit: %w", err)
    }
    return nil
}

Три поколения

• До 1.13. На каждый defer аллоцируется структура _defer в куче и вставляется в связный список горутины (g._defer). При выходе deferreturn обходит список. Порядок 50 нс плюс мусор для GC.
• 1.13. Записи _defer переехали в стековый фрейм. Аллокации в куче нет, но список и его обход остались: ~35 нс.
• 1.14, open-coded defers. Если число defer-ов известно статически, компилятор инлайнит нужные вызовы перед каждым return, а какие из них успели «зарегистрироваться», отслеживает битовой маской deferBits в регистре или на стеке. Никакого списка и обхода: overhead около одной наносекунды.

Когда оптимизация не включается

Компилятор откатывается к стековым записям, если defer стоит в цикле, если их в функции больше восьми или если оптимизации отключены (-gcflags="all=-N -l", то есть под отладчиком). Проверяется это через go build -gcflags=-m: в выводе видно «open-coded defer».

Пошагово

1. panic(v) создаёт запись _panic и обрывает текущую функцию прямо в этой точке.
2. Рантайм начинает раскрутку: в каждом фрейме, снизу вверх, выполняются его отложенные функции. Все до одной, паника этому не мешает.
3. Если очередная отложенная функция вызвала recover() и получила не nil, паника гаснет. Функция, которой принадлежал defer, завершается нормально и отдаёт то, что лежит в её (именованных) возвращаемых значениях.
4. Не перехватил никто: раскрутка доходит до корня горутины, рантайм печатает сообщение и стектрейс в stderr и завершает весь процесс с кодом 2.

Где именно должен стоять recover

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

func safe() (err error) {
    defer func() {                    // ОК: recover прямо здесь
        if r := recover(); r != nil {
            err = fmt.Errorf("panic: %v\n%s", r, debug.Stack())
        }
    }()
    return work()
}

// Работает и так: сама именованная функция отложена
func catch(err *error) {
    if r := recover(); r != nil { *err = fmt.Errorf("panic: %v", r) }
}
func safe2() (err error) { defer catch(&err); return work() }

Чего recover не ловит

Fatal error рантайма: concurrent map writes, дедлок («all goroutines are asleep»), stack overflow, out of memory. Это не паника: раскрутки нет, defer-ы не выполняются, процесс умирает сразу. Мимо проходит и os.Exit(), а runtime.Goexit() паникой не считается (defer-ы выполнятся, но recover() вернёт nil).

panic оправдан

• Баг в коде: невозможная ветка, нарушенный контракт, nil там, где его быть не может. panic("unreachable") честнее, чем молча вернуть ноль.
• Инициализация: regexp.MustCompile, template.Must, парсинг зашитой конфигурации. Программа с битым конфигом не должна стартовать: лучше упасть на первой секунде, чем отдавать мусор.
• Внутренний механизм пакета: быстрый выход из глубокой рекурсии парсера, но при условии, что паника гарантированно ловится на экспортируемой функции. Так устроены encoding/json и text/template.

panic недопустим

• Файл не найден, сеть недоступна, БД вернула ошибку, пользователь прислал мусор. Это обычные ошибки, их возвращают.
• В публичном API библиотеки: вызывающий не обязан оборачивать твои функции в recover.
• Как способ выйти из вложенных циклов: для этого есть метки (outer: for { ... break outer }).

Правило границы

Раз внутри пакета паника работает как механизм, перехвати её на границе и верни error, обязательно отличая свою панику от чужой по типу и пробрасывая чужие дальше. Иначе глухой recover проглотит настоящий nil pointer dereference и спрячет баг.

Почему так

Раскрутка идёт по стеку конкретной горутины. Горутины не вложены друг в друга: у запущенной go f() собственный стек, «родительского» фрейма в нём нет. Дойдя до корня своего стека, паника упирается в тупик: рантайм вызывает fatalpanic, печатает трейс и завершает процесс. Ни один defer в других горутинах при этом не выполнится.

// Обязательная обёртка для любой фоновой горутины
func Go(fn func()) {
    go func() {
        defer func() {
            if r := recover(); r != nil {
                metrics.PanicsTotal.Inc()
                log.Printf("panic: %v\n%s", r, debug.Stack())
            }
        }()
        fn()
    }()
}

// Если результат нужен наверху, отдаём панику как ошибку
func RunSafe(fn func() error) (err error) {
    done := make(chan error, 1)
    go func() {
        defer func() {
            if r := recover(); r != nil {
                done <- fmt.Errorf("panic: %v\n%s", r, debug.Stack())
            }
        }()
        done <- fn()
    }()
    return <-done
}

Три вещи, которые тут проверяют

• net/http ставит recover вокруг вызова хендлера, но только в горутине соединения. Если хендлер сам запустил go и там паника, сервер умрёт. Плюс http.ErrAbortHandler, специальная паника, которую сервер гасит молча.
• errgroup собирает error, но исторически не перехватывал паники; в свежих версиях x/sync паника пробрасывается в Wait(), но закладываться на это без проверки версии нельзя.
• Даже с глобальным recover-middleware паника оставляет систему в неопределённом состоянии: незакрытые транзакции, недоснятые локи. Recover помогает не уронить соседние запросы, но баг за тебя не починит.

Главный практический вывод

log.Fatalf это os.Exit(1), поэтому все defer db.Close(), defer tracer.Shutdown(), defer f.Sync() тихо не выполнятся: буферы не сброшены, спаны не отправлены, соединения не закрыты. Отсюда паттерн «тонкий main»: вся работа в run() error с нормальными return, а main занимает три строки с единственным os.Exit(1) в самом конце, когда defer-ов уже нет.

func main() {
    if err := run(); err != nil {
        fmt.Fprintln(os.Stderr, "error:", err)
        os.Exit(1)
    }
}