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/


> Модуль: Runtime и память · Уровень: Senior+

## TL;DR
Escape analysis — это анализ компилятора, определяющий, переживёт ли значение функцию, в которой оно создано. Если переживёт (или компилятор не может доказать обратное), значение размещается в куче; иначе — на стеке. Анализ консервативен: при неопределённости выбирается куча. Смотреть решения можно через `go build -gcflags="-m"` (или `-m -m` для подробностей). Типовые причины escape: возврат указателя, попадание значения в интерфейс, замыкания, захватывающие переменную по ссылке, слишком большой объект, отправка указателя в канал, передача в `fmt.Println` (через `any`).

## Теория

### Зачем нужен escape analysis

Цель — максимально много разместить на стеке, потому что стек дешёв и не нагружает GC. Анализ строит граф «потока» значений и адресов: куда утекает адрес переменной. Если адрес «вытекает» за границу функции (returns, globals, heap, interface, channel), переменная **escapes to heap**.

Принцип консервативности: компилятор **обязан** отправить в кучу всё, в безопасности чего на стеке он не уверен. Ложно-положительные escape (лишние аллокации) допустимы; ложно-отрицательные (use-after-free) — недопустимы.

### Как смотреть

```bash
# базовый отчёт о решениях
go build -gcflags="-m" ./...

# подробнее: ПОЧЕМУ принято решение (цепочки)
go build -gcflags="-m -m" ./...

# заодно показать решения по инлайнингу
go build -gcflags="-m -m" ./... 2>&1 | grep -E "escapes|inlin|leaking|moved"
```

Пример:

```go
package demo

func newInt() *int {
    x := 0      // ./demo.go:4:2: moved to heap: x
    return &x   // &x убегает через return
}

func localOnly() int {
    y := 42     // остаётся на стеке — адрес не берётся
    return y
}
```

```bash
$ go build -gcflags="-m" demo.go
./demo.go:4:2: moved to heap: x
```

Сообщения, которые надо уметь читать:

| Сообщение | Что значит |
|---|---|
| `moved to heap: x` | Переменная `x` размещена в куче (escape) |
| `&x escapes to heap` | Адрес `x` утёк, поэтому `x` в куче |
| `x escapes to heap` | Значение убегает (часто через интерфейс) |
| `... argument does not escape` | Параметр не утекает — отлично |
| `leaking param: p` | Параметр `p` утекает (его адрес/содержимое уходит наружу) |
| `leaking param content: p` | Утекает то, на что указывает `p` (одноуровнево) |
| `can inline f` / `inlining call to f` | Функция инлайнится |

### Типовые причины escape

#### 1. Возврат указателя на локальную переменную
```go
func make() *T { t := T{}; return &t } // t moved to heap
```
Классика: адрес переживает функцию.

#### 2. Сохранение в интерфейс / any
```go
func boxed() {
    x := 42
    var i any = x   // x escapes: интерфейс хранит указатель на данные
    _ = i
}
```
Интерфейс — это пара `(type, data ptr)`. Чтобы положить значение в `any`, нужен адрес → значение убегает. Это причина, почему `fmt.Println(x)` часто вызывает escape: сигнатура `Println(a ...any)` боксирует аргументы.

```go
func logIt() {
    n := 1234
    fmt.Println(n) // n escapes to heap (упаковка в any для variadic)
}
```

#### 3. Замыкания, захватывающие по ссылке
```go
func counter() func() int {
    c := 0           // c moved to heap
    return func() int {
        c++          // замыкание держит ссылку на c
        return c
    }
}
```
Если захваченная переменная модифицируется и/или замыкание переживает функцию, переменная едет в кучу (становится частью closure-объекта). Захват только для чтения внутри той же функции может остаться на стеке.

#### 4. Слишком большой объект
```go
func big() {
    var buf [1 << 20]byte // > порога → moved to heap
    _ = buf
}
```
Объекты больше внутреннего лимита (исторически ~64 КБ для стек-объектов) принудительно идут в кучу, чтобы не раздувать фрейм.

#### 5. Slice, растущий через append (неизвестный размер)
```go
func grow(n int) []int {
    s := make([]int, 0)   // если n неизвестен на этапе компиляции →
    for i := 0; i < n; i++ {
        s = append(s, i)  // backing array escapes to heap
    }
    return s
}
```
Если размер `make` не константа или slice возвращается/убегает, backing array идёт в кучу. `make([]int, 16)` с константой и без утечки может остаться на стеке.

