Код

func f1() (result int) {          // именованный результат
    defer func() { result *= 2 }()
    return 5
}

func f2() int {                   // анонимный результат
    result := 5
    defer func() { result *= 2 }()
    return result
}

func f3() (result int, err error) {
    defer func() {
        if r := recover(); r != nil {
            err = fmt.Errorf("recovered: %v", r)
            result = -1
        }
    }()
    panic("boom")
}

func f4() (n int) {
    defer func() { n++ }()
    defer func() { n *= 10 }()
    return 1
}

func main() {
    fmt.Println(f1())
    fmt.Println(f2())
    fmt.Println(f3())
    fmt.Println(f4())
}

Почему: что на самом деле делает return

return X в Go распадается на три операции, строго в этом порядке:

1. присвоить X переменной-результату;
2. выполнить отложенные вызовы в порядке LIFO;
3. фактически вернуть управление, отдав то, что лежит в переменной-результате сейчас.

Вся разница между f1 и f2 сводится к одному: существует ли эта переменная как именованная. В f1 результат назван result, и defer модифицирует ровно ту ячейку, из которой на шаге 3 будет взято значение: result = 5 → result *= 2 → вернули 10.

В f2 результат анонимен. return result копирует значение локальной переменной result в невидимый слот результата, и defer, изменяя локальную result, к этому слоту уже никак не относится. Функция возвращает 5, а result становится 10 в никуда.

f3 применяет ту же механику на практике и остаётся единственным способом вернуть ошибку из recover. Без именованных результатов перехваченная паника не превращается в error: писать некуда.

f4 проверяет порядок: отложенные вызовы выполняются LIFO, поэтому сначала n *= 10 (1 → 10), затем n++ (10 → 11). Порядок объявления обратен порядку выполнения.

Как звучит правильное объяснение на собесе

«return сначала присваивает результату, потом идёт defer, потом собственно возврат. Если результат именованный, defer видит ту же переменную и может её поменять, поэтому f1 вернёт 10. Если анонимный, значение уже скопировано, и defer меняет локальную переменную впустую, так что f2 вернёт 5. На этом же механизме держится превращение паники в ошибку через recover, и на нём же стоит правильный defer Close(), который не теряет ошибку закрытия.»

Код

type T struct {
    n int
}

func (t T) Show()   { fmt.Println("Show (значение):", t.n) }
func (t *T) ShowP() { fmt.Println("ShowP (указатель):", t.n) }

func main() {
    i := 0
    defer fmt.Println("A defer со значением:", i)
    defer func() { fmt.Println("B defer с замыканием:", i) }()

    t := T{n: 1}
    defer t.Show()      // получатель-значение
    defer t.ShowP()     // получатель-указатель

    i = 3
    t.n = 2
    fmt.Println("конец main:", i, t.n)
}

Почему

Правило одно, но у него четыре следствия: defer вычисляет функцию и все её аргументы немедленно, а вызывает при выходе.

• A. i стоит аргументом fmt.Println, поэтому вычислен и скопирован в момент defer, когда i был равен 0. Последующее i = 3 ни на что не влияет.
• B. Аргументов у func(){...}() нет вообще. Тело работает как замыкание, захватывает переменную i, а не её значение, и читает её при выполнении: 3.
• t.Show(). Получатель тоже считается аргументом, просто неявным. Метод объявлен на значении, поэтому t копируется в момент defer: копия помнит n = 1.
• t.ShowP(). Метод на указателе, значит вычисляется и копируется &t, то есть сам указатель, а не то, на что он смотрит. Через него виден актуальный n = 2.

Порядок вывода подчиняется LIFO: последний объявленный defer выполняется первым.

Как звучит правильное объяснение на собесе

«defer значит "запомнить вызов и его аргументы сейчас, выполнить потом". Аргументы, включая получателя метода, копируются в момент объявления. Поэтому defer f(x) замораживает x, а defer func(){ f(x) }() не замораживает: замыкание держит саму переменную. Если метод на значении, заморозится копия структуры; если на указателе, заморозится указатель, и изменения будут видны. Выполняются в порядке LIFO.»

Код

func main() {
    for i := 0; i < 3; i++ {
        defer fmt.Println("defer", i)
    }
    fmt.Println("конец цикла")

    for i := 0; i < 3; i++ {
        func() {
            defer fmt.Println("вложенный defer", i)
        }()
    }
    fmt.Println("конец main")
}

Почему

defer привязан к функции, а не к блоку. Ни фигурные скобки цикла, ни if, ни switch не создают точку выполнения отложенных вызовов; её создаёт только возврат из функции (или паника). Поэтому три defer из первого цикла копятся в списке текущей функции и разряжаются в самом конце main, в порядке LIFO.

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

// Открывает 10 000 файлов и НИ ОДНОГО не закрывает до конца функции.
for _, name := range names {
    f, err := os.Open(name)
    if err != nil {
        return err
    }
    defer f.Close()          // ← накопится 10 000 отложенных Close
    process(f)
}

Отдельно про производительность: с Go 1.14 defer в большинстве случаев инлайнится и стоит порядка одной-двух наносекунд. Это уже не тот дорогой defer, о котором писали в 2017-м. Но defer в цикле остаётся дорогим по другой причине: он не выполняется, а накапливается в списке, то есть расходует память пропорционально числу итераций.

Как звучит правильное объяснение на собесе

