Senior Go Interview Prep

- Core Go: https://go.vbloher.org/docs/01-core-go/
- Механика defer в Go: https://go.vbloher.org/docs/01-core-go/defer/
- Встраивание структур и интерфейсов (Embedding): https://go.vbloher.org/docs/01-core-go/embedding/
- Ошибки в Go: error, wrapping, errors.Is/As/Join: https://go.vbloher.org/docs/01-core-go/errors/
- Дженерики в Go (1.18+): https://go.vbloher.org/docs/01-core-go/generics/
- Интерфейсы в Go: https://go.vbloher.org/docs/01-core-go/interfaces/
- Устройство map в Go: https://go.vbloher.org/docs/01-core-go/maps/
- panic / recover: механика, раскрутка стека и runtime-паники: https://go.vbloher.org/docs/01-core-go/panic-recover/
- Указатели в Go: https://go.vbloher.org/docs/01-core-go/pointers/
- Рефлексия в Go (reflect): https://go.vbloher.org/docs/01-core-go/reflection/
- Внутреннее устройство слайсов в Go: https://go.vbloher.org/docs/01-core-go/slices/
- Строки, руны и байты в Go: https://go.vbloher.org/docs/01-core-go/strings-runes-bytes/
- Система типов Go: defined types, alignment, memory layout: https://go.vbloher.org/docs/01-core-go/type-system/
- Concurrency: https://go.vbloher.org/docs/02-concurrency/
- sync/atomic: https://go.vbloher.org/docs/02-concurrency/atomic/
- Буферизованные vs небуферизованные каналы: https://go.vbloher.org/docs/02-concurrency/buffered-unbuffered/
- Канал vs Mutex: когда что выбрать: https://go.vbloher.org/docs/02-concurrency/channel-vs-mutex/
- Каналы: устройство hchan: https://go.vbloher.org/docs/02-concurrency/channels/
- Утечки горутин, дедлоки, livelock, starvation: https://go.vbloher.org/docs/02-concurrency/common-leaks-deadlocks/
- sync.Cond: https://go.vbloher.org/docs/02-concurrency/cond/
- context: https://go.vbloher.org/docs/02-concurrency/context/
- Горутины: жизненный цикл, стоимость, стек: https://go.vbloher.org/docs/02-concurrency/goroutines-lifecycle/
- sync.Mutex и sync.RWMutex: https://go.vbloher.org/docs/02-concurrency/mutex-rwmutex/
- sync.Once: https://go.vbloher.org/docs/02-concurrency/once/
- Паттерны конкурентности: https://go.vbloher.org/docs/02-concurrency/patterns/
- Race Detector (гонки данных и -race): https://go.vbloher.org/docs/02-concurrency/race-detector/
- Планировщик GMP: https://go.vbloher.org/docs/02-concurrency/scheduler-gmp/
- select: https://go.vbloher.org/docs/02-concurrency/select/
- sync.WaitGroup: https://go.vbloher.org/docs/02-concurrency/waitgroup/
- Runtime и память: https://go.vbloher.org/docs/03-runtime-memory/
- Паттерны аллокаций и снижение давления на GC: https://go.vbloher.org/docs/03-runtime-memory/allocation-patterns/
- Escape Analysis: когда переменная убегает в кучу: https://go.vbloher.org/docs/03-runtime-memory/escape-analysis/
- Сборщик мусора Go: concurrent tri-color mark-sweep: https://go.vbloher.org/docs/03-runtime-memory/gc/
- Тюнинг GC: GOGC и GOMEMLIMIT: https://go.vbloher.org/docs/03-runtime-memory/gogc-gomemlimit/
- GOMAXPROCS: параллелизм планировщика и проблема контейнеров: https://go.vbloher.org/docs/03-runtime-memory/gomaxprocs/
- Утечки горутин (goroutine leaks): https://go.vbloher.org/docs/03-runtime-memory/goroutine-leaks/
- Утечки памяти в Go (несмотря на GC): https://go.vbloher.org/docs/03-runtime-memory/memory-leaks/
- Модель памяти Go (Go Memory Model): happens-before и синхронизация: https://go.vbloher.org/docs/03-runtime-memory/memory-model/
- pprof: профилирование CPU, памяти и блокировок в Go: https://go.vbloher.org/docs/03-runtime-memory/pprof/
- Execution Tracer и runtime/trace: тайминги вместо агрегатов: https://go.vbloher.org/docs/03-runtime-memory/runtime-tracing/
- Стек vs Куча: где живут данные в Go: https://go.vbloher.org/docs/03-runtime-memory/stack-vs-heap/
- Тестирование: https://go.vbloher.org/docs/04-testing/
- testify, assert/require и golden files: https://go.vbloher.org/docs/04-testing/assertions-testify/
- Бенчмарки в Go: https://go.vbloher.org/docs/04-testing/benchmarks/
- Покрытие, -race и флаки-тесты: https://go.vbloher.org/docs/04-testing/coverage-race/
- Нативный fuzzing в Go (1.18+): https://go.vbloher.org/docs/04-testing/fuzzing/
- Интеграционные тесты, testcontainers-go, TestMain: https://go.vbloher.org/docs/04-testing/integration-testcontainers/
- Моки, стабы и тестируемость: https://go.vbloher.org/docs/04-testing/mocks/
- Table-driven тесты, subtests и параллельность: https://go.vbloher.org/docs/04-testing/table-driven/
- Backend: https://go.vbloher.org/docs/05-backend/
- Аутентификация и авторизация: AuthN/AuthZ, сессии vs токены, RBAC/ABAC, API keys, mTLS, секреты: https://go.vbloher.org/docs/05-backend/auth-authz/
- Graceful Shutdown HTTP/gRPC сервера в Go: https://go.vbloher.org/docs/05-backend/graceful-shutdown/
- gRPC: типы RPC, интерсепторы, контекст, метаданные, error model: https://go.vbloher.org/docs/05-backend/grpc/
- JWT (JSON Web Token): https://go.vbloher.org/docs/05-backend/jwt/
- Middleware-паттерн в Go: https://go.vbloher.org/docs/05-backend/middleware/
- net/http: Server, Handler, ServeMux, таймауты, Client и контекст: https://go.vbloher.org/docs/05-backend/net-http/
- OAuth2: роли, grant types, OIDC, токены и типовые ошибки: https://go.vbloher.org/docs/05-backend/oauth2/
- OpenAPI/Swagger, code generation, contract-first vs code-first, валидация: https://go.vbloher.org/docs/05-backend/openapi/
- Protocol Buffers: схемы, wire format, эволюция и совместимость: https://go.vbloher.org/docs/05-backend/protobuf/
- REST: принципы, версионирование, идемпотентность, статусы, пагинация, ошибки: https://go.vbloher.org/docs/05-backend/rest/
- Сети и протоколы: https://go.vbloher.org/docs/06-networking/
- Пулы соединений: http.Transport, БД, утечки: https://go.vbloher.org/docs/06-networking/connection-pooling/
- DNS: записи, резолвинг, кэширование, DNS в Go: https://go.vbloher.org/docs/06-networking/dns/
- Версии HTTP: 1.1, 2, 3: https://go.vbloher.org/docs/06-networking/http-versions/
- TCP/IP: модель, транспорт и что важно бэкендеру: https://go.vbloher.org/docs/06-networking/tcp-ip/
- TLS: handshake, сертификаты, mTLS, производительность: https://go.vbloher.org/docs/06-networking/tls/
- UDP и надёжность поверх UDP: https://go.vbloher.org/docs/06-networking/udp/
- WebSocket: upgrade, фреймы, масштабирование: https://go.vbloher.org/docs/06-networking/websocket/
- Базы данных: https://go.vbloher.org/docs/07-databases/
- Пул соединений к PostgreSQL в Go: database/sql, pgx, pgxpool, PgBouncer: https://go.vbloher.org/docs/07-databases/connection-pooling-pgx/
- Взаимоблокировки (Deadlocks) в PostgreSQL: https://go.vbloher.org/docs/07-databases/deadlocks/
- Индексы в PostgreSQL: https://go.vbloher.org/docs/07-databases/indexes/
- Уровни изоляции транзакций в PostgreSQL: https://go.vbloher.org/docs/07-databases/isolation-levels/
- MVCC в PostgreSQL: версии строк, видимость, VACUUM и bloat: https://go.vbloher.org/docs/07-databases/mvcc/
- Обзор NoSQL и Redis: https://go.vbloher.org/docs/07-databases/nosql-redis/
- Партиционирование таблиц в PostgreSQL: https://go.vbloher.org/docs/07-databases/partitioning/
- Архитектура PostgreSQL: https://go.vbloher.org/docs/07-databases/postgresql-architecture/
- Планирование и оптимизация запросов в PostgreSQL: https://go.vbloher.org/docs/07-databases/query-planning/
- Репликация в PostgreSQL: https://go.vbloher.org/docs/07-databases/replication/
- Шардирование (горизонтальное масштабирование): https://go.vbloher.org/docs/07-databases/sharding/
- Транзакции в PostgreSQL и Go (database/sql, pgx): https://go.vbloher.org/docs/07-databases/transactions/
- Распределённые системы: https://go.vbloher.org/docs/08-distributed-systems/
- CAP теорема: https://go.vbloher.org/docs/08-distributed-systems/cap-theorem/
- Circuit Breaker: https://go.vbloher.org/docs/08-distributed-systems/circuit-breaker/
- Консенсус и Raft: репликация состояния в присутствии отказов: https://go.vbloher.org/docs/08-distributed-systems/consensus-raft/
- Модели согласованности: https://go.vbloher.org/docs/08-distributed-systems/consistency/
- Гарантии доставки сообщений: at-most-once / at-least-once / exactly-once: https://go.vbloher.org/docs/08-distributed-systems/delivery-guarantees/
- Eventual Consistency: https://go.vbloher.org/docs/08-distributed-systems/eventual-consistency/
- Идемпотентность в распределённых системах: https://go.vbloher.org/docs/08-distributed-systems/idempotency/
- Apache Kafka: https://go.vbloher.org/docs/08-distributed-systems/kafka/
- Transactional Outbox: https://go.vbloher.org/docs/08-distributed-systems/outbox/
- RabbitMQ: AMQP 0-9-1, маршрутизация, надёжность доставки и сравнение с Kafka: https://go.vbloher.org/docs/08-distributed-systems/rabbitmq/
- Ретраи: backoff, jitter, budgets и идемпотентность: https://go.vbloher.org/docs/08-distributed-systems/retries/
- Saga Pattern: https://go.vbloher.org/docs/08-distributed-systems/saga/
- Observability: https://go.vbloher.org/docs/09-observability/
- Grafana: https://go.vbloher.org/docs/09-observability/grafana/
- Метрики: RED, USE, Golden Signals: https://go.vbloher.org/docs/09-observability/metrics/
- OpenTelemetry: https://go.vbloher.org/docs/09-observability/opentelemetry/
- Prometheus: https://go.vbloher.org/docs/09-observability/prometheus/
- SLI / SLO / SLA: https://go.vbloher.org/docs/09-observability/slo-sli/
- Структурированное логирование (slog): https://go.vbloher.org/docs/09-observability/structured-logging/
- Distributed Tracing: https://go.vbloher.org/docs/09-observability/tracing/
- System Design: https://go.vbloher.org/docs/10-system-design/
- Analytics Pipeline: https://go.vbloher.org/docs/10-system-design/analytics-pipeline/
- Chat System: https://go.vbloher.org/docs/10-system-design/chat/
- Фреймворк System Design интервью: https://go.vbloher.org/docs/10-system-design/framework/
- Notification Service: https://go.vbloher.org/docs/10-system-design/notification-service/
- Order Service: https://go.vbloher.org/docs/10-system-design/order-service/
- Payment Service: https://go.vbloher.org/docs/10-system-design/payment-service/
- Rate Limiter: https://go.vbloher.org/docs/10-system-design/rate-limiter/
- URL Shortener: https://go.vbloher.org/docs/10-system-design/url-shortener/
- DevOps: https://go.vbloher.org/docs/11-devops/
- CI/CD: пайплайны, стадии, стратегии деплоя: https://go.vbloher.org/docs/11-devops/cicd/
- Облака (AWS / GCP) для бэкендера: https://go.vbloher.org/docs/11-devops/cloud-aws-gcp/
- Docker для Go-разработчика: https://go.vbloher.org/docs/11-devops/docker/
- GitHub Actions и GitLab CI: https://go.vbloher.org/docs/11-devops/github-gitlab-ci/
- Kubernetes для Go-разработчика: https://go.vbloher.org/docs/11-devops/kubernetes/
- Terraform / Infrastructure as Code: https://go.vbloher.org/docs/11-devops/terraform/
- Алгоритмы: https://go.vbloher.org/docs/12-algorithms/
- Типовые алгоритмические задачи и паттерны: https://go.vbloher.org/docs/12-algorithms/common-problems/
- Асимптотическая сложность (Big-O): https://go.vbloher.org/docs/12-algorithms/complexity/
- Структуры данных в Go: https://go.vbloher.org/docs/12-algorithms/data-structures/
- Специфика live-coding на Go: https://go.vbloher.org/docs/12-algorithms/go-specifics/
- Behavioral: https://go.vbloher.org/docs/13-behavioral/
- Конфликты, разногласия и работа со стейкхолдерами: https://go.vbloher.org/docs/13-behavioral/conflicts/
- Как проходит senior-интервью: этапы, оценка, оффер: https://go.vbloher.org/docs/13-behavioral/interview-flow/
- Лидерство и менторство: https://go.vbloher.org/docs/13-behavioral/leadership-mentoring/
- Типовые поведенческие вопросы для Senior: https://go.vbloher.org/docs/13-behavioral/senior-questions/