#### 6. Отправка указателя в канал
```go
func send(ch chan *T) {
    t := &T{}   // escapes: другая горутина может прочитать после выхода
    ch <- t
}
```
Канал переживает функцию, значит указатель доступен другим горутинам неопределённое время → куча.

#### 7. Сохранение в глобальную переменную / поле, живущее дольше
```go
var sink *int
func leak() { x := 1; sink = &x } // x moved to heap
```

#### 8. Адрес, переданный в функцию, которая «leaks param»
Если вызываемая функция помечена `leaking param`, передача туда адреса локала заставит его убежать. Если же та функция гарантированно не утекает параметр (`does not escape`), вызов безопасен для стека.

### Leaking param: уровни утечки

```go
// leaking param: p   → сам указатель p утекает (например, сохраняется или возвращается)
func keep(p *int) *int { return p }

// leaking param content: p → утекает разыменованное содержимое
func store(p *[]int, v int) { *p = append(*p, v) }

// p does not escape → лучший случай, аргумент остаётся на стороне вызывающего
func read(p *int) int { return *p }
```

Эта аннотация — часть **межпроцедурного** анализа: escape analysis смотрит, как функция обращается с параметрами, и кэширует «escape-сводку» (summary) функции, чтобы вызывающие могли принять решение, не залезая внутрь.

### Связь с инлайнингом

Инлайнинг и escape analysis работают в паре и усиливают друг друга:

```go
func get() *int { x := 0; return &x }   // в отрыве — x escapes

func caller() int {
    p := get()   // если get() заинлайнится, тело раскроется в caller,
    return *p    // и компилятор увидит, что адрес НЕ покидает caller → стек!
}
```

После инлайнинга `get()` его `x` оказывается локальным для `caller`, адрес не убегает наружу — escape устраняется. Поэтому:
- Инлайнинг происходит **до/во взаимодействии** с escape analysis в SSA-конвейере.
- Маленькие функции (бюджет инлайнинга, `budget`) лучше для устранения аллокаций.
- `//go:noinline` может внезапно добавить аллокации, ломая эту оптимизацию.

```bash
# увидеть и инлайнинг, и escape вместе
go build -gcflags="-m -m" ./... 2>&1 | grep -E "inlin|escape|heap"
```

### Оптимизации, помогающие избежать escape

```go
// Плохо: возвращаем указатель → escape
func New() *Config { return &Config{Timeout: 30} }

// Лучше для горячего пути: вернуть значение (копия на стек вызывающего)
func New() Config { return Config{Timeout: 30} }

// Переиспользование буфера вместо аллокации на каждый вызов
var bufPool = sync.Pool{New: func() any { return new([4096]byte) }}

// Передавать []byte и писать в него, а не возвращать новый slice
func Format(dst []byte, x int) []byte { return strconv.AppendInt(dst, int64(x), 10) }
```

Приёмы: возврат значения вместо указателя на горячем пути; `sync.Pool` для переиспользования; `AppendX`-функции вместо аллокации; избегание `any`/`interface{}` в hot loop; предвыделение slice с константной ёмкостью; не передавать в `fmt`/логгер в горячем цикле (или использовать типизированные методы вроде `zap` без рефлексии).

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

- **`-m` показывает решения, а не факт аллокации.** Финальный факт — это `-benchmem` (`allocs/op`) и `pprof`. Всегда подтверждайте бенчмарком.
- **`fmt.Println(x)` боксирует.** Любая передача в `...any` упаковывает аргумент → escape. В горячем коде это ловушка для аллокаций.
- **Замыкание ≠ всегда escape.** Захват по чтению, не переживающий функцию (например, в `for ... { go ... }` без выхода), может остаться на стеке; модификация или переживание функции — escape.
- **`make` без константного размера → куча.** `make([]int, n)` с переменным `n` почти всегда escape, даже если slice локальный.
- **Возврат интерфейса прячет escape.** `func() error { return &myErr{} }` — указатель в интерфейсе убегает, причём это часто незаметно.
- **`//go:noinline` и границы пакета мешают анализу.** Escape analysis межпроцедурный, но опирается на summary; вызовы через интерфейс (динамическая диспетчеризация) и `noinline` ухудшают вывод и провоцируют consервативный escape.
- **Указатель на элемент slice/map.** Взятие адреса элемента может заставить весь backing array убежать.
- **`new(T)` сам по себе не значит куча.** `new` лишь даёт zero-value и адрес; если адрес не убегает, объект на стеке.

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