«defer относится к функции, а не к блоку, поэтому в цикле он не выполняется на каждой итерации, а копится и разряжается в конце функции в порядке LIFO. Для ресурсов внутри цикла это утечка дескрипторов, поэтому тело итерации заворачивают в анонимную функцию, чтобы у каждой итерации была своя точка выхода. В main из примера сначала отработают все вложенные defer по ходу второго цикла, а три "цикловых" сработают только после конец main, в обратном порядке.»

Код

func main() {
    var wg sync.WaitGroup
    for i := 0; i < 3; i++ {
        wg.Add(1)
        go func() { defer wg.Done(); fmt.Print(i, " ") }()
    }
    wg.Wait()
    fmt.Println()

    var fns []func()
    for _, s := range []string{"a", "b", "c"} {
        fns = append(fns, func() { fmt.Print(s, " ") })
    }
    for _, f := range fns {
        f()
    }
    fmt.Println()

    ptrs := []*int{}
    for i := 0; i < 3; i++ {
        ptrs = append(ptrs, &i)
    }
    for _, p := range ptrs {
        fmt.Print(*p, " ")
    }
    fmt.Println()
}

Почему: что именно изменили в Go 1.22

До Go 1.22 переменная цикла объявлялась один раз на весь цикл и переиспользовалась на каждой итерации. Замыкание захватывает переменную, а не её значение, поэтому все три горутины ссылались на одну и ту же ячейку памяти. К моменту их запуска цикл обычно уже завершался, и в ячейке лежало финальное значение, 3 для счётчика и "c" для range. Отсюда и &i: три указателя на одну ячейку.

Начиная с Go 1.22 переменная цикла объявляется заново на каждой итерации: формально компилятор создаёт новую переменную и копирует в неё значение перед телом итерации. Каждое замыкание получает свою ячейку, и задача перестаёт быть задачей.

Деталь про версию. Поведение определяется не версией установленного компилятора, а строкой go 1.xx в go.mod модуля. Собранный Go 1.27 модуль с go 1.21 получит старую семантику. Именно поэтому вопрос всё ещё живой: легаси-модулей с go 1.19 вокруг очень много, а миграция сводится к правке одной строки, которую боятся трогать ровно из-за этого изменения.

Как писали до 1.22 - и почему это до сих пор встречается

// Способ 1: параметр функции, значение копируется при вызове go.
for i := 0; i < 3; i++ {
    go func(i int) { fmt.Print(i, " ") }(i)
}

// Способ 2: затенение, новая переменная на итерацию вручную.
for i := 0; i < 3; i++ {
    i := i                    // да, это легально и было идиомой
    go func() { fmt.Print(i, " ") }()
}
// Оба способа под go 1.21 в go.mod печатают 0, 1 и 2, но в произвольном порядке.
// Шесть прогонов подряд дали: 2 0 1 / 2 1 0 / 2 1 0 / 2 1 0 / 2 1 0 / 2 0 1.
// (В самом фрагменте нет wg.Wait, так что для проверки его надо дописать,
//  иначе main завершится раньше, чем горутины успеют напечатать хоть что-то.)

Оба приёма продолжают работать и на 1.22+, просто перестали быть обязательными. В новом коде строка i := i теперь избыточна, и линтеры (copyloopvar) на неё ругаются.

Как звучит правильное объяснение на собесе

«Замыкание захватывает переменную, а не значение. До Go 1.22 переменная цикла была одна на весь цикл, поэтому все горутины видели её финальное значение, отсюда 3 3 3. С Go 1.22 на каждой итерации создаётся своя переменная, и выведется 0, 1, 2, но в произвольном порядке, потому что порядок выполнения горутин не гарантирован. Семантику задаёт строка go в go.mod, а не версия компилятора, так что в старом модуле, собранном новым Go, поведение останется старым.»

Код

func main() {
    a := []int{1, 2, 3, 4, 5}
    b := a[1:3]
    fmt.Println(len(b), cap(b))

    b = append(b, 99)
    fmt.Println(a)
    fmt.Println(b)
}

Почему

Слайс устроен как заголовок из трёх полей: {ptr, len, cap}. Операция a[1:3] не копирует данные, она делает новый заголовок на тот же массив: указатель сдвигается на элемент 1, длина становится 2, а ёмкость считается до конца массива: cap(b) = cap(a) - 1 = 4. Именно эта «лишняя» ёмкость и есть корень проблемы.

append(b, 99) видит len(b) < cap(b) и понимает, что место есть, а новый массив выделять не нужно. Он записывает 99 в следующую свободную ячейку того же массива, а это физически a[3]. Значение 4 уничтожено. Возвращается заголовок с len = 3, указывающий туда же.

Где это встречается в реальном коде

// Популярный приём «отфильтровать без аллокации» легко превращается в баг,
// если вызывающий продолжает пользоваться исходным слайсом.
func filterInPlace(s []int, keep func(int) bool) []int {
    out := s[:0]                 // тот же массив, len 0, cap полный
    for _, v := range s {
        if keep(v) {
            out = append(out, v) // пишем поверх s
        }
    }
    return out
}

a := []int{1, 2, 3, 4, 5}
b := filterInPlace(a, func(v int) bool { return v%2 == 0 })
// b = [2 4], но a = [2 4 3 4 5] - исходный слайс изуродован

Как звучит правильное объяснение на собесе

«Срез не копирует данные, он делает новый заголовок на тот же массив, и cap считается до конца массива, а не до конца среза. У b получилось len 2, cap 4, поэтому append нашёл свободное место в том же массиве и записал 99 в ячейку, которая для a служит четвёртым элементом. Если нужно гарантировать независимость, надо либо явно копировать через slices.Clone, либо ограничить ёмкость трёхиндексным срезом a[1:3:3].»

Код