> Модуль: Core Go · Уровень: Senior

## TL;DR
`defer` откладывает вызов функции до момента выхода из окружающей функции (return, паника или нормальное завершение). Аргументы отложенного вызова вычисляются **в момент выполнения оператора `defer`**, а сам вызов — позже, в порядке **LIFO**. Отложенные функции могут читать и модифицировать **именованные возвращаемые значения**, что лежит в основе паттерна `recover`. С Go 1.14 для статически известного и небольшого (≤8) числа defer без циклов компилятор применяет **open-coded defer** — почти нулевые накладные расходы; иначе используется `_defer`-запись в runtime.

## Теория

### Что такое defer и когда он выполняется
`defer F(args)` регистрирует вызов `F` с заранее вычисленными `args`. Вызов произойдёт при выходе из функции, в которой написан `defer`, причём ровно в трёх случаях:

1. Достижение `return` (включая «голый» return).
2. Достижение конца тела функции.
3. Раскрутка стека из-за паники (`panic`), проходящей через эту функцию.

Важно: defer привязан к **функции**, а не к лексическому блоку (`{}`) или итерации цикла. Это ключевой источник ошибок (см. утечки в циклах).

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

```go
func main() {
    i := 0
    defer fmt.Println("deferred:", i) // i скопировано прямо сейчас -> 0
    i = 42
    fmt.Println("normal:", i)         // 42
}
// normal: 42
// deferred: 0
```