**В:** Что такое escape analysis и почему он консервативен?
**О:** Это статический анализ компилятора, определяющий, переживёт ли значение свою функцию. Если адрес значения утекает наружу (return, глобал, интерфейс, канал, замыкание), значение размещается в куче. Консервативность означает: при невозможности доказать безопасность стека выбирается куча. Лишняя аллокация — приемлемая цена; use-after-free — нет.

**В:** Почему `var i any = x` вызывает escape переменной `x`?
**О:** Интерфейсное значение — это пара (тип, указатель на данные). Чтобы положить `x` в `any`, нужно хранить указатель на его данные, а время жизни интерфейса компилятору неизвестно. Поэтому `x` перемещается в кучу. Это же объясняет, почему `fmt.Println(x)` (сигнатура `...any`) часто аллоцирует.

**В:** Как инлайнинг влияет на escape analysis? Приведите пример.
**О:** Инлайнинг раскрывает тело вызываемой функции в месте вызова, после чего её локальные переменные становятся локальными для вызывающего. Если в отрыве функция «возвращала указатель» (escape), то после инлайнинга компилятор может увидеть, что адрес не покидает вызывающего, и оставить значение на стеке. Поэтому маленькие инлайнируемые функции дают меньше аллокаций, а `//go:noinline` может их добавить.

**В:** Что означают `leaking param`, `leaking param content` и `does not escape`?
**О:** `does not escape` — параметр не утекает, аргумент может остаться на стеке вызывающего (лучший случай). `leaking param: p` — сам параметр-указатель утекает (сохраняется/возвращается). `leaking param content: p` — утекает то, на что указывает `p` (одноуровнево). Эти сводки — основа межпроцедурного анализа.

**В:** Почему `make([]int, n)` с переменным `n` почти всегда уходит в кучу, а `make([]int, 16)` — нет?
**О:** При константном размере и отсутствии утечки компилятор знает точный размер фрейма и может разместить backing array на стеке. При неизвестном на этапе компиляции `n` размер фрейма неопределён, и безопасно разместить можно только в куче. Также если slice возвращается/убегает — всегда куча.

**В:** Как достоверно проверить, что код не аллоцирует?
**О:** `go build -gcflags="-m"` показывает решения компилятора, но окончательное подтверждение — бенчмарк с `-benchmem` и метрикой `allocs/op`, плюс `testing.AllocsPerRun` или профиль `-memprofile`/pprof. Флаги дают намерение, бенчмарк — факт.

**В:** Замыкание всегда вызывает escape захваченных переменных?
**О:** Нет. Если замыкание не переживает функцию и переменная захвачена так, что компилятор доказывает её локальность, она может остаться на стеке. Escape наступает, когда замыкание возвращается/сохраняется или переживает создающую функцию, либо переменная модифицируется и разделяется — тогда она становится частью closure-объекта в куче.

**В:** Назовите способы уменьшить аллокации в горячем коде.
**О:** Возвращать значения вместо указателей; избегать боксинга в `any`/`interface{}` (не использовать `fmt` в hot loop); `sync.Pool` для переиспользования буферов; `AppendX`-API вместо новых slice; предвыделять slice/map с известной ёмкостью; держать функции маленькими для инлайнинга; избегать ненужного взятия адреса элементов slice/map; типизированные логгеры без рефлексии.

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

- Чтение `-m -m`: умение проследить цепочку «почему именно escape» (`flow:`, `from ... (...)`), а не просто констатировать факт.
- Внутренняя модель: escape analysis как анализ на SSA с построением графа location/flow, escape summary функций, fixed-point итерация.
- Граница с GC: понимание, что меньше escape → меньше работа GC → ниже GC CPU и паузы; связь с `GOGC`/`GOMEMLIMIT`.
- Динамическая диспетчеризация: почему вызовы через интерфейс и рефлексия ухудшают анализ (нет статической цели → консервативный escape), и как девиртуализация/`-d=ssa` помогает.
- Практика: `testing.AllocsPerRun`, `-benchmem`, профиль `alloc_space`/`inuse_space`, чтение `pprof -alloc_objects`, поиск «горячих» аллокаций.
- Тонкости: порог размера для stack-объектов, поведение `sync.Pool` под GC (очистка пула на каждом цикле GC), почему `Pool` не панацея и иногда хуже простого стека.
- Самостоятельная проверка гипотезы: построить минимальный пример, прогнать `-gcflags="-m -m"` + бенчмарк, объяснить расхождение между намерением компилятора и фактическими `allocs/op`.