func main() {
    x := make([]int, 3, 4)        // len 3, cap 4, есть одна свободная ячейка
    copy(x, []int{1, 2, 3})

    y := append(x, 4)
    z := append(x, 5)
    fmt.Println(x, y, z)

    p := []int{1, 2, 3}           // len 3, cap 3, свободных ячеек нет
    q := append(p, 4)
    q[0] = 99
    fmt.Println(p, q)
}

Почему

Это самая коварная пара примеров во всей теме, потому что они выглядят одинаково, а ведут себя противоположно. Разница ровно одна: хватило ли ёмкости.

Первый случай. При cap(x) = 4 и len(x) = 3 свободная ячейка есть. append(x, 4) записывает 4 в array[3] и возвращает заголовок {ptr, 4, 4}. Затем append(x, 5) смотрит на тот же x, у которого по-прежнему len 3, и записывает 5 в ту же array[3], затирая четвёрку. Теперь y и z держат два заголовка на один массив, и оба показывают [1 2 3 5]. Сам x остаётся [1 2 3], потому что его len никто не менял: append не модифицирует исходный заголовок, он возвращает новый.

Второй случай. cap(p) = 3, места нет. append выделяет новый массив (обычно вдвое больше), копирует туда три элемента, дописывает четвёртый. Слайс q смотрит на новую память, поэтому q[0] = 99 никак не задевает p.

Как растёт ёмкость

Точные коэффициенты остаются деталью реализации и менялись между версиями, но модель такая: для маленьких слайсов ёмкость примерно удваивается, а после порога (около 256 элементов с Go 1.18) рост становится плавнее и с ростом длины сходится к ×1.25, чтобы не тратить память на больших объёмах: сразу за порогом коэффициент ещё около двух и снижается постепенно. Поэтому append работает амортизированно за O(1): отдельная операция может стоить O(n) на копировании, но суммарно за n добавлений копирований будет O(n). Заранее известный размер стоит задавать: make([]T, 0, n) убирает все реаллокации.

var s []int
prev := cap(s)
for i := 0; i < 2000; i++ {
    s = append(s, i)
    if cap(s) != prev {
        fmt.Printf("len=%d cap=%d\n", len(s), cap(s))
        prev = cap(s)
    }
}
// len=1 cap=4, len=5 cap=8, len=9 cap=16, len=17 cap=32, ... len=257 cap=512,
// а дальше шаг роста уменьшается: 512 -> 848 -> 1280 -> 1792 -> 2560

Как звучит правильное объяснение на собесе

«append смотрит на len и cap. Если места хватает, он пишет в существующий массив и возвращает заголовок с увеличенной длиной; исходный слайс при этом не меняется, но данные общие. Если места нет, выделяется новый массив, и слайсы становятся независимыми. В первом примере ёмкости хватило, поэтому оба append писали в одну и ту же ячейку, и второй затёр первый. Во втором не хватило, поэтому q уехал на новую память. Из этого следует правило: не полагаться на то, скопировал append данные или нет, а копировать явно, когда независимость нужна.»

Код

func main() {
    m := []int{1, 2, 3, 4, 5}
    n := m[1:3:3]                 // low : high : max
    fmt.Println(len(n), cap(n))

    n = append(n, 99)
    fmt.Println(m)
    fmt.Println(n)
}

Почему

Full slice expression a[low:high:max] задаёт все три поля заголовка явно: ptr = &a[low], len = high - low, cap = max - low. Действует ограничение low ≤ high ≤ max ≤ cap(a).

В примере cap(n) == len(n) == 2, свободного места нет вообще. Поэтому append обязан выделить новый массив и скопировать туда данные, а исходный m остаётся физически недосягаем. Ровно этого мы и добивались.

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

type Buffer struct {
    data []byte
}

// Плохо: вызывающий может append'нуть и затереть наши данные за границей len.
func (b *Buffer) Head(n int) []byte { return b.data[:n] }

// Хорошо: cap обрезан, любой append у вызывающего сделает копию.
func (b *Buffer) HeadSafe(n int) []byte { return b.data[:n:n] }

Идиома s[:n:n] (или s[:len(s):len(s)]) читается как «отдать read-append-safe вид на слайс». Ровно в таком виде она встречается в стандартной библиотеке и в хорошем чужом коде.

Как звучит правильное объяснение на собесе

«Третий индекс задаёт cap: a[low:high:max] даёт cap = max - low. Когда я пишу a[1:3:3], ёмкость становится равной длине, свободного места нет, и любой append вынужден скопировать данные в новый массив. Это стандартный приём, когда отдаёшь наружу часть своего буфера: сосед не сможет незаметно записать поверх твоих данных через append. От прямой записи по индексу это не защищает, там нужна копия.»

Код

func mod(s []int) {
    s[0] = 100                    // запись по индексу
    s = append(s, 4)              // может переаллоцировать
    s[1] = 200                    // запись, но куда?
}

func main() {
    a := []int{1, 2, 3}           // len 3, cap 3
    mod(a)
    fmt.Println(a, len(a), cap(a))

    b := make([]int, 3, 4)        // len 3, cap 4
    copy(b, []int{1, 2, 3})
    mod(b)
    fmt.Println(b, len(b), cap(b))
}

Почему

В Go всё передаётся по значению, включая слайс. Функция получает копию заголовка {ptr, len, cap}. Отсюда два разных эффекта, которые часто путают в один:

• Запись по индексу проходит через указатель, который в копии заголовка тот же. Поэтому s[0] = 100 меняет данные, видимые снаружи. Работает всегда.
• append меняет поля len/cap копии заголовка, а копия локальна. Даже если данные записались в общий массив, снаружи len остался старым, и новый элемент не виден. Именно поэтому обязательно писать s = append(s, v) и возвращать результат.