То же касается получателя метода (receiver) и значения функции-выражения: они «снимаются» в момент `defer`.

```go
type T struct{ v int }
func (t T) Show() { fmt.Println(t.v) }

func f() {
    t := T{v: 1}
    defer t.Show() // копия t (v=1) зафиксирована сейчас
    t.v = 2
}
// печатает 1, потому что receiver-копия снята в момент defer
```

Если же нужен «поздний» снимок состояния — оборачивают в замыкание без аргументов (см. ниже про замыкания vs аргументы).

### Порядок LIFO
Отложенные вызовы складываются в стек и исполняются в обратном порядке регистрации.

```go
func f() {
    for i := 0; i < 3; i++ {
        defer fmt.Print(i, " ")
    }
}
// 2 1 0
```

Это естественно для парных захват/освобождение ресурсов: первым захватили — последним освободим (mutex.Lock/Unlock, открытие/закрытие, начало/завершение трейсинга).

### defer в цикле: накопление и классическая утечка
Поскольку defer привязан к функции, а не к итерации, в длинном цикле отложенные вызовы **накапливаются** и не выполняются до выхода из функции. Самый частый баг — отложенный `Close` в цикле:

```go
// ПЛОХО: файлы и дескрипторы не закрываются до конца readAll
func readAll(paths []string) error {
    for _, p := range paths {
        f, err := os.Open(p)
        if err != nil {
            return err
        }
        defer f.Close() // накапливается! при тысячах файлов -> исчерпание FD
        // ... работа с f
    }
    return nil
}
```

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