Первый случай: cap(a) = 3, места нет, append выделил новый массив. Локальный s теперь смотрит туда, и s[1] = 200 пишет в новую память, которую снаружи никто не видит. На выходе [100 2 3].

Второй случай: cap(b) = 4, место есть, append дописал в тот же массив. Локальный s всё ещё указывает на массив b, поэтому s[1] = 200 меняет b[1]. Получается [100 200 3], а четвёрка лежит в b[3], за границей длины, и снаружи не видна.

Как надо было написать

// Вариант 1: вернуть результат, так идиоматичнее.
func mod(s []int) []int {
    s[0] = 100
    s = append(s, 4)
    s[1] = 200
    return s
}
a = mod(a)

// Вариант 2: указатель на слайс, когда возврат неудобен (редко).
func modP(s *[]int) {
    (*s)[0] = 100
    *s = append(*s, 4)
}

Как звучит правильное объяснение на собесе

«Слайс передаётся по значению, функция получает копию заголовка, но указатель внутри тот же. Поэтому запись по индексу видна снаружи всегда, а append снаружи не виден: он меняет len локальной копии. Дальше всё зависит от ёмкости: если append переаллоцировал, локальный слайс уехал на новую память и последующие записи наружу не видны; если места хватило, они по-прежнему идут в исходный массив. Поэтому в Go и пишут s = append(s, v), а функции, которые дописывают в слайс, возвращают его.»

Код

type P struct {
    Name string
    Age  int
}

func main() {
    ps := []P{{"Аня", 30}, {"Боря", 40}}
    for _, p := range ps {
        p.Age++                       // меняем копию
    }
    fmt.Println(ps)

    for i := range ps {
        ps[i].Age++                   // меняем оригинал
    }
    fmt.Println(ps)

    arr := [3]int{1, 2, 3}            // МАССИВ
    fmt.Print("массив: ")
    for i, v := range arr {
        if i == 0 {
            arr[1] = 100
        }
        fmt.Print(v, " ")
    }
    fmt.Println(arr)

    sl := []int{1, 2, 3}              // СЛАЙС
    fmt.Print("слайс:  ")
    for i, v := range sl {
        if i == 0 {
            sl[1] = 100
        }
        fmt.Print(v, " ")
    }
    fmt.Println(sl)
}

Почему часть первая: переменная цикла - копия

for _, p := range ps на каждой итерации копирует элемент в переменную p. Копия структуры полностью независима, p.Age++ инкрементирует её и выбрасывает при следующей итерации. Чтобы изменить оригинал, нужно обращаться по индексу: ps[i].Age++ (или брать &ps[i]).

Побочный эффект, о котором стоит знать: копирование не бесплатно. Если структура большая - скажем, 200 байт, - цикл for _, v := range bigStructs копирует по 200 байт на итерацию. Для горячего кода это заметно, и там пишут for i := range s с обращением &s[i].

Почему часть вторая: range вычисляет выражение один раз

Перед началом цикла Go один раз вычисляет выражение справа от range и работает с этой копией значения. И вот тут массив и слайс расходятся радикально:

• Массив - это значение целиком, все элементы. Копируется весь массив. Цикл идёт по копии, поэтому arr[1] = 100 внутри тела на итерации не влияет: копия сделана до цикла. Печатается 1 2 3, хотя сам arr уже [1 100 3].
• Слайс - это заголовок {ptr, len, cap}. Копируется заголовок, но данные общие. Поэтому sl[1] = 100 видно на следующей итерации: печатается 1 100 3.

Отсюда же следует ещё одно свойство: число итераций фиксируется до цикла. Если внутри range sl делать sl = append(sl, x), цикл всё равно пройдёт исходное число раз - бесконечного цикла не будет, потому что len взят один раз. Это отличает Go от языков, где такой код зацикливается.

Как звучит правильное объяснение на собесе

«range делает две вещи, о которых надо помнить. Первое: он один раз вычисляет выражение справа. Для массива это копия всех элементов, поэтому изменения внутри цикла не видны; для слайса - копия заголовка, а данные общие, поэтому видны. Второе: переменная значения - это копия элемента, менять её бессмысленно, надо идти через индекс. Оба факта сводятся к одному: в Go всё копируется по значению, а разница между массивом и слайсом - в том, что именно лежит в этом значении.»

Код

func main() {
    m := map[string]int{"a": 1, "b": 2, "c": 3, "d": 4, "e": 5, "f": 6}
    for r := 0; r < 3; r++ {
        fmt.Print("проход ", r, ": ")
        for k := range m {
            fmt.Print(k, " ")
        }
        fmt.Println()
    }

    m2 := map[int]int{1: 1, 2: 2, 3: 3, 4: 4}
    seen := 0
    for k := range m2 {
        seen++
        if k == 1 {
            m2[100] = 100          // добавляем во время обхода
            delete(m2, 4)          // и удаляем
        }
    }
    fmt.Println("итераций:", seen, "итог:", len(m2))
}

Почему порядок случаен - и почему это сделано специально

Рантайм Go намеренно рандомизирует стартовую позицию обхода мапы. Это не побочный эффект хеширования, а сознательное решение: чтобы никто не начал полагаться на порядок, который остаётся деталью устройства мапы. Иначе любая переделка внутренностей (а их переписывали: в Go 1.24 мапу перевели на SwissTable) ломала бы код по всей экосистеме. Плюс защита от HashDoS: подобрать ключи с одинаковым хешем не выйдет, потому что сид у каждой мапы свой и берётся при её создании.