```go
func readAll(paths []string) error {
    for _, p := range paths {
        if err := func() error {
            f, err := os.Open(p)
            if err != nil {
                return err
            }
            defer f.Close() // закроется в конце КАЖДОЙ итерации
            // ... работа с f
            return nil
        }(); err != nil {
            return err
        }
    }
    return nil
}
```

Дополнительный нюанс: накопление defer в цикле также **отключает open-coded оптимизацию** (см. ниже) — defer в цикле всегда тяжелее.

### Изменение именованных возвращаемых значений из defer
Если функция объявляет именованные возвращаемые значения, отложенная функция видит их как обычные переменные и может изменять — изменения отразятся на фактически возвращаемом значении. Это работает потому, что `return x` компилируется в «присвоить именованным результатам, затем выполнить defer'ы, затем фактически вернуть».

```go
func inc() (result int) {
    defer func() { result++ }()
    return 5 // result = 5, затем defer делает result = 6
}
// возвращает 6
```

Сравните с анонимными результатами — там defer не имеет доступа к возвращаемому значению и может влиять лишь через побочные эффекты:

```go
func inc2() int {
    result := 5
    defer func() { result++ }() // меняет локальную переменную, не возврат
    return result               // вернёт 5
}
```

Главное практическое применение — оборачивание ошибок и восстановление после паники:

```go
func do() (err error) {
    defer func() {
        if r := recover(); r != nil {
            err = fmt.Errorf("recovered: %v", r)
        }
    }()
    defer func() {
        if err != nil {
            err = fmt.Errorf("do failed: %w", err)
        }
    }()
    // ...
    return nil
}
```

### defer + recover и паника
`recover` имеет смысл **только** внутри отложенной функции. Вне defer он возвращает `nil`. Когда возникает паника, runtime начинает раскрутку стека, по дороге выполняя зарегистрированные defer'ы; если какой-то из них вызывает `recover`, паника гасится, и функция, чей defer восстановил выполнение, возвращается нормально (со значениями именованных результатов, какими они стали).

```go
func safeDiv(a, b int) (q int, err error) {
    defer func() {
        if r := recover(); r != nil {
            err = fmt.Errorf("panic: %v", r)
        }
    }()
    return a / b, nil // при b==0 паника -> recover -> err установлен
}
```

Тонкости:
- `recover()` должен быть вызван **непосредственно** отложенной функцией, а не функцией, которую она вызывает. `defer helper()` где `helper` внутри зовёт `recover()` — не сработает (в Go это вызов на «глубину 1»; runtime проверяет, что recover вызван прямо из defer'нутого фрейма).
- Если в defer происходит новая паника, она заменяет текущую (в трейсе остаётся след предыдущей).
- defer'ы выполняются даже при панике — поэтому `mutex.Unlock`, закрытие соединений и т. п. в defer безопасны при панике.

### Стоимость defer и эволюция реализации
Под капотом отложенный вызов в общем случае представляется структурой `runtime._defer` (в `runtime/runtime2.go`), которая хранит указатель на функцию, размер аргументов, указатель на стек/SP, ссылку на следующий `_defer` в связанном списке горутины (`g._defer`) и др. поля. Эволюция:

| Версия | Реализация | Характеристика |
|---|---|---|
| до Go 1.13 | **heap-allocated defer** | каждый `defer` аллоцировал `_defer` в куче (через `deferproc`), вызывался `deferreturn`; дорого, давило на GC |
| Go 1.13 | **stack-allocated defer** | `_defer` размещается на стеке (если не «убегает»); ~30% быстрее, меньше нагрузка на кучу, но всё ещё через список и `deferproc`/`deferreturn` |
| Go 1.14 | **open-coded defer** | компилятор инлайнит отложенные вызовы прямо в код функции; накладные расходы близки к прямому вызову — defer перестал быть «дорогим» |

#### Как работает open-coded defer
Компилятор применяет open-coding, когда выполнены условия:
- число операторов `defer` в функции **статически известно и ≤ 8**;
- `defer`'ы **не находятся в цикле** (число срабатываний ограничено и известно);
- функция не слишком «осложнена» (есть пороги по числу defer × выходов).

При open-coding компилятор:
1. Не создаёт `_defer`-записи в общем пути; вместо этого вычисляет аргументы и сохраняет их в локальных переменных стека.
2. Заводит **defer bit mask** (битовую маску) — по биту на каждый defer, выставляемую в момент исполнения соответствующего `defer`. Это нужно, потому что не каждый defer гарантированно выполнится (например, ранний return до второго `defer`).
3. На каждом пути выхода вставляет инлайн-код, который по маске вызывает нужные отложенные функции в порядке LIFO.
4. Для пути паники компилятор генерирует **`deferreturn`-подобный** хвост и регистрирует информацию через `funcdata`/`stackmap`, чтобы runtime в `gopanic` мог найти и выполнить open-coded defer'ы при раскрутке стека (механизм с фреймовым «открытым» defer и `_defer{openDefer: true}`).

Практический вывод: «defer медленный» — устаревшее знание. Сегодня в горячем пути дорогим становится defer только если он **в цикле** или их **> 8** (откат к heap/stack `_defer` через `deferproc`), либо если функция вызывает `recover` так, что компилятор вынужден откатиться к классической схеме.

### defer с замыканиями vs с аргументами
Два способа передать данные в отложенный вызов дают разную семантику снимка состояния:

```go
// Аргументы: значение фиксируется в момент defer
defer fmt.Println(x) // печатает x КАКИМ ОНО БЫЛО на строке defer

// Замыкание без аргументов: значение читается в момент ВЫПОЛНЕНИЯ
defer func() { fmt.Println(x) }() // печатает АКТУАЛЬНОЕ x на выходе из функции
```

```go
func demo() {
    x := 1
    defer fmt.Println("arg:", x)            // arg: 1
    defer func() { fmt.Println("clo:", x) }() // clo: 3
    x = 2
    x = 3
}
// LIFO: clo: 3, затем arg: 1
```

Производительность: замыкание захватывает переменные, что может вынудить их «убежать» в кучу (escape analysis). Передача аргументами иногда дешевле и яснее по семантике (поздний снимок не нужен). Выбор: нужен снимок «сейчас» — аргументы; нужно «актуальное на выходе» (типично для `err`, метрик длительности) — замыкание.

## Подводные камни / gotchas

- **Аргументы вычисляются сразу.** `defer log(time.Since(start))` зафиксирует длительность ≈ 0. Нужно `defer func(){ log(time.Since(start)) }()`.
- **defer в длинном цикле = утечка/накопление.** Дескрипторы, мьютексы, память живут до конца функции. Лечится выносом тела в функцию/замыкание.
- **defer внутри `if`/`for`/блока всё равно срабатывает на выходе из функции**, а не из блока — defer не блочный.
- **`recover` вне отложенной функции бесполезен** (вернёт nil), и не сработает, если вызван не напрямую из defer'нутого фрейма.
- **Анонимные результаты не меняются из defer.** Чтобы defer влиял на возврат — объявите именованные результаты.
- **defer на `nil`-функции/значении** паникует при выполнении, а не при регистрации.
- **`defer rows.Close()` без проверки ошибок** маскирует ошибки закрытия; для записи (Close файла, в который писали) ошибку нужно ловить: `defer func(){ if cerr := f.Close(); cerr != nil && err == nil { err = cerr } }()`.
- **defer + горутины:** defer в `go func(){...}()` относится к этой горутине, а не к породившей функции.
- **`os.Exit` не выполняет defer'ы.** И `log.Fatal` (вызывает `os.Exit`) тоже — отложенные Close не отработают.
- **defer добавляет фрейм при панике-трейсе и слегка усложняет инлайнинг** функции (исторически функции с defer плохо инлайнились; современный компилятор это улучшил, но эффект остаётся).

## Вопросы на собеседовании

**В:** Когда вычисляются аргументы отложенной функции?
**О:** В момент исполнения оператора `defer`, а не в момент фактического вызова. Значения аргументов, receiver метода и само значение функции копируются сразу и сохраняются (на стеке/в `_defer`). Поэтому `defer f(x)` зафиксирует текущее `x`. Чтобы отложить чтение до выхода, нужно замыкание без аргументов: `defer func(){ f(x) }()`.

**В:** В каком порядке выполняются несколько defer?
**О:** LIFO — последний зарегистрированный выполняется первым. Реализуется как стек/связанный список `_defer` в `g._defer`, куда новые записи добавляются в голову. Это удобно для парных операций lock/unlock, open/close.

**В:** Как изменить возвращаемое значение из defer?
**О:** Объявить именованные возвращаемые значения. `return x` присваивает их, затем выполняются defer'ы, которые видят и могут менять эти именованные переменные; изменённое значение и будет возвращено. С анонимными результатами это невозможно — defer влияет только через внешние побочные эффекты.

**В:** Почему defer в цикле часто приводит к багу и как чинить?
**О:** defer привязан к функции, не к итерации, поэтому в цикле вызовы накапливаются и не срабатывают до выхода из функции — типично это незакрытые файлы/соединения (исчерпание дескрипторов). Решение — обернуть тело итерации в функцию/замыкание, тогда defer отработает на каждой итерации. Бонус: defer в цикле ещё и отключает open-coded оптимизацию.

**В:** Дорог ли defer? Как менялась его стоимость?
**О:** До Go 1.13 — heap-allocation `_defer` (дорого, нагрузка на GC). В 1.13 — stack-allocation (~30% быстрее). В 1.14 — open-coded defer: компилятор инлайнит отложенные вызовы при статически известном числе ≤8 и отсутствии циклов, стоимость близка к прямому вызову. Сегодня defer «дорог» только в цикле, при >8 defer или когда компилятор откатывается к классической схеме.

**В:** Что такое open-coded defer и какие условия его включают?
**О:** Это компиляторная оптимизация, при которой вместо `_defer`-записей в runtime код отложенных вызовов вставляется напрямую в каждый путь выхода функции, а управление — через стековые переменные с аргументами и битовую маску (какие defer успели зарегистрироваться). Условия: число defer статически известно и ≤8, defer не в цикле, функция не превышает порогов сложности. Для пути паники компилятор регистрирует `funcdata`, чтобы `gopanic` нашёл и выполнил эти defer'ы при раскрутке.

**В:** Где должен находиться вызов `recover`, чтобы он сработал?
**О:** Непосредственно внутри отложенной функции текущего фрейма. `recover()` в обычном коде или внутри функции, вызванной из defer (на ещё одну глубину), вернёт nil и не погасит панику. Runtime проверяет, что recover вызывается прямо из фрейма, чей defer сейчас исполняется во время паники.

**В:** В чём разница между `defer f(x)` и `defer func(){ f(x) }()`?
**О:** Первый снимает `x` в момент `defer` (ранний снимок), второй читает `x` в момент выполнения (актуальное значение на выходе). Замыкание также может захватывать и менять именованные результаты/ошибки. Минус замыкания — возможный escape переменных в кучу и чуть большие накладные расходы.

**В:** Выполняются ли defer при панике и при `os.Exit`?
**О:** При панике — да: runtime раскручивает стек, исполняя defer'ы (что и даёт шанс recover и корректному освобождению ресурсов). При `os.Exit` (и `log.Fatal`) — нет: процесс завершается немедленно, defer'ы пропускаются.

## На что копают на senior+

- **Точная семантика `return` + defer + named results.** Senior должен описать, что `return x` это не атомарная операция: присваивание результатов → выполнение defer'ов → реальный возврат. Follow-up: почему `defer func(){ recover() }()` восстанавливает функцию именно с текущими значениями именованных результатов.
- **Внутреннее устройство `_defer` и `g._defer`.** Ожидают, что кандидат назовёт связанный список defer'ов на горутине, поля (fn, sp/pc, link, openDefer/heap-флаги), и разницу путей `deferproc`/`deferreturn` против open-coded.
- **Когда оптимизация откатывается.** Глубокое понимание: defer в цикле, >8 defer, defer в горячем пути с recover — что именно заставляет компилятор вернуться к stack/heap `_defer`. Умение это проверить (`go build -gcflags=-d=defer`, анализ через бенчмарки/`go tool objdump`).
- **Escape analysis и замыкания в defer.** Понимание, что захват переменных замыканием может вызвать их размещение в куче, и как это видно в `-gcflags=-m`.
- **Корректная обработка ошибок Close.** Особенно для writable-ресурсов: senior проверяет ошибку `Close` и аккуратно пробрасывает её в именованный `err`, не затирая основную ошибку.
- **Поведение recover на «глубине».** Follow-up «почему вынесенный helper с recover не работает» отделяет тех, кто знает правило «recover только напрямую из defer'нутого фрейма».
- **Влияние на инлайнинг и трейсы паник.** Senior знает исторические ограничения инлайнинга функций с defer и как defer-фреймы выглядят в стеке паники.
- **Альтернативы defer в сверхгорячем пути.** Когда ради производительности (например, в аллокаторах, парсерах) defer сознательно заменяют ручным освобождением — и как обосновать это бенчмарками, а не догадками.