Практическое следствие: если порядок нужен, его надо создать явно.

keys := make([]string, 0, len(m))
for k := range m {
    keys = append(keys, k)
}
sort.Strings(keys)               // или slices.Sort(keys)
for _, k := range keys {
    fmt.Println(k, m[k])
}
// Для m := map[string]int{"b": 2, "a": 1, "c": 3} выведет всегда одно и то же:
// a 1
// b 2
// c 3

Почему модификация во время обхода даёт разное число итераций

Спецификация Go описывает это буквально в двух правилах:

• Удаление безопасно и предсказуемо. Если ключ удалён во время обхода, а цикл до него ещё не дошёл, он не будет выдан. Поэтому for k := range m { delete(m, k) } законно очищает мапу (хотя clear(m) с Go 1.21 лучше).
• Добавление недетерминированно. Новый ключ может быть выдан в этом же обходе, а может и нет. Зависит от того, попал он в уже пройденную область таблицы или в ещё не пройденную и вызвала ли вставка рост таблицы.

В примере: 4 ключа, а на итерации с ключом 1 один удаляется (4) и один добавляется (100). Если удалённый ключ ещё не был выдан, а так выходит в большинстве запусков (ключ 1 должен выпасть первым), получается минус одна итерация. Новый попал в непройденную часть, значит плюс одна. Комбинации дают 3 или 4. Итоговый len при этом всегда 4: было 4, минус один, плюс один.

Как звучит правильное объяснение на собесе

«Порядок обхода мапы в Go рандомизирован намеренно, чтобы на него не полагались. От HashDoS защищает другое: случайный сид хеша у каждой мапы. Для стабильного порядка надо собрать ключи в слайс и отсортировать. Модификация во время обхода из одной горутины легальна, но с оговорками: удалённый ключ гарантированно не будет выдан, а добавленный может быть выдан, а может нет. Поэтому число итераций тут не определено, 3 или 4. А конкурентная модификация из другой горутины даёт fatal error от рантайма, который не ловится через recover.»

Код

func main() {
    var m map[string]int           // объявлена, но НЕ создана - это nil

    fmt.Println(m == nil, len(m), m["x"])
    v, ok := m["x"]
    fmt.Println("чтение:", v, ok)

    delete(m, "x")                 // без паники
    for range m {                  // 0 итераций, без паники
        fmt.Println("не будет")
    }
    fmt.Println("до записи всё ок")

    defer func() { fmt.Println("recover:", recover()) }()
    m["x"] = 1                     // ← вот тут
}

Почему

Nil-мапа хранит нулевой указатель на хеш-таблицу. Всё, что не требует самой таблицы, работает корректно и без специальных проверок в твоём коде:

Асимметрию сделали осознанно: nil-мапа ведёт себя как пустая мапа только для чтения. Поэтому функция спокойно возвращает nil вместо пустой мапы, а вызывающий её читает и обходит, не проверяя на nil. Так же устроен nil-слайс: len, range и append на нём работают.

type Config struct {
    Name string
    Tags map[string]string          // забыли инициализировать
}

c := Config{Name: "svc"}
fmt.Println(c.Tags["env"])          // "" - работает, никаких подозрений
c.Tags["env"] = "prod"              // panic: assignment to entry in nil map

Как звучит правильное объяснение на собесе

«Nil-мапа ведёт себя как пустая мапа, доступная только для чтения. Чтение, len, range и delete на ней работают и возвращают нулевые значения: так сделано, чтобы функции могли возвращать nil вместо пустой мапы. Паникует только запись, потому что писать физически некуда. Чаще всего на это напарываются с мапой-полем структуры: нулевое значение структуры содержит nil-мапу, и падение приходит на первой же записи. Отсюда правило: мапы и каналы инициализируются в конструкторе.»

Код

type MyErr struct {
    Code int
}

func (e *MyErr) Error() string { return fmt.Sprintf("my error %d", e.Code) }

func doWork(fail bool) *MyErr {      // ← конкретный тип, не error
    if fail {
        return &MyErr{Code: 500}
    }
    return nil                       // честный nil типа *MyErr
}

func wrap(fail bool) error {         // ← а тут уже интерфейс
    return doWork(fail)
}

func main() {
    err := wrap(false)
    fmt.Println("err == nil:", err == nil)
    fmt.Println("err печатается как:", err)
    fmt.Printf("%v | %T\n", err, err)

    var p *MyErr
    var i any = p
    fmt.Println("any(nil-указатель) == nil:", i == nil)
}

Почему

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

На return doWork(fail) срабатывает неявное преобразование *MyErr → error. Компилятор упаковывает пару: тип *MyErr есть, значение указателя равно nil. Интерфейс получился «непустым», хотя внутри пусто.

Больнее всего делает баг строка err печатается как: <nil>. fmt видит nil-указатель внутри и печатает <nil>, так что в логах всё выглядит нормально, а if err != nil при этом срабатывает. Классический сценарий: сервис отвечает «ошибка», в логе стоит <nil>, и несколько часов уходит на поиск.

Как чинить

// Вариант 1 (лучший): функция сразу возвращает интерфейс error.
func doWork(fail bool) error {
    if fail {
        return &MyErr{Code: 500}
    }
    return nil                       // теперь это настоящий nil-интерфейс
}

// Вариант 2: если сигнатуру менять нельзя - явная проверка при конвертации.
func wrap(fail bool) error {
    if e := doWork(fail); e != nil {  // сравниваем УКАЗАТЕЛЬ с nil, до упаковки
        return e
    }
    return nil
}

Правило, которое стоит произнести: «функции всегда возвращают error, а не конкретный тип ошибки». Это официальная рекомендация из Go FAQ, а вот линтера, который ловил бы этот случай, нет: nilnil проверяет другое - возврат nil, nil, - а nilness из x/tools в go vet не входит и ищет разыменование заведомо нулевого указателя.

Как звучит правильное объяснение на собесе

«Интерфейс хранит пару тип-значение и равен nil только когда обе части пусты. Здесь функция вернула nil типа *MyErr; при упаковке в error тип сохранился, поэтому интерфейс не nil, хотя указатель внутри nil. Печатается он при этом как <nil>, что делает баг особенно неприятным. Правило простое: возвращать из функций error, а не конкретный тип ошибки; если сигнатуру не поменять, сравнить конкретный указатель с nil до того, как он попадёт в интерфейс.»

Код

func main() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("main recover:", r)
        }
        fmt.Println("defer в main")
    }()

    go func() {
        defer fmt.Println("defer в горутине")
        panic("boom")
    }()

    time.Sleep(100 * time.Millisecond)
    fmt.Println("сюда не дойдём")
}

Почему

recover работает только внутри той же горутины, где случилась паника, и только в отложенной функции, вызванной непосредственно паникующей цепочкой. У каждой горутины свой стек и свой список defer; main о панике в другой горутине ничего не знает: для неё эта паника не «происходит».

Механика раскрутки такая: паника поднимается по стеку своей горутины, выполняя её отложенные вызовы, поэтому defer в горутине и печатается. Если ни один из них не сделал recover, паника доходит до вершины стека горутины, и рантайм печатает сообщение с трассировкой и завершает весь процесс. Отложенные вызовы остальных горутин, включая main, при этом не выполняются вовсе.

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

goroutine 1 [running] {request_id: "abc-123", route: "/users/{id}"}:
main.main()

Что recover не ловит вообще

• Панику из другой горутины: разобрано выше.
• fatal error от рантайма. «concurrent map writes», «all goroutines are asleep - deadlock», «out of memory», переполнение стека. Это не паники, а фатальные состояния рантайма: их не перехватить в принципе.
• os.Exit(). Он не разматывает стек и не выполняет defer.
• recover не в defer. Вызов recover() прямо в коде функции всегда вернёт nil: он работает только из отложенной функции. И только из непосредственно отложенной: defer func(){ helper() }(), где helper вызывает recover, тоже не сработает.

Как звучит правильное объяснение на собесе

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

Код

func main() {
    a := make(chan int, 1)
    b := make(chan int, 1)
    counts := map[string]int{}
    for i := 0; i < 10000; i++ {
        a <- 1
        b <- 2
        select {                       // ОБА готовы
        case <-a:
            counts["a"]++
            <-b
        case <-b:
            counts["b"]++
            <-a
        }
    }
    fmt.Println("случайный выбор:", counts)

    c := make(chan int)
    close(c)
    for i := 0; i < 3; i++ {
        select {
        case v, ok := <-c:
            fmt.Println("из закрытого:", v, ok)
        }
    }

    var nilCh chan int
    select {
    case <-nilCh:
        fmt.Println("никогда")
    default:
        fmt.Println("nil-канал не готов никогда - сработал default")
    }
}

Почему

Правил у select четыре, и все четыре стоит назвать:

1. Если готова ровно одна ветка, выполняется она.
2. Если готовы несколько, выбирается равновероятно случайная. Не первая, не последняя, не по порядку в коде. Это гарантия языка, и держится она на перестановке порядка опроса. Сделано, чтобы select не голодал ни по одной ветке: иначе быстрый канал навсегда заглушил бы медленный.
3. Если не готова ни одна и есть default, выполняется default, и select становится неблокирующим.
4. Если не готова ни одна и default нет, горутина блокируется, пока какая-нибудь не станет готова. select{} без веток блокируется навсегда.

Закрытый канал всегда готов на чтение и мгновенно отдаёт нулевое значение с ok == false. Отсюда две вещи. Хорошая: на этом построены done-каналы и ctx.Done(): закрытие будит всех ожидающих сразу. Плохая: если забыть про ok, select в цикле по закрытому каналу начнёт крутиться на 100% CPU, бесконечно получая нули. Лечит обнуление канала:

for a != nil || b != nil {
    select {
    case v, ok := <-a:
        if !ok {
            a = nil                    // выключаем ветку навсегда
            continue
        }
        use(v)
    case v, ok := <-b:
        if !ok {
            b = nil
            continue
        }
        use(v)
    }
}

Nil-канал в select не готов никогда, ни на чтение, ни на запись, и просто «выключает» свою ветку. Это не костыль, а официальная идиома: приём с ch = nil живёт в стандартной библиотеке и в любом нетривиальном pipeline. Вне select операция с nil-каналом блокирует навсегда, и отсюда же берётся её роль «выключателя».

for {
    select {
    case v := <-ch:
        handle(v)
    case <-time.After(time.Second):    // НОВЫЙ таймер на каждой итерации
        return
    }
}

Как звучит правильное объяснение на собесе

«Если в select готовы несколько веток, выбирается случайная. Это гарантия языка, а не деталь реализации, и сделана она против голодания. Закрытый канал всегда готов и отдаёт нулевое значение с ok = false, поэтому в цикле такой select закрутится, если не проверять ok и не обнулять канал. Nil-канал, наоборот, не готов никогда, и присваивание ch = nil служит стандартным способом выключить ветку select. default делает select неблокирующим.»

Код

type S struct {
    mu sync.Mutex
    n  int
    sl []int
    m  map[string]int
    p  *int
}

func main() {
    one := 1
    a := S{n: 1, sl: []int{1, 2, 3}, m: map[string]int{"x": 1}, p: &one}
    b := a                             // копирование структуры

    b.n = 100
    b.sl[0] = 100
    b.m["x"] = 100
    *b.p = 100
    b.sl = append(b.sl, 4)

    fmt.Println("a:", a.n, a.sl, a.m, *a.p)
    fmt.Println("b:", b.n, b.sl, b.m, *b.p)
}

Почему

Структура копируется поверхностно: побайтово копируются все поля. Дальше всё решает тип поля.

Тонкий момент со слайсом: b.sl[0] = 100 видно в a, потому что массив общий. А b.sl = append(b.sl, 4) уже не видно: append при cap 3 переаллоцировал, и b.sl уехал на новый массив. Даже если бы ёмкости хватило, a.sl всё равно остался бы длиной 3, заголовки-то разные. Одна строка кода показывает обе половины природы слайса.

Как сделать настоящую независимую копию

func (s *S) Clone() *S {
    s.mu.Lock()
    defer s.mu.Unlock()

    c := &S{n: s.n}                    // новый мьютекс в нулевом состоянии
    c.sl = slices.Clone(s.sl)          // копия слайса
    c.m = maps.Clone(s.m)              // копия мапы (тоже поверхностная!)
    if s.p != nil {
        v := *s.p
        c.p = &v                       // копия значения по указателю
    }
    return c
}

Оговорка: slices.Clone и maps.Clone тоже поверхностные. Если внутри слайса лежат структуры со слайсами, их придётся копировать рекурсивно. Настоящего глубокого копирования в стандартной библиотеке нет, и на добивку правильно ответить: «сделал бы явный Clone, потому что автоматического deep copy в Go нет».

Как звучит правильное объяснение на собесе

«Копирование структуры в Go поверхностное: копируются поля как есть. int скопировался по-настоящему. Слайс скопировал заголовок, массив остался общий, но длина у каждого своя, поэтому запись по индексу видна, а append уже нет. Мапа и указатель сами по себе указатели, данные полностью общие. А мьютекс скопировался вместе со своим состоянием, и это баг: у копии свой мьютекс, взаимоисключение сломано. go vet ловит это правилом copylocks, поэтому типы с мьютексом всегда используются через указатель.»

Код

package main

import "fmt"

var a = b + 1                     // объявлены в «неправильном» порядке
var b = c + 1
var c = f()

func f() int { fmt.Println("1. f() - вычисляется c"); return 1 }

func init() { fmt.Println("2. init A:", a, b, c) }
func init() { fmt.Println("3. init B") }

const (
    A = iota                      // 0
    B                             // 1
    _                             // 2 - пропущен
    D                             // 3
)

const (
    _  = iota
    KB = 1 << (10 * iota)          // 1 << 10
    MB                            // повтор выражения с iota = 2
    GB
)

type Weekday int

const (
    Mon Weekday = iota + 1
    Tue
    Wed
)

func main() {
    fmt.Println("4. main:", a, b, c)
    fmt.Println("iota:", A, B, D)
    fmt.Println("размеры:", KB, MB, GB)
    fmt.Println("дни:", Mon, Tue, Wed)
}

Почему: переменные пакета инициализируются по зависимостям, а не по порядку

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

Здесь a зависит от b, b зависит от c, а c не зависит ни от чего. Поэтому реальный порядок: c = f() = 1, затем b = 2, затем a = 3. Текстовый порядок объявления полностью игнорируется. Циклическая зависимость (var x = y; var y = x) даёт ошибку компиляции, а не бесконечный цикл.

Полный порядок запуска программы: константы пакета → переменные пакета в порядке зависимостей → все функции init() в порядке объявления (их может быть сколько угодно, в том числе несколько в одном файле) → main(). Пакеты при этом обрабатываются снизу вверх по дереву импортов: импортируемый пакет полностью инициализируется раньше импортирующего, и каждый проходит это ровно один раз, даже если импортирован многократно.

Почему iota ведёт себя именно так

• iota хранит порядковый номер ConstSpec в блоке const, считая с нуля. Не «счётчик констант», а именно номер строки спецификации. Поэтому пустая строка _ тоже увеличивает iota: A=0, B=1, _=2, D=3.
• Пропущенное выражение повторяет предыдущее. MB и GB не «наследуют значение», а повторяют формулу 1 << (10 * iota) со своим iota: 2 и 3. Отсюда 1<<20 и 1<<30. Тут спотыкаются чаще всего.
• iota обнуляется в каждом новом блоке const, а внутри блока считает строки, а не константы: строка X, Y = iota, iota*2 даёт одну спецификацию и один iota.
• Тип наследуется вместе с выражением. Tue и Wed получают тип Weekday, потому что повторяется вся спецификация целиком, включая тип.

Как звучит правильное объяснение на собесе

«Переменные пакета инициализируются не сверху вниз, а по графу зависимостей: сначала то, у чего нет неготовых зависимостей. Здесь это c, потом b, потом a, получится 3, 2, 1. Дальше выполняются все init() в порядке объявления, потом main. Пакеты инициализируются снизу вверх по импортам и по одному разу. iota означает номер строки внутри блока const, поэтому пропуск через _ его увеличивает, а пустая строка повторяет предыдущее выражение целиком, включая тип, но уже с новым значением iota.»

Код

func main() {
    var x any = 1
    var y any = 1.0
    fmt.Println("1)", x == y)

    var s1 any = "go"
    var s2 any = "go"
    fmt.Println("2)", s1 == s2)

    type Pt struct {
        X, Y int
    }
    var p1 any = Pt{1, 2}
    var p2 any = Pt{1, 2}
    fmt.Println("3)", p1 == p2)

    defer func() { fmt.Println("recover:", recover()) }()
    var b1 any = []int{1, 2}
    var b2 any = []int{1, 2}
    fmt.Println("4)", b1 == b2)       // ← компилируется, но падает
}

Почему

Два значения интерфейса равны, если совпадают их динамические типы И равны их динамические значения. Отсюда первый результат: 1 и 1.0 - числа одинаковые, но типы int и float64 разные, значит false. Никакого неявного приведения при сравнении интерфейсов не происходит.

Второй шаг - сравнимость самого динамического типа. Go делит типы на две категории:

Если несравнимый тип написан явно - []int{1} == []int{2}, - это ошибка компиляции: компилятор видит типы и запрещает. Но когда значение спрятано в интерфейсе, статически тип неизвестен: any == any компилируется всегда. Проверка переезжает в рантайм, и там она превращается в панику comparing uncomparable type []int. Именно этот переход «из compile-time в runtime» и есть содержание вопроса.

m := map[any]int{}
m["строка"] = 1                    // ок
m[42] = 2                          // ок
m[[2]int{1, 2}] = 3                // ок: массив сравним
m[[]int{1, 2}] = 4                 // panic: runtime error: hash of unhashable type []int

Чем сравнивать несравнимое

slices.Equal(a, b)                 // слайсы, поэлементно, быстро - Go 1.21+
maps.Equal(m1, m2)                 // мапы
reflect.DeepEqual(x, y)            // что угодно, но медленно и с сюрпризами

reflect.DeepEqual стоит упомянуть вместе с его подвохом: он считает []int(nil) и []int{} разными, хотя обе длины нулевые. В тестах это регулярно приводит к ложным падениям - поэтому в новом коде предпочитают slices.Equal (который их как раз уравнивает) или google/go-cmp.

Как звучит правильное объяснение на собесе

«Интерфейсы равны, когда совпадают и динамический тип, и значение. Поэтому any(1) и any(1.0) не равны - типы разные. А если динамический тип несравним - слайс, мапа или функция, - то сравнение компилируется (статически тип неизвестен), но падает в рантайме с comparing uncomparable type. Та же паника прилетает при использовании такого значения как ключа мапы. Для слайсов и мап есть slices.Equal и maps.Equal; reflect.DeepEqual тоже работает, но медленный и по-разному трактует nil и пустой слайс.»

Код

func main() {
    s := "Привет, Go!"
    fmt.Println("len:", len(s))
    fmt.Println("рун:", utf8.RuneCountInString(s))
    fmt.Printf("s[0] = %v, %c, %q\n", s[0], s[0], s[0])
    fmt.Printf("s[:3] = %q\n", s[:3])

    fmt.Print("range: ")
    for i, r := range s[:12] {
        fmt.Printf("(%d:%c) ", i, r)
    }
    fmt.Println()

    fmt.Print("byte-loop: ")
    for i := 0; i < 6; i++ {
        fmt.Printf("%d ", s[i])
    }
    fmt.Println()

    r := []rune(s)
    fmt.Println("[]rune len:", len(r), "первый:", string(r[0]))
}

Почему

Строка в Go - это неизменяемая последовательность байт, а не символов. Литералы в исходнике хранятся в UTF-8, где кириллическая буква занимает 2 байта, латиница и цифры - 1, а эмодзи - 4. «Привет, Go!» - это 6 кириллических букв (12 байт) + запятая, пробел, G, o, ! (5 байт) = 17 байт при 11 рунах.

• s[i] возвращает byte (uint8), а не символ. s[0] = 208 - это первый из двух байт буквы «П» (0xD0 0x9F). %c честно печатает символ с кодом 208 - Ð.
• Срез строки режет байты. s[:3] захватывает «П» целиком и первый байт от «р» - получается невалидный UTF-8, который %q показывает как "П\xd1".
• range по строке декодирует UTF-8 на лету и выдаёт пары (байтовое смещение, руна). Именно поэтому индексы идут 0, 2, 4, 6… - это не порядковые номера символов, а смещения в байтах. Ловушка: если использовать этот i как «номер символа», всё сломается на первой же кириллице.
• []rune(s) декодирует всю строку в слайс int32 - по 4 байта на руну. Даёт случайный доступ и корректный len, но стоит O(n) времени и O(n) памяти.

Как делать правильно

Когда индексный цикл по байтам уместен: если ты осознанно работаешь с байтами - парсишь ASCII-протокол, ищешь разделитель, считаешь размер для буфера. Тогда это не ошибка, а оптимизация, и об этом стоит сказать вслух: «здесь я иду по байтам намеренно, потому что разделитель - ASCII, а ASCII-байт не может встретиться внутри многобайтовой руны в UTF-8». Последнее - самосинхронизирующееся свойство UTF-8, и знание про него ценится отдельно.

Как звучит правильное объяснение на собесе

«Строка в Go - это байты в UTF-8, поэтому len даёт длину в байтах, а s[i] - байт, а не символ: для кириллицы это половина буквы. range по строке декодирует UTF-8 и выдаёт руну и её байтовое смещение - поэтому индексы идут через один, и использовать их как номер символа нельзя. Если нужен случайный доступ к символам - конвертирую в []rune один раз, помня, что это O(n) памяти. Резать строку можно только по границам рун, иначе получится невалидный UTF-8.»