Go: язык

1.1Типы и базовые конструкции

Дальше в Go-секции всё упирается в эту главу. Если не уложится в голове, что такое значение и что копируется, поплывут и слайсы, и мапы, и интерфейсы.

Сначала — три вещи, без которых дальше будет каша

Считай, что вся глава про один вопрос: если я где-то поменяю значение, увидит ли это изменение кто-то другой? Чтобы отвечать не наугад, хватит трёх вещей. Договоримся о словах.

1. Переменная — это кусочек памяти с именем

Когда ты пишешь var x int64, программа откладывает в памяти кусочек размером 8 байт и вешает на него ярлык x. Размер кусочка задаёт тип: bool занимает 1 байт, int64 — 8, структура из двух int64 — 16. Компилятор знает размер заранее, ещё до запуска, поэтому и отводит ровно столько места, сколько нужно.

2. Присваивание — это копирование байтов из одного кусочка в другой

b := a означает буквально: «взять байты, которые лежат в кусочке a, и записать их в кусочек b». Два разных кусочка памяти, побайтовое копирование из первого во второй. С аргументом функции то же самое: у неё появляется свой кусочек памяти под параметр, и туда копируются байты из аргумента.

Отсюда и ответ на главный вопрос: раз кусочки разные, изменение одного не трогает другой. Загвоздка в одном: всё зависит от того, что именно лежало в скопированных байтах.

3. Указатель — переменная, в которой лежит не значение, а адрес

Иногда в кусочке памяти лежат не «полезные» данные, а адрес другого кусочка: число, которое говорит «нужное лежит вон там». Такая переменная называется указателем (тип пишется как *T, взять адрес — &x, сходить по адресу — *p).

Аналогия: значение — квартира, указатель — бумажка с её адресом. Скопировав бумажку, ты получил вторую бумажку, но квартира осталась одна. Придёшь по любой из двух бумажек, попадёшь в одну и ту же квартиру, и следы чужого ремонта увидишь по обеим.

Система типов: что вообще есть

Все типы Go делятся на четыре группы, и отличаются они ровно одним: что лежит в том самом кусочке памяти, который скопируется при присваивании.

Целые числа: размер и переполнение

int и uint — платформозависимые типы: они шириной в машинное слово целевой архитектуры. На всех современных сборках (amd64, arm64) это 64 бита, на 32-битных (386, arm) — 32. Смотри strconv.IntSize или unsafe.Sizeof(int(0)). При этом int, int64 и int32 — это три разных типа, между которыми нет неявного приведения, даже когда их размеры совпадают.

var a int = 5
var b int64 = 10
// _ = a + b            // ошибка компиляции:
//                      // invalid operation: a + b (mismatched types int and int64)
_ = int64(a) + b        // ок — явная конверсия

// размер int зависит от платформы:
fmt.Println(strconv.IntSize)          // 64 на amd64/arm64
fmt.Println(unsafe.Sizeof(int(0)))    // 8

Переполнение целых в Go не паникует и не проверяется в рантайме: это арифметика по модулю 2^N («заворачивается»). Знаковые прыгают с максимума на минимум, беззнаковые с нуля на максимум.

var i8 int8 = 127
i8++                       // -128, без паники

var u uint8 = 0
u--                        // 255

// В проде чаще всего подводит беззнаковая арифметика:
var n uint = 3
for i := n; i >= 0; i-- {  // бесконечный цикл: uint никогда не станет < 0
    _ = i
}

// И вторая: разность длин в uint
a, b := len(x), len(y)     // len возвращает int, тут всё ок
var la, lb uint = 2, 5
_ = la - lb                // 18446744073709551613, а не -3

Компилятор ловит переполнение только у констант, потому что константы вычисляются с произвольной точностью на этапе компиляции:

const big = 1 << 62         // ок, нетипизированная константа: побитовый сдвиг "1 << 62" даёт 2⁶²
var x int8 = 200            // ошибка компиляции: constant 200 overflows int8
var y = big * 4             // ошибка: constant overflows int (при присвоении в int)

Zero values: почему в Go нет мусора в памяти

Любая объявленная переменная гарантированно инициализирована. Рантайм обнуляет выделенную память (memclr), и на стеке, и в куче. Это решение сознательное: оно убирает целый класс багов «использование неинициализированной переменной», делает var mu sync.Mutex сразу готовым к работе, а var buf bytes.Buffer — валидным. Формулировка для собеса: в Go нулевое значение должно быть полезным (zero value is useful), это принцип дизайна стандартной библиотеки.

byte и rune

Оба — псевдонимы, не самостоятельные типы: type byte = uint8 и type rune = int32 объявлены через =, то есть это буквально одно и то же имя для одного типа. Поэтому byte и uint8 взаимозаменяемы без конверсии, а вот type MyByte uint8 (без =) создал бы новый тип, требующий явного приведения.

• byte — один октет. Из них состоят строки, содержимое []byte, элементы I/O.
• rune — одна кодовая точка Unicode, 32 бита. Это не «символ», каким его видит человек: составные эмодзи и буквы с диакритикой могут состоять из нескольких рун.

s := "Привет"
fmt.Println(len(s))                       // 12 — байты, кириллица по 2 байта в UTF-8
fmt.Println(utf8.RuneCountInString(s))    // 6  — руны
fmt.Printf("%T %v\n", s[0], s[0])         // uint8 208 — байт, не буква
fmt.Printf("%T %c\n", []rune(s)[0], []rune(s)[0]) // int32 П

Приведение типов: почему всё явно

В Go есть конверсия (T(v)) и нет неявного приведения между разными типами, даже если базовое представление у них одинаковое. Причина: код предсказуем, скрытых потерь нет. В C/C++/Java правила неявных промоушенов занимают страницы спецификации и регулярно рождают баги вида «поделили int на int и получили 0», «сравнили signed с unsigned». Go эту область просто удалил.

type UserID int64
type OrderID int64

var u UserID = 7
var o OrderID = u          // ошибка компиляции: cannot use u (variable of int64
                           // type UserID) as OrderID value in variable declaration
                           // ради этого отдельные типы и заводят
var o2 OrderID = OrderID(u) // явно, на ревью сразу видно

// Конверсия может молча терять данные:
var big int32 = 300
var small int8 = int8(big)  // 44, старшие биты отброшены, ошибки нет

// Конверсия float→int обрезает, а не округляет:
f := 2.99
fmt.Println(int(f))         // 2
fmt.Println(int(-f))        // -2
// Но только для переменной. int(2.99) от нетипизированной константы —
// ошибка компиляции: cannot convert 2.99 (untyped float constant) to type int

Константы и iota

Константы в Go вычисляются на этапе компиляции и бывают типизированными и нетипизированными. Нетипизированная константа хранится с произвольной точностью (минимум 256 бит по спецификации) и получает тип только в момент использования. Поэтому и можно писать math.MaxInt64 и 1 << 62 без гимнастики с приведениями.

const Pi = 3.14159           // нетипизированная float-константа
const TypedPi float64 = 3.14 // типизированная

var f float32 = Pi           // ок: нетипизированная подстроится
// var g float32 = TypedPi   // ошибка компиляции: cannot use TypedPi (constant
//                           // 3.14 of type float64) as float32 value

const Huge = 1 << 100        // ок, пока не присваиваем в переменную
fmt.Println(Huge >> 98)      // 4 — вычислено компилятором

iota — счётчик внутри блока const. Он равен индексу строки (ConstSpec) в блоке, начиная с нуля, и сбрасывается на каждом новом const (. Тонкость: если у строки нет своего выражения, повторяется выражение предыдущей строки. Так и работают «пустые» строки в перечислении.

type Weekday int

const (
    Sunday Weekday = iota // 0
    Monday                // 1 — выражение унаследовано
    Tuesday               // 2
)

// Пропуск значений через _
const (
    _  = iota             // 0 отбрасываем
    KB = 1 << (10 * iota)  // 1 << 10 = 1024
    MB                    // 1 << 20
    GB                    // 1 << 30
)

// Битовые флаги
type Perm uint8
const (
    Read Perm = 1 << iota // 1
    Write                 // 2
    Exec                  // 4
)
p := Read | Write
fmt.Println(p&Write != 0) // true

switch: чем отличается от C-подобных языков

// break внутри switch выйдет из switch, а не из цикла, тут часто ошибаются
loop:
for _, ev := range events {
    switch ev.Kind {
    case KindStop:
        break loop        // без метки прервали бы только switch
    case KindSkip:
        continue loop
    }
    handle(ev)
}

// switch без выражения идиоматично заменяет лестницу if
switch {
case age < 13:
    return "child"
case age < 20:
    return "teen"
default:
    return "adult"
}

Структуры: сравнение и выравнивание

Структура comparable, если comparable все её поля. Не comparable: слайсы, мапы, функции, а значит и любая структура, которая их содержит. Массивы comparable, если comparable их элементы. Структуры сравниваются пополево, а не побайтово (иначе padding-байты давали бы ложные различия).

type Point struct {
    X, Y int
}
type Bag struct {
    Items []string
}

fmt.Println(Point{1, 2} == Point{1, 2}) // true
// _ = Bag{} == Bag{}                   // ошибка компиляции: invalid operation:
//                                      // Bag{} == Bag{} (struct containing
//                                      // []string cannot be compared)

// Обходной путь для «глубокого» сравнения:
reflect.DeepEqual(a, b)      // медленно, но работает со всем
cmp.Equal(a, b)              // github.com/google/go-cmp — стандарт де-факто в тестах

Выравнивание. Процессор читает память словами, поэтому компилятор кладёт каждое поле по адресу, кратному его выравниванию (int64 — по 8, int32 — по 4, bool — по 1), а между полями вставляет padding. Размер всей структуры дополняется до кратного максимальному выравниванию полей, чтобы в массиве структур каждый следующий элемент тоже был выровнен. Go не переупорядочивает поля сам: порядок в исходнике = порядок в памяти.

$ go vet -vettool=$(which fieldalignment) ./...
$ fieldalignment -fix ./...        # умеет переставлять поля автоматически
$ go run honnef.co/go/tools/cmd/structlayout@latest -json pkg Bad

Анонимные структуры и функции

// 1. Табличные тесты, самый частый случай
tests := []struct {
    name string
    in   string
    want int
    err  bool
}{
    {"пусто", "", 0, true},
    {"обычный", "42", 42, false},
}

// 2. Одноразовый JSON-ответ, ради которого нет смысла заводить тип
json.NewEncoder(w).Encode(struct {
    Status string `json:"status"`
    Count  int    `json:"count"`
}{"ok", n})

// 3. Множество (set) с нулевым оверхедом на значение
seen := map[string]struct{}{}
seen["a"] = struct{}{}

// 4. Анонимные функции: замыкания, defer, горутины, функциональные опции
defer func() {
    if r := recover(); r != nil { log.Println("recovered:", r) }
}()

Пустая структура struct{} занимает 0 байт, а все её экземпляры лежат по одному адресу (runtime.zerobase). Отсюда идиомы map[T]struct{} для множества и chan struct{} для сигнального канала: памяти под значение не выделяется вообще.

type P struct {
    X int
}
a := P{1}; b := a; b.X = 9
// a.X == 1 — копия независима

s1 := []int{1, 2, 3}; s2 := s1; s2[0] = 9
// s1[0] == 9 — общий массив

arr1 := [3]int{1, 2, 3}; arr2 := arr1; arr2[0] = 9
// arr1[0] == 1 — массив копируется целиком

var i int8 = 127; i++            // -128
var u uint8 = 0;  u--            // 255

// Ловушка №1: обратный цикл по uint
for i := uint(3); i >= 0; i-- {  // бесконечный: uint всегда >= 0
}

// Ловушка №2: разность беззнаковых
var a, b uint = 2, 5
fmt.Println(a - b)               // 18446744073709551613

// Ловушка №3: проверка переполнения после операции
c := math.MaxInt64
c++                              // уже -9223372036854775808
if c < 0 { /* поздно, но так обычно и ловят */ }

// знаковые — руками:
func addSafe(a, b int64) (int64, error) {
    if (b > 0 && a > math.MaxInt64-b) || (b < 0 && a < math.MinInt64-b) {
        return 0, errors.New("overflow")
    }
    return a + b, nil
}
// сейчас для беззнаковых есть math/bits:
sum, carry := bits.Add64(x, y, 0)   // carry == 1 при переполнении

var m map[string]int
fmt.Println(m["x"], len(m))  // 0 0 — чтение ок
m["x"] = 1                   // panic: assignment to entry in nil map

var s []int
s = append(s, 1)             // ок: append работает и с nil-слайсом

var ch chan int
<-ch                         // висит навсегда (deadlock, если спят все горутины)

s := "Go♥"
fmt.Println(len(s))                    // 5: 'G','o' по 1 байту, '♥' — 3 байта
fmt.Printf("%T\n", s[0])               // uint8
for i, r := range s {
    fmt.Printf("%d:%c(%d) ", i, r, r)  // 0:G(71) 1:o(111) 2:♥(9829)
}
fmt.Println(utf8.RuneCountInString(s)) // 3
rs := []rune(s)                        // аллоцирует 3 × 4 = 12 байт
fmt.Println(len(rs))                   // 3

// От константы такие конверсии не скомпилируются,
// компилятор ловит их ещё при сборке:
//   int8(300)   → constant 300 overflows int8
//   int(2.99)   → cannot convert 2.99 (untyped float constant) to type int
//   uint(-1)    → constant -1 overflows uint

// А вот от переменной те же конверсии проходят молча:
var a int32 = 300
var b float64 = 2.99
var c int = -1

fmt.Println(int8(a))   // 44   — старшие биты отрезаны молча
fmt.Println(int(b))    // 2    — обрезает, а не округляет
fmt.Println(int(-b))   // -2   — к нулю, а не «вниз»
fmt.Println(uint(c))   // 18446744073709551615

string(65)         // "A"  — go vet ругается: подозрительная конверсия int→string
string([]byte{65}) // "A"  — а так правильно

const (
    A = iota      // 0
    B             // 1  — выражение "iota" унаследовано
    C             // 2
)
const (
    D = iota      // 0 — новый блок, счётчик сброшен
)

// iota считает строки, а не константы:
const (
    X, Y = iota, iota * 10   // X=0, Y=0
    Z, W                     // Z=1, W=10
)

// 1) Перечисление статусов, строки для них сгенерирует stringer
type Status int
const (
    StatusUnknown Status = iota
    StatusPending
    StatusDone
)
//go:generate stringer -type=Status

// 2) Размеры
const (
    _  = iota
    KB = 1 << (10 * iota)   // 1024
    MB                       // 1048576
)

// 3) Битовые маски
type Flag uint
const (
    FlagRead Flag = 1 << iota
    FlagWrite
    FlagExec
)

// 4) Пропуск ненужных значений
const (
    _ = iota
    First   // 1 — чтобы zero value означал "не задано"
    Second
)

switch v := x.(type) {
case nil:
    fmt.Println("nil интерфейс")
case int, int64:
    fmt.Printf("целое, но v тут ещё any: %T\n", v)
case fmt.Stringer:
    fmt.Println(v.String())   // v уже fmt.Stringer
default:
    fmt.Printf("%T\n", v)
}

switch {                      // без выражения
case n < 0:  return "neg"
case n == 0: return "zero"
default:     return "pos"
}

switch n {
case 1:
    fmt.Println("один")
    fallthrough               // безусловно выполнит тело case 2
case 2:
    fmt.Println("два")
}
// при n == 1 вывод:
// один
// два

for i := 0; i < 3; i++ {
    switch i {
    case 1:
        break            // выходит из switch, НЕ из цикла
    }
    fmt.Print(i)
}

const c = 1 << 100          // ок, пока не присвоено переменной
fmt.Println(c >> 98)        // 4

const half = 1 / 2          // 0 — целочисленное деление констант
const halfF = 1.0 / 2       // 0.5 — одна из констант вещественная

var f float64 = 3           // 3 подстроится под float64
var d time.Duration = 5     // ок: нетипизированная 5 станет Duration
var n int = 5
// var d2 time.Duration = n // ошибка: int → Duration неявно нельзя

// Типы по умолчанию, если контекста нет:
x := 42        // int
y := 4.2       // float64
z := 'a'       // rune (int32)
s := "hi"      // string
b := true      // bool

type A struct {
    X int
    S string
}        // comparable
type B struct {
    Items []int
}            // не comparable
_ = A{1,"a"} == A{1,"a"}                // true
// _ = B{} == B{}                       // compile error

// С интерфейсным полем структура comparable, но в рантайме может запаниковать:
type C struct {
    V any
}
_ = C{1} == C{1}                        // true
_ = C{[]int{1}} == C{[]int{1}}          // panic: comparing uncomparable type []int

type Bad struct {           // 24 байта
    a bool                  // 1 + 7 padding
    b int64                 // 8
    c bool                  // 1 + 7 padding (добивка до кратного 8)
}
type Good struct {          // 16 байт
    b int64                 // 8
    a bool                  // 1
    c bool                  // 1 + 6 padding
}
unsafe.Sizeof(Bad{})        // 24
unsafe.Sizeof(Good{})       // 16
unsafe.Alignof(Bad{})       // 8
unsafe.Offsetof(Bad{}.b)    // 8

cfg := struct {
    Host string
    Port int
}{"localhost", 8080}

var payload struct {
    Email string `json:"email"`
}
if err := json.NewDecoder(r.Body).Decode(&payload); err != nil { ... }

// функциональные опции: на собесах по архитектуре их спрашивают чаще всего
type Option func(*Server)

func WithTimeout(d time.Duration) Option { return func(s *Server) { s.timeout = d } }
func WithLogger(l *slog.Logger) Option   { return func(s *Server) { s.log = l } }

func New(addr string, opts ...Option) *Server {
    s := &Server{addr: addr, timeout: 5 * time.Second}
    for _, o := range opts { o(s) }
    return s
}

1.2Массивы и слайсы

Тема номер один для отсева. По слайсам видно всё сразу: понимает ли человек, что лежит в памяти, умеет ли рассуждать про совместное владение данными и про то, где рантайм делает копию, а где нет. Заучивать тут нечего, надо уметь вывести ответ из устройства заголовка. Тогда любая задача «что выведет код» решается за десять секунд.

Зачем вообще лезть слайсу внутрь

На каждом собесе в разных обёртках спрашивают одно и то же: я передал слайс дальше (в функцию, в горутину, положил в структуру), увидит ли он мои изменения, и увижу ли я его? Списком случаев это не запомнить, случаев десятки. Ответ выводится из того, что физически лежит в переменной типа []int. Разобрался один раз, дальше не гадаешь, а считаешь.

К концу главы ты объяснишь, почему запись s[0] = 1 внутри функции видна снаружи, а append нет; почему два слайса иногда «мешают» друг другу, а потом внезапно перестают; почему маленький кусочек большого ответа сервера держит в памяти весь ответ целиком.

Массив: длина — часть типа

Массив в Go хранит фиксированное число элементов, они лежат в памяти подряд. Дальше всё держится на одном: длина входит в тип. [3]int и [4]int считаются разными типами, и функция, принимающая [3]int, не примет [4]int. Длина обязана быть константным выражением, известным на этапе компиляции.

var a [3]int                 // [0 0 0]
b := [3]int{1, 2, 3}
c := [...]int{1, 2, 3, 4}    // [4]int — компилятор посчитал длину сам
d := [5]int{2: 9}            // [0 0 9 0 0] — индексированный литерал

fmt.Printf("%T %T\n", b, c)  // [3]int [4]int — разные типы
// b = c                     // ошибка компиляции:
//                           // cannot use c (variable of type [4]int) as [3]int value in assignment

e := b                       // копия всех 24 байт
e[0] = 99
fmt.Println(b[0], e[0])      // 1 99 — независимы

fmt.Println(b == [3]int{1,2,3}) // true — массивы comparable, если comparable элементы

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

• Фиксированные буферы и хеши: [32]byte для SHA-256, [16]byte для UUID. Значение целиком, без указателя, без аллокации, comparable, годится в ключи мапы.
• Ключи мапы: map[[2]int]bool работает, а map[[]int]bool нет.
• Стековые буферы: var buf [64]byte; s := buf[:]. Массив остаётся на стеке, если не убегает, и слайс над ним не даёт аллокации в куче.

Слайс — это структура из трёх полей

1. Что такое «заголовок» и почему это не страшное слово

Заголовок сам данных не содержит. Это маленькая служебная структурка, она только описывает, где данные лежат и сколько их. Как наклейка на коробке: «полка 3, коробка 12, внутри 40 болтов». Наклейку можно скопировать, переписать, отдать другому человеку, а коробка от этого не раздвоится и не переедет.

Переменная типа []int и есть такая наклейка. Сами числа лежат отдельно, в обычном массиве где-то в памяти. В переменной их нет.

2. Почему полей ровно три

Чтобы описать «окно» в чужом массиве, надо знать три вещи. Каждая отвечает на свой вопрос:

• array: где начинается окно. Адрес первого элемента, который слайсу «виден». Без него до данных не добраться.
• len: сколько элементов сейчас в окне. Это вернёт len(s), по этому пройдётся range, а за этой границей индексация даёт панику.
• cap: сколько места есть в запасе, то есть сколько элементов помещается от начала окна до конца массива. Это поле отвечает на вопрос «переживёт ли следующий append без переезда в новую память».

Убери любое из трёх, и что-то отвалится. Без len не проверить выход за границы, без cap append не знает, можно ли дописать на месте. Три поля тут не от исторической случайности: меньше просто не хватает.

3. Три слова, которые дальше встречаются на каждой странице

• Ёмкость (cap): сколько элементов слайс вместит без выделения новой памяти. Не путать с длиной. Длина считает элементы, которые реально есть; ёмкость показывает, сколько их влезет в уже выделенный кусок. make([]int, 3, 10) даёт три элемента и место ещё под семь.
• Базовый массив: тот самый непрерывный кусок памяти с элементами, на который смотрит слайс. Владеет им слайс не единолично. На один массив смотрит сколько угодно слайсов, и запись через любой из них видна всем остальным.
• Реаллокация (она же перевыделение): старый базовый массив перестал вмещать данные, рантайм выделил кусок побольше, скопировал туда всё содержимое и переставил указатель в заголовке. Слайсы, которые смотрели на прежний массив, продолжают смотреть на прежний массив, и связь с новым слайсом рвётся. Отсюда и берутся «магические» задачи про append.

В рантайме всё выглядит буднично. Никакого «динамического массива» нет, есть заголовок (slice header): три машинных слова, описывающих окно в чужой памяти. Сама память лежит в отдельном массиве, слайсу он не принадлежит и бывает общим у нескольких слайсов.

// runtime/slice.go: вот что лежит в переменной типа []T
type slice struct {
    array unsafe.Pointer // указатель на первый элемент окна
    len   int            // сколько элементов видно
    cap   int            // сколько элементов есть от array до конца массива
}
// на 64-битной платформе: 8 + 8 + 8 = 24 байта
fmt.Println(unsafe.Sizeof([]int{}))   // 24

У слайса три инварианта, и из них выводится всё остальное поведение: 0 <= len <= cap; len держит границу индексации (за ней паника index out of range); cap держит границу нарезки (s[:cap(s)] легально, s[:cap(s)+1] уже паника).

Три способа создать слайс (и ещё пара)

make([]T, 0, n) это преаллокация: «мне нужно место под n элементов, но пока их ноль». Смысл в том, чтобы append не пересоздавал массив по дороге. Разница видна на бенчмарке: без ёмкости на 10 000 элементов будет примерно 20 перевыделений и столько же копирований всего содержимого, суммарно около 20 000 скопированных элементов вместо 10 000 записей.

// Плохо: 0 → 1 → 2 → 4 → 8 → ... → 16384, ~20 аллокаций и копирований
func bad(n int) []int {
    var s []int
    for i := 0; i < n; i++ { s = append(s, i) }
    return s
}

// Хорошо: одна аллокация, append только пишет
func good(n int) []int {
    s := make([]int, 0, n)
    for i := 0; i < n; i++ { s = append(s, i) }
    return s
}

// Частая ошибка: make([]T, n) вместо make([]T, 0, n)
func wrong(n int) []int {
    s := make([]int, n)              // len == n, слайс уже полон нулей
    for i := 0; i < n; i++ { s = append(s, i) }
    return s                          // длина 2n: n нулей, потом n значений
}

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

Слайс передаётся по значению, как и всё в Go. Копируются 24 байта заголовка; поле array в копии указывает на тот же массив. Отсюда правило, которое надо уметь проговорить одной фразой: функция может изменить элементы, но не может изменить длину слайса у вызывающего, потому что len лежит в копии.

func modify(s []int)   { s[0] = 100 }        // видно снаружи: общий массив
func grow(s []int)     { s = append(s, 4) }  // не видно: изменили копию заголовка
func growP(s *[]int)   { *s = append(*s, 4) }// видно: пишем в саму переменную

s := []int{1, 2, 3}
modify(s); fmt.Println(s)   // [100 2 3]
grow(s);   fmt.Println(s)   // [100 2 3] — длина не изменилась
growP(&s); fmt.Println(s)   // [100 2 3 4]

Указатель на слайс (*[]T) в прикладном коде почти не нужен: идиоматично вернуть новый слайс (s = f(s)), ровно так устроен сам append. *[]T оправдан в горячих местах, где надо наполнять переданный буфер без возврата, и когда пишешь json.Unmarshaler / sql.Scanner.

append: единственное место, где массив может смениться

append не метод и не обычная функция, а встроенная: компилятор разворачивает её вызов в инлайновый код. Логика такая:

1. Посчитать нужную длину: newLen = len(s) + len(добавляемого).
2. Если newLen <= cap(s), то ничего не выделять: записать элементы в существующий массив начиная с индекса len(s) и вернуть заголовок с новым len.
3. Иначе вызвать runtime.growslice: посчитать новый cap, выделить новый массив, скопировать в него старые элементы (memmove), дописать новые, вернуть новый заголовок.

Из шага 2 растёт вся «магия» слайсов: при достаточном cap append молча пишет в память, которую видят и другие слайсы. Из шага 3 растёт другое: после роста связь с исходным массивом теряется.

Стратегия роста capacity

Считает её runtime.growslice в runtime/slice.go. Наивное «всегда x2» уже несколько лет неверный ответ. Алгоритм двухступенчатый, а сверху ещё накладывается округление до классов размеров аллокатора.

// Быстрее всего проверить руками, что «всегда x2» неверно
s := make([]int, 0)
prev := 0
for i := 0; i < 5000; i++ {
    s = append(s, i)
    if cap(s) != prev {
        fmt.Printf("len=%-5d cap=%-6d x%.2f\n", len(s), cap(s), float64(cap(s))/float64(max(prev,1)))
        prev = cap(s)
    }
}
// Прогон на go1.27, []int, пары len cap:
// 1 4 | 5 8 | 9 16 | 17 32 | 33 64 | 65 128 | 129 256 | 257 512
// 513 848 | 849 1280 | 1281 1792 | 1793 2560 | 2561 3408 | 3409 5120
// Первый же append даёт cap=4, а не 1: с Go 1.25 слайсу, который не убегает,
// компилятор даёт стартовый буфер в 32 байта на стеке, отсюда cap = 32/размер —
// []byte → 32, []int32 → 8, []int/[]int64 → 4, []string → 2, struct{4 int} → 1.
// До 256 элементов ровно x2, после 256 множитель падает
// (x1.66, x1.51, x1.40...), а «некруглые» цифры даёт roundupsize.

Full slice expression: третий индекс

s[low:high:max] задаёт len = high-low и cap = max-low. Ограничение low <= high <= max <= cap(s). Зачем: чтобы отобрать у подслайса право писать в чужой хвост. Без третьего индекса подслайс наследует cap до конца массива, и первый же append в него молча затрёт элементы соседа.

base := []int{1, 2, 3, 4, 5}

a := base[0:2]        // len=2 cap=5  — опасно
a = append(a, 99)
fmt.Println(base)     // [1 2 99 4 5]  ← затёрли base[2]

base = []int{1, 2, 3, 4, 5}
b := base[0:2:2]      // len=2 cap=2  — безопасно
b = append(b, 99)     // cap исчерпан → новый массив
fmt.Println(base, b)  // [1 2 3 4 5] [1 2 99]

Утечки памяти через подслайсы

Сборщик мусора в Go работает с объектами целиком: он не умеет освободить «хвост» массива, если на его начало кто-то смотрит. Один живой слайс на пять элементов удерживает в куче весь массив на десять миллионов. Ровно та же история со строками и с []byte из io.ReadAll.

// Утечка: маленький результат держит гигантский вход
func firstLine(data []byte) []byte {
    i := bytes.IndexByte(data, '\n')
    return data[:i]                     // держит весь data
}

// Лечим
func firstLineOK(data []byte) []byte {
    i := bytes.IndexByte(data, '\n')
    return bytes.Clone(data[:i])        // Go 1.20+; до него — append([]byte(nil), data[:i]...)
}

// Вторая утечка: элементы-указатели остаются достижимыми после «удаления»
func pop(s []*Item) []*Item {
    last := len(s) - 1
    s[last] = nil                       // без этого Item жив, хоть и вне len
    return s[:last]
}

Удаление элементов и сложность операций

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

// Фильтрация без аллокации: пишем в тот же массив
s = s[:0]
for _, v := range src {
    if keep(v) { s = append(s, v) }
}

// Очередь на слайсе: s = s[1:] в бесконечном цикле даёт утечку
q := make([]int, 0, 8)
for {
    q = append(q, produce())   // хвост растёт вправо
    head := q[0]
    q = q[1:]                  // окно ползёт вправо, cap уменьшается
    _ = head
    // cap(q) убывает → append периодически выделяет новый массив и копирует,
    // а «отрезанное» начало старого массива недостижимо, но живо до следующего роста.
    // Память пилообразно растёт. Правильно: кольцевой буфер, container/list,
    // или copy(q, q[1:]); q = q[:len(q)-1]
}

copy: семантика

n := copy(dst, src) копирует min(len(dst), len(src)) элементов и возвращает это число. Обрати внимание: смотрит на len, а не на cap, вот самая частая ошибка. При перекрытии областей копирование тоже работает корректно (внутри memmove). Особый случай: copy(dst []byte, src string) разрешён.

src := []int{1, 2, 3, 4, 5}

dst := make([]int, 3)
fmt.Println(copy(dst, src), dst)   // 3 [1 2 3]

bad := make([]int, 0, 10)
fmt.Println(copy(bad, src), bad)   // 0 [] — len(dst)==0, ничего не скопировалось

ok := make([]int, len(src))
copy(ok, src)                      // 5

// Сдвиг влево с перекрытием работает как надо
copy(src, src[1:])                 // [2 3 4 5 5]

n := copy(make([]byte, 4), "привет") // 4 байта строки

nil-слайс и пустой слайс

Сравнение и многомерность

Слайсы не comparable: == для них запрещён компилятором (разрешено только сравнение с nil). Причина не техническая, а семантическая: непонятно, что считать равенством, совпадение заголовков, поэлементное сравнение или глубокое? Go отказался выбирать. Сравнивают через slices.Equal (быстро, поэлементно, без рефлексии), slices.EqualFunc, bytes.Equal для []byte или reflect.DeepEqual (медленно, но «глубоко»).

a := []int{1, 2, 3}
b := []int{1, 2, 3}
// _ = a == b                      // ошибка: slice can only be compared to nil
fmt.Println(slices.Equal(a, b))    // true    (Go 1.21+)
fmt.Println(reflect.DeepEqual(a,b))// true, но в ~100 раз медленнее
fmt.Println(bytes.Equal([]byte("x"), []byte("x"))) // true

// DeepEqual считает nil и пустой слайс разными
fmt.Println(reflect.DeepEqual([]int(nil), []int{}))  // false
fmt.Println(slices.Equal([]int(nil), []int{}))       // true — сравнивает содержимое

Многомерного слайса в Go нет, есть слайс слайсов. Каждая строка это отдельный заголовок и отдельный массив, строки бывают разной длины (jagged), и памяти это стоит дороже, чем плоский массив.

// Обычный способ: n аллокаций + 1
grid := make([][]int, rows)
for i := range grid { grid[i] = make([]int, cols) }

// Ловушка: одна общая строка на всех
row := make([]int, cols)
bad := make([][]int, rows)
for i := range bad { bad[i] = row }   // все строки — один массив
bad[0][0] = 7
fmt.Println(bad[1][0])                // 7

// Быстрый способ: одна аллокация, лучшая локальность
flat := make([]int, rows*cols)
grid2 := make([][]int, rows)
for i := range grid2 { grid2[i] = flat[i*cols : (i+1)*cols : (i+1)*cols] }

Что выведет код?

// (A)
s1 := []int{1, 2, 3, 4, 5}
s2 := s1[1:3]
s2[0] = 99
s2 = append(s2, 100)
fmt.Println(s1)
fmt.Println(s2, len(s2), cap(s2))

// (B)
a := make([]int, 3, 4)
b := append(a, 1)
c := append(a, 2)
b[0] = 7
fmt.Println(a, b, c)
fmt.Println(b[3], c[3])

(A) → [1 99 3 100 5], затем [99 3 100] 3 4. s2 имеет len=2, cap=4 (от индекса 1 до конца массива), поэтому append не выделяет новый массив, а пишет в s1[3].

(B) → [7 0 0] [7 0 0 2] [7 0 0 2], затем 2 2. У a есть запас cap=4, поэтому оба append ничего не выделяют, а пишут в одну и ту же ячейку с индексом 3: второй затёр единицу двойкой. b, c и a смотрят в один массив тремя заголовками, поэтому b[0] = 7 видно везде. Если бы a создали как make([]int, 3) (то есть cap=3), каждый append выделил бы свой массив и ответ стал бы [0 0 0] [7 0 0 1] [0 0 0 2], а b[0] = 7 было бы видно только в b. На этой развилке и ловят: решай по картинке заголовков, а не по интуиции.

arr := [3]int{1, 2, 3}
sl  := []int{1, 2, 3}
fmt.Println(unsafe.Sizeof(arr), unsafe.Sizeof(sl))  // 24 24 — совпало случайно
arr2 := [10]int{}
sl2  := make([]int, 10)
fmt.Println(unsafe.Sizeof(arr2), unsafe.Sizeof(sl2)) // 80 24

type slice struct {          // runtime/slice.go
    array unsafe.Pointer
    len   int
    cap   int
}

s := make([]int, 3, 10)
fmt.Println(len(s), cap(s))        // 3 10
t := s[2:]
fmt.Println(len(t), cap(t))        // 1 8  — cap уменьшился на смещение
u := s[:cap(s)]
fmt.Println(len(u), cap(u))        // 10 10 — «расширили» окно до cap

// Посмотреть на указатель без reflect.SliceHeader (он deprecated с Go 1.21):
fmt.Printf("%p %p\n", unsafe.SliceData(s), unsafe.SliceData(t)) // t сдвинут на 16 байт

a := []int{1, 2, 3}          // 1) литерал: len=3 cap=3
b := make([]int, 5)          // 2) make: len=5 cap=5, заполнен нулями
c := make([]int, 0, 5)       //    make с cap: len=0 cap=5
d := arr[1:4]                // 3) нарезка: делит массив с arr
var e []int                  // +  nil-слайс: len=0 cap=0, аллокации нет
f := new([5]int)[:]          // +  экзотика: массив в куче + слайс на него

// Типичная разница на бенчмарке (n = 10 000, []int)
// BenchmarkNoPrealloc   ~ 45 000 ns/op   386 KB/op   20 allocs/op
// BenchmarkPrealloc     ~  9 000 ns/op    81 KB/op    1 allocs/op

// Чаще всего это забывают при маппинге из БД/gRPC:
out := make([]DTO, 0, len(rows))     // длина известна заранее — грех не воспользоваться
for _, r := range rows { out = append(out, toDTO(r)) }

func setFirst(s []int) { s[0] = 100 }          // видно снаружи
func appendOne(s []int) { s = append(s, 4) }   // не видно
func clear(s []int) { s = nil }                // не видно
func appendPtr(s *[]int) { *s = append(*s, 4) }// видно

s := []int{1, 2, 3}
setFirst(s);  fmt.Println(s)  // [100 2 3]
appendOne(s); fmt.Println(s)  // [100 2 3]
clear(s);     fmt.Println(s)  // [100 2 3]
appendPtr(&s); fmt.Println(s) // [100 2 3 4]

func addOne(s []int) []int {
    s = append(s, 42)
    s[0] = -1
    return s
}

// Случай 1: cap хватает
a := make([]int, 3, 10)          // len=3 cap=10
b := addOne(a)
fmt.Println(a, len(a), cap(a))   // [-1 0 0] 3 10   ← a[0] изменился
fmt.Println(b, len(b), cap(b))   // [-1 0 0 42] 4 10
fmt.Println(&a[0] == &b[0])      // true — один массив

// Случай 2: cap не хватает
c := make([]int, 3, 3)           // len=3 cap=3
d := addOne(c)
fmt.Println(c, len(c), cap(c))   // [0 0 0] 3 3     ← c не тронут
fmt.Println(d, len(d), cap(d))   // [-1 0 0 42] 4 6
fmt.Println(&c[0] == &d[0])      // false — разные массивы

s1 := []int{0, 1, 2, 3, 4, 5, 6, 7}
s2 := s1[2:5]                 // len=3, cap=6 (от индекса 2 до конца массива)

s2[0] = 99
fmt.Println(s1)               // [0 1 99 3 4 5 6 7]  ← запись видна

s2 = append(s2, 100)          // len 3→4, cap 6 — места хватает
fmt.Println(s1)               // [0 1 99 3 4 100 6 7] ← затёрли s1[5]
fmt.Println(s2)               // [99 3 4 100]

s1 := []int{0, 1, 2, 3, 4}
s2 := s1[2:5]                 // len=3, cap=3 — окно упирается в конец массива
s2 = append(s2, 100)          // cap исчерпан → новый массив
fmt.Println(s1, s2)           // [0 1 2 3 4] [2 3 4 100]

// Явная защита — full slice expression:
s3 := s1[2:5:5]               // cap=3 принудительно
// или
s4 := slices.Clip(s1[2:5])    // то же самое, читаемее

s1 := make([]int, 100)
for i := range s1 { s1[i] = i }

sub := s1[30:40]                       // len=10, cap=70
_ = json.Unmarshal([]byte(`[1,2,3]`), &sub)

fmt.Println(sub)          // [1 2 3]   — len стал 3, cap остался 70
fmt.Println(s1[28:44])    // [28 29 1 2 3 33 34 35 36 37 38 39 40 41 42 43]
//                              ^^^^^^  затёрли s1[30..32]: массив тот же, не копия
// Хвост (s1[33..39]) декодер не трогает: он просто ставит len=3,
// а старые элементы остаются лежать в массиве.

// Начало, O(1): просто сдвигаем окно
s = s[1:]                       // массив тот же, начало недостижимо, но живо

// Начало, O(n): сдвигаем данные, окно остаётся на месте
s = append(s[:0], s[1:]...)     // или copy(s, s[1:]); s = s[:len(s)-1]

// Середина с сохранением порядка, O(n)
s = append(s[:i], s[i+1:]...)   // классика
s = slices.Delete(s, i, i+1)    // Go 1.22+: то же самое, но зануляет хвост

// Середина без сохранения порядка, O(1)
s[i] = s[len(s)-1]
s[len(s)-1] = zero              // обнулить, если элементы содержат указатели
s = s[:len(s)-1]

// Конец, O(1)
s[len(s)-1] = zero
s = s[:len(s)-1]

// Пачкой по предикату, O(n) и без аллокаций
s = slices.DeleteFunc(s, func(v T) bool { return !keep(v) })

// Проверим на деле
s := make([]int, 0, 4)
for i := 0; i < 12; i++ {
    s = append(s, i)
    s = s[1:]
    fmt.Println(i, len(s), cap(s))
}
// вывод (go1.27), i len cap:
// 0 0 3 | 1 0 2 | 2 0 1 | 3 0 0   ← окно доехало до конца исходного массива
// 4 0 3 | 5 0 2 | 6 0 1 | 7 0 0   ← append выделил новый массив (cap=4), и всё повторилось
// 8 0 0 | 9 0 0 | 10 0 0 | 11 0 0 ← дальше каждый append выделяет память заново
// Какой cap даст очередная переаллокация, решает аллокатор (тут 4, потом 1),
// но cap монотонно тает до нуля, и с этого момента каждая итерация
// это отдельная аллокация. Хуже некуда.

// 1) Кольцевой буфер: O(1) на push и pop, память не растёт
type Ring[T any] struct {
    buf        []T
    head, tail int
    size       int
}

// 2) Остаёмся на слайсе, но сдвигаем данные, а не окно
head := q[0]
q[0] = zero
copy(q, q[1:])
q = q[:len(q)-1]      // O(n) на pop, зато массив не «уползает»

// 3) Периодически уплотняем: голова ушла далеко, пора переезжать
if offset > len(q) {
    q = append(q[:0:0], q...)   // новый массив ровно по размеру
    offset = 0
}

// 4) Для очереди между горутинами хватит канала

func loadAndKeepPrefix(path string) []byte {
    data, _ := os.ReadFile(path)      // 100 МБ
    return data[:16]                  // держит все 100 МБ
}

func loadOK(path string) []byte {
    data, _ := os.ReadFile(path)
    return bytes.Clone(data[:16])     // 16 байт, остальное соберёт GC
}

buf := make([]byte, 0, 1024)
buf = append(buf, "header"...)

// Отдаём наружу кусок своего буфера
view  := buf[0:6]      // cap = 1024 — вызывающий сделает append и затрёт наш буфер
safe  := buf[0:6:6]    // cap = 6    — любой append у вызывающего выделит свою память
safe2 := slices.Clip(buf[0:6])  // то же самое, читаемее (Go 1.21+)

n := copy(dst, src)

dst := make([]int, 0, 100)      // len=0
src := []int{1, 2, 3}
fmt.Println(copy(dst, src))     // 0 — ничего не скопировано

dst2 := make([]int, 3)
fmt.Println(copy(dst2, src))    // 3

dst3 := make([]int, 10)
fmt.Println(copy(dst3, src))    // 3 — остальные 7 остались нулями

// Идиома «клонировать»: три эквивалентных варианта
c1 := slices.Clone(s)                   // Go 1.21+, читаемо
c2 := append([]int(nil), s...)          // работает везде
c3 := make([]int, len(s)); copy(c3, s)  // самый явный

// Идиома «дописать строку в байтовый буфер без аллокации»
buf = append(buf, "hello"...)           // да, так можно

s := make([]int, 3, 3)
p := &s[0]
*p = 10
fmt.Println(s)        // [10 0 0]

s = append(s, 4)      // cap исчерпан → новый массив
*p = 99
fmt.Println(s, *p)    // [10 0 0 4] 99 — запись ушла в старый массив, s её не видит

// 1) Цикл range даёт копию элемента: &v это адрес копии
for _, v := range items {
    register(&v)          // до Go 1.22 — один адрес на все вызовы; с 1.22 разные, но это копии
}
for i := range items {
    register(&items[i])   // правильно
}

// 2) Указатели на элементы + append в том же цикле
var ptrs []*Item
for i := range items {
    ptrs = append(ptrs, &items[i])
    items = append(items, newItem())   // ← массив переехал, ptrs протухли
}

// 3) Метод с pointer receiver у элемента слайса
type Counter struct {
    n int
}
func (c *Counter) Inc() { c.n++ }
cs := []Counter{{}, {}}
cs[0].Inc()               // ок: компилятор берёт &cs[0]
for _, c := range cs { c.Inc() }   // бесполезно: инкрементим копию

var a []int          // nil-слайс:   array=nil
b := []int{}         // пустой:      array=&runtime.zerobase
c := make([]int, 0)  // пустой

fmt.Println(a == nil, b == nil, c == nil)   // true false false
fmt.Println(len(a), cap(a), len(b), cap(b)) // 0 0 0 0

a = append(a, 1)     // работает: append умеет растить nil
for range a {}       // работает
fmt.Println(a[0])    // 1

j1, _ := json.Marshal(struct {
    S []int
}{nil})     // {"S":null}
j2, _ := json.Marshal(struct {
    S []int
}{[]int{}}) // {"S":[]}

a, b := []int{1,2,3}, []int{1,2,3}
// a == b     // ошибка компиляции:
//            // invalid operation: a == b (slice can only be compared to nil)
fmt.Println(a == nil)                        // false — с nil сравнивать можно

slices.Equal(a, b)                           // true, Go 1.21+, O(n), без рефлексии
slices.EqualFunc(a, b, func(x, y int) bool { return x == y })
bytes.Equal([]byte("a"), []byte("a"))        // для []byte быстрее всего
reflect.DeepEqual(a, b)                      // true, но медленно и nil != []T{}

// Множества сортируем и сравниваем
slices.Sort(a); slices.Sort(b)
fmt.Println(slices.Equal(a, b))              // true

// В тестах
if diff := cmp.Diff(want, got); diff != "" { t.Errorf("mismatch (-want +got):\n%s", diff) }

// Правильно: rows+1 аллокаций
grid := make([][]int, rows)
for i := range grid {
    grid[i] = make([]int, cols)
}

// Ловушка 1: одна строка на всех
row := make([]int, cols)
bad := make([][]int, rows)
for i := range bad { bad[i] = row }
bad[0][0] = 7
fmt.Println(bad[1][0])         // 7 — все строки указывают на один массив

// Ловушка 2: копия неглубокая
cp := make([][]int, len(grid))
copy(cp, grid)                 // скопировали заголовки, данные общие
cp[0][0] = 9
fmt.Println(grid[0][0])        // 9

// Ловушка 3: append к строке может её «отвязать»
grid[0] = append(grid[0], 1)   // если cap исчерпан — новый массив только у этой строки

type Matrix struct {
    data       []float64
    rows, cols int
}
func New(rows, cols int) *Matrix {
    return &Matrix{data: make([]float64, rows*cols), rows: rows, cols: cols}
}
func (m *Matrix) At(i, j int) float64     { return m.data[i*m.cols+j] }
func (m *Matrix) Set(i, j int, v float64) { m.data[i*m.cols+j] = v }

// Или гибрид: одна аллокация + удобная индексация grid[i][j]
flat := make([]int, rows*cols)
grid := make([][]int, rows)
for i := range grid {
    grid[i] = flat[i*cols : (i+1)*cols : (i+1)*cols]
}

1.3Мапы

Вторая по частоте тема после слайсов. Спрашивают не «как положить ключ», а почему нельзя взять адрес значения, почему порядок обхода случайный, что именно происходит при конкурентной записи и как мапа растёт. Ответы на всё это прячутся в устройстве хеш-таблицы, с него и начнём.

Что такое мапа и какой у неё контракт

Под map[K]V лежит хеш-таблица. Контракт языка: амортизированные O(1) на вставку, поиск и удаление; ключи должны быть comparable; порядок обхода не определён; мапа не потокобезопасна. Переменная типа map[K]V хранит один указатель (8 байт) на структуру runtime.hmap в куче. Копируешь мапу, копируешь только этот указатель, а nil-мапа и есть нулевой указатель.

m := map[string]int{"a": 1}
m2 := m                 // скопировали 8 байт указателя
m2["b"] = 2
fmt.Println(m)          // map[a:1 b:2] — одна и та же таблица
fmt.Println(unsafe.Sizeof(m))   // 8

Зачем лезть внутрь и пять слов, без которых дальше не разобрать

Почти все «странности» мапы (запрет на &m[k], случайный порядок обхода, падение всей программы при конкурентной записи, память, которая не возвращается после удаления ключей) растут из устройства хеш-таблицы: это прямые следствия, а не капризы дизайнеров. Разберёшь устройство, и эти вопросы перестанут быть списком для зубрёжки.

Но сначала пять слов. Дальше они встречаются в каждом абзаце.

1. Хеш-функция — превращает ключ в число

Хеш-функция берёт ключ любого размера (строку на 200 символов, структуру, число) и выдаёт одно число фиксированной длины, хеш. Требований два: одинаковые ключи всегда дают одинаковый хеш, разные дают по возможности разные и равномерно разбросанные. Обратно из хеша ключ не восстановить, да и не нужно: хеш работает как «номерок», по нему понятно, где искать.

2. Бакет (bucket) — корзина, в которую складывают ключи с одинаковым номерком

Внутри мапы массив корзин. Хеш ключа определяет номер корзины: взяли несколько младших бит хеша, получили индекс в массиве. Бакет и есть одна такая корзина; в классической реализации Go в неё помещается ровно 8 пар «ключ-значение».

Аналогия: камера хранения, где ячейки подписаны буквами. Фамилия «Петров» всегда идёт в ячейку «П», обходить все ячейки не надо, идёшь сразу в нужную. Отсюда и O(1) вместо O(n): ты не перебираешь ключи, а сразу прыгаешь в одну корзину.

3. Коллизия — два разных ключа попали в одну корзину

Коллизия случается, когда хеши двух разных ключей указали на один и тот же бакет. Не ошибка и не редкость: корзин конечное число, ключей сколько угодно. Хеш-таблица обязана уметь с ними жить: в бакете лежит несколько пар, и при поиске ключ придётся сравнить с теми, кто уже там лежит. Чем больше коллизий, тем ближе поиск к линейному перебору. Отсюда и все разговоры про «хорошую» хеш-функцию.

4. tophash — быстрый фильтр, чтобы не трогать сами ключи

Сравнивать длинные строки-ключи дорого. Поэтому рядом с восемью слотами бакета Go держит массив из восьми байт: tophash хранит старший байт хеша каждого лежащего в слоте ключа, запомненный заранее. Поиск сначала пробегает эти восемь байт (одна кэш-линия, никаких разыменований) и сравнивает ключ целиком только там, где байт совпал. Значение 0 в tophash служебное, оно помечает пустой слот.

5. Эвакуация — переезд элементов в новый массив бакетов

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

Классическое устройство: hmap и бакеты (Go до 1.24)

Исторически (а в первых версиях со Swiss-мапами ещё и с GOEXPERIMENT=noswissmap) мапа Go устроена как массив бакетов с цепочками overflow-бакетов. Бакет вмещает ровно 8 пар ключ-значение.

Хеш-функция, seed и коллизии — подробности

Про хеш-функцию и коллизии договорились выше, дальше детали. Go выбирает хеш-функцию по типу ключа на этапе компиляции: для строк и байтовых срезов берётся memhash (на amd64 это вариант на инструкциях AES-NI, очень быстрый), числа прогоняются через простое смешивание, у структур комбинируются хеши полей.

Каждая мапа при создании получает свой случайный seed (hash0). Это защита от hash flooding: без seed злоумышленник, знающий алгоритм, подобрал бы ключи с одинаковыми хешами и превратил все операции в O(n). Классическая DoS-атака на веб-сервер, который кладёт заголовки запроса в мапу.

Коллизии Go разрешает методом цепочек (не по одному элементу, а бакетами по 8): сначала заполняются 8 слотов бакета, при переполнении выделяется overflow-бакет, дополнительная корзина на те же 8 слотов, она прицепляется к основной как вагон к вагону. Поиск идёт по цепочке, пока ключ не найдётся или вагоны не кончатся.

В Swiss Tables (Go 1.24+) подход другой, открытая адресация: лишних вагонов нет, при занятом месте элемент ложится в другую группу того же массива по заранее известному правилу («пробинг»). Разбросанных по куче overflow-бакетов и указателей между ними больше нет, значит и промахов кэша меньше.

Рост и эвакуация

Мапа растёт, когда срабатывает одно из двух условий:

• Превышен load factor. Load factor считается как «сколько элементов лежит» на «сколько корзин есть». Чем он выше, тем плотнее набиты бакеты и тем длиннее цепочки при поиске. Порог в Go: count > 6.5 * 2^B, то есть в среднем больше 6.5 элементов на бакет при вместимости 8. Тогда B растёт на единицу, а бакетов становится вдвое больше.
• Слишком много overflow-бакетов при нормальной заполненности. Так бывает после массовых удалений. Тогда включается sameSizeGrow: массив бакетов того же размера, но элементы перекладываются плотно, и мусорные overflow-цепочки исчезают.

Переселение не происходит целиком за одну операцию. Разом оно убило бы время отклика на больших мапах: одна невезучая вставка встала бы на сотни миллисекунд. Вместо этого старый массив остаётся в oldbuckets, а каждая вставка/удаление эвакуирует один-два бакета. Пока эвакуация идёт, чтение проверяет оба массива.

Go 1.24: Swiss Tables

В Go 1.24 мапу переписали целиком: вместо бакетов с overflow-цепочками пришёл Swiss Table, дизайн из absl::flat_hash_map (Google, 2017). Идея одна: отделить метаданные от данных, чтобы за одно обращение к памяти проверять сразу восемь слотов.

Почему нельзя взять адрес значения: &m[key]

Потому что адрес нестабилен. Мапа растёт, начинается эвакуация, и пары ключ-значение физически переезжают в другой массив бакетов. Разреши язык &m[k], и после первой же вставки указатель смотрел бы в старую память: тихие баги ровно того сорта, которого Go старается не иметь. У слайса такой проблемы нет, там переезжает весь массив сразу, а старый остаётся валидным до сборки.

m := map[string]int{"a": 1}
// p := &m["a"]        // ошибка компиляции: invalid operation: cannot take address of m["a"]
// m["a"]++            // а это можно: компилятор разворачивает в чтение + запись
// m["a"] += 5         // тоже можно

type S struct {
    N int
}
ms := map[string]S{"a": {1}}
// ms["a"].N = 2       // ошибка: cannot assign to struct field ms["a"].N in map
v := ms["a"]; v.N = 2; ms["a"] = v   // читаем, меняем, кладём обратно

// Или, что обычно правильнее, хранить указатели:
mp := map[string]*S{"a": {1}}
mp["a"].N = 2                        // работает: адресуем то, на что указывает значение

Почему порядок итерации случайный

Это намеренная защита от неявной зависимости. Порядок обхода и сам по себе зависит от размера таблицы, порядка вставок и seed; он менялся бы от версии к версии и от запуска к запуску. А окажись он стабильным «на практике», разработчики стали бы на него полагаться, и любое улучшение рантайма ломало бы прод. Поэтому команда Go пошла дальше и сделала рандомизацию явной: mapiterinit выбирает случайный стартовый бакет и случайное смещение внутри него на каждый range.

m := map[int]string{1: "a", 2: "b", 3: "c"}
for k := range m { fmt.Print(k, " ") }   // разный порядок при каждом запуске
// восемь запусков подряд дали: "1 2 3", "3 1 2", "1 2 3", "1 2 3",
// "1 2 3", "1 2 3", "2 3 1", "2 3 1" — на трёх ключах совпадения частые,
// но опираться на порядок нельзя

// Детерминированный обход: сортируем ключи
keys := make([]int, 0, len(m))
for k := range m { keys = append(keys, k) }
slices.Sort(keys)
for _, k := range keys { fmt.Println(k, m[k]) }

// Go 1.23+: то же короче
for _, k := range slices.Sorted(maps.Keys(m)) { fmt.Println(k, m[k]) }
// оба цикла печатают одно и то же, всегда:
// 1 a
// 2 b
// 3 c

nil-мапа и мутации во время итерации

var m map[string]int         // nil: указатель на hmap равен nil

fmt.Println(m == nil)        // true
fmt.Println(len(m))          // 0
fmt.Println(m["x"])          // 0 — чтение из nil-мапы легально
v, ok := m["x"]              // 0, false
for range m {}               // ноль итераций, без паники
delete(m, "x")               // no-op, без паники

m["x"] = 1                   // panic: assignment to entry in nil map

Асимметрия объясняется просто: чтение честно вернёт нулевое значение, не трогая память, а запись обязана эту память создать. Указатель nil означает, что создавать негде. Инициализировать мапу сам рантайм не может: переменная передана по значению, и новый указатель некуда записать.

Мутация во время range легальна, но с оговорёнными в спецификации последствиями: удалённый и ещё не пройденный ключ гарантированно не будет посещён; добавленный во время обхода ключ может быть посещён, а может и нет, спецификация этого не определяет.

// Безопасно удалять во время обхода
for k, v := range m {
    if v == 0 { delete(m, k) }   // ок, спецификация это разрешает
}

// Опасно добавлять во время обхода: обход может зациклиться или выдать не всё
for k := range m {
    m[k+1000] = 1                // попадёт ли новый ключ в обход, не определено
}

Конкурентный доступ: почему это fatal error, а не panic

Мапа не потокобезопасна, и рантайм за этим следит. В hmap.flags есть бит hashWriting: mapassign и mapdelete ставят его в начале работы и снимают в конце. Любая другая операция, увидев этот бит, немедленно валит процесс:

fatal error: concurrent map writes
fatal error: concurrent map read and map write

Это не паника, а throw из рантайма. Разницу спрашивают почти всегда: recover() такое не ловит, defer не выполняются, процесс умирает целиком с дампом всех горутин. Логика простая: структуру данных уже могло порвать, дальше выполнять небезопасно, лучше упасть громко и сразу.

Чем защищаться: RWMutex, sync.Map, шардирование

Шардирование: одну большую структуру режут на N независимых кусков, у каждого свой замок, а ключ по хешу попадает ровно в один кусок. Две горутины с разными ключами чаще всего берут разные замки и не мешают друг другу.

// Вариант 1 — мьютекс рядом с мапой. Дефолт в 90 % случаев.
type Cache struct {
    mu sync.RWMutex
    m  map[string]int
}

func (c *Cache) Get(k string) (int, bool) {
    c.mu.RLock()
    v, ok := c.m[k]        // много читателей одновременно — ок
    c.mu.RUnlock()
    return v, ok
}

func (c *Cache) Set(k string, v int) {
    c.mu.Lock()
    c.m[k] = v
    c.mu.Unlock()
}

// Вариант 2 — sync.Map. Только под два паттерна.
var sm sync.Map
sm.Store("a", 1)
v, ok := sm.Load("a")
actual, loaded := sm.LoadOrStore("b", 2)   // атомарно: получить-или-положить
sm.Range(func(k, v any) bool { return true })

// Вариант 3 — шардирование. Когда RWMutex стал узким местом.
type Shard struct {
    mu sync.RWMutex
    m  map[string]int
}
type Sharded [256]*Shard

func (s *Sharded) shard(k string) *Shard {
    return s[fnv32(k)%256]   // разные ключи — разные мьютексы
}

Какие типы могут быть ключами

Ключ обязан быть comparable, то есть к нему применим ==. Это все базовые типы, указатели, каналы, интерфейсы, массивы из comparable-элементов и структуры, у которых comparable все поля. Нельзя: слайсы, мапы, функции и любая структура, которая их содержит.

type Key struct {
    UserID int64
    Region string
}   // ок — оба поля comparable
m := map[Key]int{{1, "ru"}: 10}

type BadKey struct {
    Tags []string
}
// mb := map[BadKey]int{}   // ошибка компиляции: invalid map key type BadKey

// Массив можно, слайс нельзя, поэтому так:
m2 := map[[16]byte]string{}          // фиксированный размер = comparable
var id [16]byte
copy(id[:], someSlice)
m2[id] = "value"

// Или сериализуем ключ в строку (строка иммутабельна и comparable):
m3 := map[string]int{}
m3[strings.Join(tags, "\x00")] = 1

m := map[float64]string{}
m[math.NaN()] = "a"
m[math.NaN()] = "b"
fmt.Println(len(m))          // 2 — две записи по "одному" ключу
fmt.Println(m[math.NaN()])   // "" — не найдено
delete(m, math.NaN())        // ничего не удалит
for k, v := range m { fmt.Println(k, v) }  // обе записи видны, но только через range
// NaN a
// NaN b
// порядок между ними случайный: 5 прогонов дали 4 раза "a, b" и 1 раз "b, a"

Память: мапа не сжимается

delete помечает слот пустым и обнуляет ключ и значение (чтобы GC мог собрать то, на что они указывали), но массив бакетов не уменьшается никогда. Мапа, в которую положили 10 млн ключей и потом всё удалили, продолжает держать место под 10 млн, пока жива сама переменная.

m := make(map[int][128]byte)
for i := 0; i < 10_000_000; i++ { m[i] = [128]byte{} }
for i := 0; i < 10_000_000; i++ { delete(m, i) }
fmt.Println(len(m))   // 0 — а RSS процесса всё ещё гигабайты

// Вариант 1: пересоздать мапу и дать старой умереть
m = make(map[int][128]byte)

// Вариант 2 (Go 1.21+): clear() работает как delete всех ключей,
// то есть память тоже не отдаёт и пересоздание не заменяет.
clear(m)

// Вариант 3: хранить указатели, тогда «толстые» значения соберёт GC,
// а в бакетах останутся только 8-байтовые указатели
mp := make(map[int]*[128]byte)

Множество (set) через мапу

Отдельного типа set в стандартной библиотеке нет, вместо него пишут map[T]struct{}: struct{} занимает 0 байт, поэтому в бакете под массив значений память вообще не выделяется.

// Идиоматичный set
seen := make(map[string]struct{}, 1024)
seen["a"] = struct{}{}
if _, ok := seen["a"]; ok { /* есть */ }
delete(seen, "a")

// Альтернатива map[string]bool — до Go 1.24 на байт больше на элемент,
// зато читается лучше и можно писать одно выражение вместо comma-ok:
seenB := map[string]bool{}
seenB["a"] = true
if seenB["a"] { /* есть */ }   // false и для "нет ключа", и для "ключ есть, но false"

Сложность и деградация

Мапа деградирует в четырёх ситуациях:

• Плохой хеш / атака. Много ключей с одинаковыми низкими битами хеша → длинные overflow-цепочки → O(n) на операцию. От внешней атаки защищает случайный seed.
• Разреженность после удалений. Бакеты остались, элементов мало, обход и кэш-локальность проседают. Частично лечится sameSizeGrow.
• Большие ключи и значения. map[string][4096]byte копирует значение целиком при каждом чтении и записи; бакеты огромные, кэш не помогает. Лучше map[string]*T.
• Рост без преаллокации. Залить 10 млн ключей без make(map[..].., 10_000_000) значит пройти ~23 удвоения и переложить все элементы заново. Скажешь размер заранее, и почти вся эта работа отпадёт.

// Преаллоцируем: рантайм сразу выберет нужный B
m := make(map[string]int, len(rows))   // одна аллокация вместо цепочки ростов
for _, r := range rows { m[r.Key] = r.Val }

comma-ok

У чтения из мапы две формы. Односложная всегда возвращает значение, нулевое, если ключа нет. Двухсложная (comma-ok) добавляет флаг наличия. Это единственный способ отличить «ключа нет» от «ключ есть и в нём нулевое значение».

m := map[string]int{"a": 0}

v := m["a"]            // 0
v2 := m["zzz"]         // 0 — не отличить от предыдущего
v3, ok := m["a"]       // 0, true
v4, ok2 := m["zzz"]    // 0, false

// Типичная ошибка в проде: флаги в map[string]bool
flags := map[string]bool{"debug": false}
if flags["debug"] { }          // false
if flags["typo_debug"] { }     // тоже false — опечатка не заметна
if v, ok := flags["debug"]; ok && v { }   // так честно

// Одна идиома языка, тот же синтаксис у трёх других конструкций:
v, ok := i.(MyType)    // type assertion
v, ok := <-ch          // чтение из канала: ok == false, если канал закрыт и пуст
_, ok := m[k]          // мапа

Что выведет код?

// (A)
m := map[string][]int{}
m["a"] = append(m["a"], 1)
m["a"] = append(m["a"], 2)
fmt.Println(m, len(m["b"]))

type S struct {
    N int
}
ms := map[string]S{"x": {1}}
v := ms["x"]
v.N++
fmt.Println(ms["x"].N)

// (B)
m := map[int]int{1: 1, 2: 2, 3: 3}
for k := range m {
    delete(m, k)
}
fmt.Println(len(m))

var n map[string]int
fmt.Println(n == nil, len(n), n["q"])
n2 := map[string]int{}
fmt.Println(n2 == nil, len(n2))

(A) → map[a:[1 2]] 0, затем 1. append(m["a"], 1) работает, потому что чтение отсутствующего ключа даёт nil-слайс, а в него можно аппендить. А вот v := ms["x"] копирует структуру: инкремент ушёл в копию, в мапе осталась единица. Чтобы поменять, нужно ms["x"] = v или map[string]*S.

(B) → 0, затем true 0 0 и false 0. Удаление во время range легально, и спецификация гарантирует, что удалённый непосещённый ключ не будет посещён, поэтому мапа честно пустеет. Второй блок про то, что nil-мапа и пустая мапа неотличимы по len, но различимы по == nil, и в первую нельзя писать.

# вернуть старую реализацию (в Go 1.27 опции уже нет)
$ GOEXPERIMENT=noswissmap go build ./...

m := map[string]int{"a": 1}
// p := &m["a"]     // ошибка: cannot take address of m["a"]
m["a"]++            // можно: разворачивается в чтение + сложение + запись
m["a"] += 5         // можно
m["new"]++          // можно: отсутствующий ключ = 0, станет 1

type S struct {
    N int
}
ms := map[string]S{"a": {1}}
// ms["a"].N = 2    // ошибка: cannot assign to struct field in map
v := ms["a"]; v.N = 2; ms["a"] = v      // читаем-меняем-пишем

mp := map[string]*S{"a": {1}}
mp["a"].N = 2                            // работает: адресуем то, на что указывает значение

sl := map[string][]int{"a": {1}}
sl["a"] = append(sl["a"], 2)             // слайс менять можно только через переприсваивание
sl["a"][0] = 9                           // а элемент можно напрямую: индексация идёт
                                         // по указателю внутри значения, а не по самому значению

keys := make([]string, 0, len(m))
for k := range m { keys = append(keys, k) }
slices.Sort(keys)
for _, k := range keys { fmt.Println(k, m[k]) }

// Go 1.23+: на итераторах это одна строка:
for _, k := range slices.Sorted(maps.Keys(m)) { fmt.Println(k, m[k]) }

// для m := map[string]int{"b": 2, "a": 1, "c": 3} оба варианта
// печатают одно и то же при любом запуске:
// a 1
// b 2
// c 3

var m map[string]int   // nil: указатель на hmap равен nil

m == nil        // true
len(m)          // 0
m["x"]          // 0     — чтение легально
v, ok := m["x"] // 0, false
for range m {}  // ноль итераций
delete(m, "x")  // no-op, без паники

m["x"] = 1      // panic: assignment to entry in nil map

type Config struct {
    Labels map[string]string   // забыли инициализировать в конструкторе
}
c := &Config{}
c.Labels["env"] = "prod"       // panic

// JSON: если в документе поля нет — мапа останется nil
var c2 Config
json.Unmarshal([]byte(`{}`), &c2)
c2.Labels["env"] = "prod"      // panic

// Правильно:
func NewConfig() *Config { return &Config{Labels: map[string]string{}} }
// или ленивая инициализация в сеттере:
func (c *Config) Set(k, v string) {
    if c.Labels == nil { c.Labels = make(map[string]string) }
    c.Labels[k] = v
}

// RLock не спасает от "проверил-и-записал"
c.mu.RLock()
_, ok := c.m[k]
c.mu.RUnlock()
if !ok {
    c.mu.Lock()
    c.m[k] = compute(k)   // между RUnlock и Lock кто-то мог уже положить
    c.mu.Unlock()
}
// Правильно: под Lock перепроверить (double-checked), либо singleflight
c.mu.Lock()
if _, ok := c.m[k]; !ok { c.m[k] = compute(k) }
c.mu.Unlock()

type Key struct {
    UserID int64
    Region string
}
m := map[Key]int{{1, "ru"}: 10}
fmt.Println(m[Key{1, "ru"}])    // 10 — сравнение пополевое

// Слайс нельзя, но можно массив фиксированной длины:
var id [16]byte
copy(id[:], uuidBytes)
byID := map[[16]byte]string{id: "user"}

// Или сериализовать ключ в строку:
byTags := map[string]int{}
byTags[strings.Join(tags, "\x00")] = 1   // разделитель, который не встречается в данных

// Интерфейс-ключ: компилируется, но падает
var anyMap = map[any]int{}
anyMap[42] = 1         // ок: int comparable
anyMap[[]int{1}] = 1   // panic: runtime error: hash of unhashable type []int

// Не помогает вернуть память:
delete(m, k)          // обнуляет слот, бакеты остаются
clear(m)              // Go 1.21+: как "удалить все ключи", память тоже не отдаёт

// Помогает:
m = make(map[K]V)     // старая мапа становится мусором целиком

// Помогает частично: значения соберёт GC, в бакетах останутся указатели по 8 байт
mp := map[K]*V{}

set := make(map[string]struct{}, 1024)
set["a"] = struct{}{}
_, ok := set["a"]        // проверка
delete(set, "a")
len(set)                 // размер

// Операции над множествами пишем руками:
func Union(a, b map[string]struct{}) map[string]struct{} {
    r := make(map[string]struct{}, len(a)+len(b))
    for k := range a { r[k] = struct{}{} }
    for k := range b { r[k] = struct{}{} }
    return r
}

done := make(chan struct{})   // сигнальный канал: важен факт, а не значение
close(done)                   // broadcast всем читателям

type NoopLogger struct{}      // тип без состояния — экземпляры бесплатны
func (NoopLogger) Log(string) {}

// Разницу легко измерить:
func BenchmarkNoPrealloc(b *testing.B) {
    for b.Loop() {                       // Go 1.24+: b.Loop вместо b.N
        m := map[int]int{}
        for i := 0; i < 1_000_000; i++ { m[i] = i }
    }
}
func BenchmarkPrealloc(b *testing.B) {
    for b.Loop() {
        m := make(map[int]int, 1_000_000)
        for i := 0; i < 1_000_000; i++ { m[i] = i }
    }
}
// преаллоцированная версия обычно быстрее в 1.5–2 раза и делает
// на порядок меньше аллокаций

m := map[string]int{"a": 0}
v1 := m["a"]        // 0
v2 := m["zzz"]      // 0 — неотличимо
v3, ok := m["a"]    // 0, true
v4, ok := m["zzz"]  // 0, false

v, ok := m[k]           // мапа: ok == есть ли ключ
v, ok := i.(MyType)     // type assertion: ok == совпал ли динамический тип
v, ok := <-ch           // канал: ok == false, если канал закрыт и опустошён
for i, ok := it.Next(); ok; i, ok = it.Next() {}   // ручной итератор

counts[word]++              // отсутствующий ключ = 0, станет 1, comma-ok не нужен
total += prices[id]         // «нет цены» и «цена 0» здесь одно и то же
sums[k] = append(sums[k], v) // nil-слайс аппендится нормально

1.4Строки

Строка в Go: два слова в памяти плюс байтовый буфер, который нельзя менять. Отсюда и всё остальное. Почему len("Привет") == 12, почему конкатенация в цикле квадратична, почему подстрока держит сто мегабайт, почему []byte(s) то аллоцирует, то нет.

String header: что физически лежит в переменной

Как и у слайса, у строки есть заголовок: маленькая служебная структурка. Байты она не хранит, только говорит, где они лежат и сколько их. Полей здесь не три, а два.

За типом string стоит runtime.stringStruct: указатель на байты и длина в байтах. Ровно 16 байт на 64-битной платформе. Ёмкости нет, и она не нужна: строка не растёт.

// runtime/string.go
type stringStruct struct {
    str unsafe.Pointer   // указатель на первый байт
    len int              // длина в байтах, не в символах
}

s := "Привет"
fmt.Println(unsafe.Sizeof(s))   // 16 — размер заголовка, а не данных
fmt.Println(len(s))             // 12 — длина буфера в байтах

Сравни со слайсом: у []byte три слова (ptr, len, cap), а у string только два. Различие единственное, но следствий у него много. Конверсия string ↔ []byte в общем случае копирует байты, потому что у типов разный контракт на изменяемость, а не разная раскладка данных.

Почему строки иммутабельны

Спецификация прямо запрещает менять байты строки: s[0] = 'X' не соберётся, компилятор скажет cannot assign to s[0]. Иммутабельность означает вот что: значение после создания уже нельзя переписать, рядом строят новое. На собесе назови хотя бы три причины, зачем это строкам:

• Подстроки без копии. s[a:b] заводит новый заголовок на тот же буфер, ноль аллокаций. Будь строки изменяемыми, каждая подстрока требовала бы копии, иначе правки протекали бы наружу.
• Безопасность в конкурентности. Неизменяемое значение читают из любого числа горутин без синхронизации. Среди «сложных» типов Go строка такая одна: безопасна по построению.
• Ключи мап и константы. Хеш строки можно считать, не боясь, что содержимое поменяется под ногами. Строковые литералы компилятор кладёт в read-only секцию бинаря и переиспользует один буфер для одинаковых литералов. Запись туда вызвала бы segfault на уровне ОС.
• Дешёвое копирование значения. Строка уходит в функцию копией в 16 байт, хоть там мегабайт, хоть два символа.

s := "hello"
// s[0] = 'H'                  // ошибка компиляции: cannot assign to s[0]

// Изменить можно через []byte или []rune:
b := []byte(s)
b[0] = 'H'
s2 := string(b)                // "Hello" — новая строка, старая цела

// Литералы шарят память:
a1 := "hello"
a2 := "hello"
// unsafe: оба указывают в одну read-only область бинаря

// Через unsafe писать нельзя: сегфолт или порча памяти
// p := unsafe.StringData(s); *p = 'H'   // SIGSEGV: write to read-only section

UTF-8, руны и len

Go хранит строки в UTF-8, и это решение авторов языка: Кен Томпсон и Роб Пайк придумали саму кодировку. Длина у неё переменная. ASCII занимает 1 байт, кириллица и большинство европейских алфавитов по 2, CJK и большинство символов по 3, эмодзи и редкие знаки по 4.

Кодовая точка означает номер символа в таблице Unicode, тот самый, что пишут как U+2665. Кодировка говорит, как этот номер записать байтами. В Go тип rune хранит именно кодовую точку (просто псевдоним int32), а в строке лежат байты UTF-8.

Работает это так: первый байт последовательности всегда отличим от продолжающих (продолжающие начинаются с 10). Поэтому по UTF-8 можно идти назад и находить границу символа из любой позиции. И ASCII-подстрока никогда не совпадёт «случайно» с куском многобайтового символа, так что strings.Contains(s, "/") корректен без всякого Unicode-парсинга.

s := "Go♥"

fmt.Println(len(s))                     // 5 — байты
fmt.Println(utf8.RuneCountInString(s))  // 3 — руны

fmt.Printf("%T %v\n", s[0], s[0])       // uint8 71    — s[i] это байт
fmt.Printf("%c\n", s[2])                // â — байт 0xE2 напечатан как руна U+00E2,
                                        // это не «♥»: один байт из трёх

// По символам идём через range: он декодирует UTF-8
for i, r := range s {
    fmt.Printf("байт %d: руна %c (U+%04X, %d байт)\n", i, r, r, utf8.RuneLen(r))
}
// байт 0: руна G (U+0047, 1 байт)
// байт 1: руна o (U+006F, 1 байт)
// байт 2: руна ♥ (U+2665, 3 байт)

// По байтам, когда нужны именно байты (парсеры, ASCII-протоколы):
for i := 0; i < len(s); i++ {
    _ = s[i]                            // uint8
}

// По «символам» индексируем только через []rune, ценой аллокации:
rs := []rune(s)
fmt.Println(string(rs[2]))              // "♥"

Конверсии string ↔ []byte ↔ []rune и их цена

В нескольких частных случаях компилятор копию убирает, и на собесе про них любят добить:

// 1. Ключ мапы: []byte → string без аллокации
var m map[string]int
b := []byte("key")
_ = m[string(b)]                 // компилятор не аллоцирует: временная строка не утекает

// 2. Сравнение
if string(b) == "hello" { }      // без аллокации

// 3. range по string(b)
for _, r := range string(b) { }  // без аллокации

// 4. Конкатенация в маленькие строки: стековый буфер на 32 байта
s := "a" + string(b)             // может уложиться в tmpBuf на стеке

// 5. Обратно: []byte(s) в аргументе Write, который не сохраняет срез —
//    escape-анализ отрабатывает, но копия обычно всё равно делается,
//    потому что компилятор не знает, что Write не запомнит срез
w.Write([]byte(s))               // аллокация есть
io.WriteString(w, s)             // а вот так — без аллокации, если w реализует StringWriter

// Zero-copy, Go 1.20+. Использовать, только понимая последствия.
func bytesToString(b []byte) string {
    if len(b) == 0 { return "" }
    return unsafe.String(unsafe.SliceData(b), len(b))
}
func stringToBytes(s string) []byte {
    if s == "" { return nil }
    return unsafe.Slice(unsafe.StringData(s), len(s))   // писать в результат нельзя
}

Конкатенация: почему «плюс» в цикле квадратичен

Каждый a + b обязан создать новую строку: выделить буфер длины len(a)+len(b) и скопировать туда оба куска. В цикле на n итераций набегает 1 + 2 + 3 + … + n скопированных байт, то есть O(n²) по времени и n аллокаций. Каждая тут же становится мусором для GC.

// Плохо: O(n²)
func joinBad(parts []string) string {
    s := ""
    for _, p := range parts { s += p }     // n аллокаций, n²/2 скопированных байт
    return s
}

// Хорошо: один буфер, одна аллокация
func joinGood(parts []string) string {
    var b strings.Builder
    n := 0
    for _, p := range parts { n += len(p) }
    b.Grow(n)                              // сразу нужный размер, без перевыделений
    for _, p := range parts { b.WriteString(p) }
    return b.String()                      // без копии: unsafe-конверсия внутри
}

// Ещё лучше, если куски уже в слайсе
func joinBest(parts []string) string {
    return strings.Join(parts, "")         // ровно одна аллокация нужного размера
}

// У форматирования другая задача и другая цена:
_ = fmt.Sprintf("%s=%d", k, v)             // рефлексия + интерфейсный боксинг
_ = k + "=" + strconv.Itoa(v)              // в разы быстрее для двух-трёх кусков

// Бенчмарк, который стоит уметь написать на доске (Go 1.24+, b.Loop)
func BenchmarkPlus(b *testing.B) {
    parts := make([]string, 1000)
    for i := range parts { parts[i] = "chunk" }
    for b.Loop() {
        s := ""
        for _, p := range parts { s += p }
        _ = s
    }
}

func BenchmarkBuilder(b *testing.B) {
    parts := make([]string, 1000)
    for i := range parts { parts[i] = "chunk" }
    for b.Loop() {
        var sb strings.Builder
        sb.Grow(5000)
        for _, p := range parts { sb.WriteString(p) }
        _ = sb.String()
    }
}
// Типичный порядок величин на 1000 кусков по 5 байт:
// BenchmarkPlus-8       ~  1_300_000 ns/op   2_500_000 B/op   999 allocs/op
// BenchmarkBuilder-8    ~      8_000 ns/op       5_000 B/op     1 allocs/op
// BenchmarkJoin-8       ~      6_000 ns/op       5_000 B/op     1 allocs/op
// BenchmarkSprintf-8    ~     70_000 ns/op      15_000 B/op    ~5 allocs/op

Утечка памяти через подстроку

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

// Читаем файл на 100 МБ, берём из него первые 10 символов и кладём в кэш
func loadKey(path string) string {
    data, _ := os.ReadFile(path)   // 100 МБ в куче
    s := string(data)              // ещё 100 МБ (копия)
    return s[:10]                  // заголовок len=10 на буфер 100 МБ
}
// data соберётся, а вот буфер s — нет: на него смотрит возвращённая подстрока.
// 100 МБ живут ради 10 байт.

// Вариант 1: форсируем копию через конверсию туда-обратно
return string([]byte(s[:10]))      // новый буфер ровно на 10 байт

// Вариант 2 (Go 1.18+): strings.Clone, явно и без лишней конверсии
return strings.Clone(s[:10])

// Вариант 3: не создавать большую строку вообще
f, _ := os.Open(path)
buf := make([]byte, 10)
io.ReadFull(f, buf)
return string(buf)

Сравнение строк

== для строк делает побайтовое сравнение содержимого, а не адресов. Под капотом (runtime.memequal) сначала идут длины (разошлись, мгновенный отказ), затем указатели (совпали, строки идентичны, ноль работы), и только потом байты машинными словами. Оператор < сравнивает лексикографически, по байтам, и для UTF-8 это совпадает с порядком кодовых точек.

a, b := "hello", "hello"
fmt.Println(a == b)                    // true — сравнение содержимого

fmt.Println("apple" < "banana")        // true — лексикографически по байтам
fmt.Println("Z" < "a")                 // true — 0x5A < 0x61, регистр влияет
fmt.Println("Ёж" < "Яблоко")           // true, но по байтам UTF-8, а не по алфавиту:
                                       // «Ё» это U+0401 (0xD0 0x81), «Я» — U+042F (0xD0 0xAF)

// strings.Compare есть, но обычно не нужен: он для sort-интерфейсов
fmt.Println(strings.Compare(a, b))     // 0 (-1, 0, 1)

// Без учёта регистра сравниваем не через ToLower:
fmt.Println(strings.EqualFold("Go", "GO"))        // true
fmt.Println(strings.EqualFold("Straße", "STRASSE")) // false — case folding не разворачивает ß
fmt.Println(strings.EqualFold("ПРИВЕТ", "привет"))  // true — работает и с кириллицей

Что выведет код?

// (A)
s := "мир"
fmt.Println(len(s))
fmt.Println(len([]rune(s)))
fmt.Println(s[0])
fmt.Println(string(s[0]))
fmt.Println(string(rune(1055)))

for i := range s {
    fmt.Print(i, " ")
}

// (B)
s := "hello"
b := []byte(s)
b[0] = 'H'
fmt.Println(s, string(b))

x := 65
fmt.Println(string(rune(x)))
fmt.Println(strconv.Itoa(x))

fmt.Println("a"+"b" == "ab")
var e string
fmt.Println(e == "", len(e))

(A) → 6 (три кириллические буквы по 2 байта), 3, 208 (первый байт буквы «м» в UTF-8 равен 0xD0), затем "Ð" (конверсия string(byte) трактует 208 как кодовую точку U+00D0), затем "П" (U+041F = 1055). Индексы из range: 0 2 4, то есть байтовые смещения начал рун, а не 0 1 2.

(B) → hello Hello: конверсия скопировала байты, оригинал цел. Затем "A" и "65": string(rune(65)) даёт символ с кодом 65, а strconv.Itoa(65) даёт текстовое представление числа. Дальше true (конкатенация констант вычисляется компилятором) и true 0: нулевое значение строки равно "", а не nil; строка не может быть nil.

type stringStruct struct {
    str unsafe.Pointer   // на первый байт
    len int              // длина в байтах
}
unsafe.Sizeof("любая строка")   // 16 на amd64 — размер заголовка

s := "hello"
// s[0] = 'H'          // ошибка компиляции: cannot assign to s[0]
b := []byte(s); b[0] = 'H'; s2 := string(b)   // через копию

m[string(b)]                       // ключ мапы — без аллокации
if string(b) == "hello" { }        // сравнение — без аллокации
for _, r := range string(b) { }    // range — без аллокации
switch string(b) { case "a": }     // switch — без аллокации
io.WriteString(w, s)               // вместо w.Write([]byte(s)) — без аллокации

s := "Привет"
len(s)                        // 12 — кириллица по 2 байта
utf8.RuneCountInString(s)     // 6
len([]rune(s))                // 6, но с аллокацией: ради счёта так не делают

// 1) По рунам: range декодирует UTF-8, i это байтовое смещение
for i, r := range s {
    fmt.Printf("%d:%c ", i, r)     // 0:П 2:р 4:и 6:в 8:е 10:т
}

// 2) По байтам, когда работаешь с бинарём или ASCII-протоколом
for i := 0; i < len(s); i++ {
    _ = s[i]                       // uint8
}

// 3) Через []rune, когда нужен произвольный доступ по индексу символа
rs := []rune(s)
_ = rs[3]                          // аллокация: оправдана, только если индексируешь много раз

// Плохо: разрежет руну пополам, в выводе появится U+FFFD
func truncBad(s string, n int) string { if len(s) > n { return s[:n] }; return s }

// Хорошо: режем по границе руны, без аллокации
func trunc(s string, n int) string {
    if utf8.RuneCountInString(s) <= n { return s }
    cnt := 0
    for i := range s {              // i — смещение начала очередной руны
        if cnt == n { return s[:i] }
        cnt++
    }
    return s
}

s := "Привет"
fmt.Printf("%T %v\n", s[0], s[0])   // uint8 208 — первый байт буквы "П" (0xD0)
fmt.Printf("%c\n", s[0])            // Ð — 208 прочитан как кодовая точка U+00D0
fmt.Println(s[0:2])                 // "П" — два байта вместе дают букву

// А range декодирует и даёт rune:
for i, r := range s {
    fmt.Printf("%d %T %c\n", i, r, r)   // 0 int32 П ; 2 int32 р ; ...
    break
}

r, size := utf8.DecodeRuneInString(s)   // руна и её длина в байтах, без аллокации
fmt.Printf("%c занимает %d байт\n", r, size)   // П занимает 2 байт

// Или через range с немедленным выходом:
for _, r := range s { first = r; break }

// А не так:
// first := rune(s[0])   // 208 — это не буква

var b strings.Builder
b.Grow(totalLen)                 // одна аллокация на всё
for _, p := range parts {
    b.WriteString(p)             // append в []byte, без копии строки
}
return b.String()                // unsafe-конверсия без копии буфера

func extractID(body string) string {
    return body[10:20]    // 10 байт, а держат весь body
}
cache[key] = extractID(hugeBody)   // в кэше «10 байт», в куче — весь body

// 1) strings.Clone — Go 1.18+, самый честный способ
small := strings.Clone(body[10:20])

// 2) Конверсия туда-обратно, так жили до Clone
small = string([]byte(body[10:20]))

// 3) Не создавать большую строку вообще: читать потоково
sc := bufio.NewScanner(r)
for sc.Scan() {
    line := sc.Text()      // Text() уже делает копию, Bytes() нет: буфер переиспользуется
}

$ go tool pprof -inuse_space http://localhost:6060/debug/pprof/heap
(pprof) top
# симптом: почти вся живая память в одном месте аллокации большого буфера
# (os.ReadFile, io.ReadAll, http body), хотя логически хранится мало

"Z" < "a"                  // true: 0x5A < 0x61 — заглавные раньше строчных
"ёлка" < "яблоко"          // сравниваются байты UTF-8, а не «русский алфавит»
// для человеческого порядка нужен golang.org/x/text/collate

strings.EqualFold("Go", "GO")           // true
strings.EqualFold("ПРИВЕТ", "привет")   // true
strings.EqualFold("Σίσυφος", "ΣΊΣΥΦΟΣ") // true — обе сигмы свернутся правильно
strings.EqualFold("Straße", "STRASSE")  // false — simple folding не разворачивает ß в ss

1.5Интерфейсы и «ООП» в Go

Здесь проверяют, понимаешь ли ты, что интерфейсное значение состоит из двух половинок: тип и данные. Отсюда растёт всё остальное: знаменитый typed nil, правила method set, цена динамической диспетчеризации, привычка объявлять интерфейс у потребителя.

Сначала — что такое интерфейс и откуда взялись «две половинки»

Всё сводится к одному рабочему вопросу: как в языке без наследования подставить одну реализацию вместо другой и что за это платишь. Мокнуть базу в тесте, подменить платёжного провайдера, написать функцию, которая одинаково пишет и в файл, и в сеть, — всё это интерфейсы. И тут же рядом два самых частых «убийственных» вопроса собеса: почему err != nil, когда там явно nil, и почему метод не находится, хотя он написан.

Прежде чем лезть в рантайм, договоримся о четырёх словах.

1. Интерфейс — это список требований, а не хранилище данных

type Writer interface { Write([]byte) (int, error) } не описывает полей и ничего не хранит. Это объявление вида «мне подойдёт любой тип, у которого есть вот такой метод». Как объявление в газете: «требуется тот, кто умеет писать байты». Кто именно придёт, объявлению безразлично.

2. Duck typing — реализация без объявления

В Java или C# тип обязан сказать, что он реализует интерфейс: implements Writer. В Go такого слова нет вообще. Если у типа есть метод Write с нужной сигнатурой, он уже реализует io.Writer, даже если написан за пять лет до появления этого интерфейса и в другом репозитории. Такой подход называют утиной типизацией, а строгий термин звучит как структурная типизация: тип подходит по форме, а не по родословной.

Плата за удобство: компилятор не скажет «класс X забыл реализовать интерфейс Y». Он скажет «X не подходит на место Y», причём там, где ты попытался его подставить, иногда в совсем другом пакете.

3. Method set — набор методов, которые «числятся» за типом

Method set типа — список методов, которые интерфейс засчитывает именно этому типу. Звучит как тавтология, но подвох реальный: у T и у *T наборы разные. Методы с получателем-значением (func (t T) Foo()) входят в оба набора; методы с получателем-указателем (func (t *T) Bar()) попадают только в набор *T. Отсюда классическое «почему T не реализует интерфейс, а &T{} реализует». Об этом ниже отдельно.

4. Интерфейсная переменная — это две половинки: «какой тип» и «где данные»

Когда ты пишешь var w io.Writer = f, в переменную w не «кладётся файл». В неё кладутся два указателя:

• левая половинка — тип: «здесь лежит *os.File», плюс, для непустого интерфейса, таблица адресов его методов;
• правая половинка — данные: адрес самого значения.

Аналогия: интерфейс — это ярлык на посылке. На ярлыке написано, что внутри («тип: коробка обуви») и по какому адресу посылка лежит. Сам ярлык не посылка. Его можно скопировать, передать, сравнить с другим ярлыком, и на нём вполне может быть написано «внутри: коробка обуви, содержимое: ничего». Ярлык всё равно существует, он не пустой. На этом и держится вся история с typed nil.

Три жаргонных слова, которые дальше встречаются постоянно и означают ровно это:

• eface (empty interface) — как устроена переменная пустого интерфейса any: «указатель на описание типа» + «указатель на данные».
• iface — как устроена переменная любого непустого интерфейса (error, io.Writer, свой): вместо описания типа в левой половинке лежит указатель на itab.
• itab (interface table) — маленькая табличка, которую рантайм заводит на каждую пару «этот интерфейс + этот конкретный тип». Внутри лежат описание типа и адреса его методов в порядке методов интерфейса, а они отсортированы по имени. Благодаря ей вызов w.Write(...) превращается в «взять адрес из ячейки номер 0 и прыгнуть туда».

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

ООП в Go: что есть и чего нет

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

Embedding: композиция с продвижением методов

Встраивание — это поле без имени. Имя типа становится именем поля, а все методы и поля встроенного типа продвигаются наружу: их можно вызывать так, будто они объявлены у внешнего типа. Это синтаксический сахар над делегированием, а не наследование.

type Animal struct {
    Name string
}
func (a Animal) Speak() string { return a.Name + " издаёт звук" }
func (a Animal) Describe() string { return "Я " + a.Speak() }

type Dog struct {
    Animal          // встроили: поле называется Animal, методы продвинуты
    Breed string
}

d := Dog{Animal{"Рекс"}, "лабрадор"}
fmt.Println(d.Name)          // "Рекс"  — продвинутое поле, сахар для d.Animal.Name
fmt.Println(d.Speak())       // "Рекс издаёт звук" — продвинутый метод
                             // (пока у Dog нет своего Speak; объявим его ниже,
                             //  и эта же строка начнёт печатать "Рекс гавкает":
                             //  порядок объявлений в файле роли не играет)

// Метод внешнего типа перекрывает продвинутый
func (d Dog) Speak() string { return d.Name + " гавкает" }

fmt.Println(d.Speak())       // "Рекс гавкает"   — вызвался метод Dog
fmt.Println(d.Animal.Speak())// "Рекс издаёт звук" — явный доступ к встроенному
fmt.Println(d.Describe())    // "Я Рекс издаёт звук", а не "гавкает"

// Встраивание интерфейса в структуру — идиома «частичная реализация»
type ReadWriter interface { io.Reader; io.Writer }   // интерфейс в интерфейсе

type OnlyRead struct {
    io.ReadWriter        // встроен интерфейс: тип формально реализует ReadWriter,
}                        // но методы делегируются в nil, если поле не заполнено

var x OnlyRead
// x.Read(nil)           // panic: nil pointer dereference — метод есть, реализации нет

// Та же идиома с пользой: обёртка перекрывает один метод
type LoggingStore struct {
    Store                       // все методы Store продвинуты
    log *slog.Logger
}
func (s LoggingStore) Get(id string) (User, error) {   // перекрываем только Get
    s.log.Info("get", "id", id)
    return s.Store.Get(id)                              // делегируем дальше
}

// Мьютекс часто встраивают ради «наследования», но это спорно:
type Counter struct {
    sync.Mutex          // Lock/Unlock стали экспортируемыми методами Counter
    n int
}
// лучше так: мьютекс остаётся деталью реализации
type Counter2 struct {
    mu sync.Mutex
    n  int
}

Внутреннее устройство: iface, eface, itab

Интерфейсное значение — всегда два машинных слова. Что именно в них лежит, зависит от того, пустой интерфейс или нет.

// Упрощённо из runtime/runtime2.go:
type eface struct {           // interface{} / any
    _type *_type
    data  unsafe.Pointer
}
type iface struct {           // любой непустой интерфейс
    tab  *itab
    data unsafe.Pointer
}
type itab struct {
    inter *interfacetype      // описание интерфейса
    _type *_type              // описание конкретного типа
    hash  uint32              // копия _type.hash для быстрого type switch
    _     [4]byte
    fun   [1]uintptr          // на самом деле переменной длины: адреса методов
}

Классика: typed nil в error

Самый частый «убийственный» вопрос секции. Ломает он ровно потому, что «две половинки» казались абстракцией, а тут вдруг решают исход if err != nil.

Что такое typed nil. Есть два разных «ничего», и в Go они не одно и то же:

• Нулевой указатель — var e *MyError. Переменная существует, её тип известен (*MyError), просто адрес внутри нулевой. Это «конкретное значение, которое ни на что не показывает».
• Пустой интерфейс-переменная — var err error. Обе половинки нулевые: неизвестно ни какой тип, ни где данные. Это «вообще ничего не положили».

Когда ты пишешь return e из функции с типом результата error, рантайм упаковывает значение: заполняет левую половинку («тип: *MyError») и правую («данные: nil»). Вернулся ярлык с надписью, что внутри, пусть внутри и пусто. А сравнение err == nil проверяет, что пусты обе половинки. Левая не пуста. Значит false.

Та же мысль короче, чтобы проговорить вслух на собесе: «nil-указатель, положенный в интерфейс, — это не nil-интерфейс. Интерфейс запомнил тип, а тип — это не nil».

Та же картинка, только схемой.

type MyError struct {
    Code int
}
func (e *MyError) Error() string { return fmt.Sprintf("code=%d", e.Code) }

// Плохо: возвращаем конкретный тип
func doBad(ok bool) error {
    var e *MyError            // e == nil
    if !ok {
        e = &MyError{Code: 500}
    }
    return e                  // в error упаковали (*MyError)(nil)
}

err := doBad(true)
fmt.Println(err == nil)             // false, хотя e был nil
fmt.Println(err)                    // <nil>
fmt.Printf("%T %v\n", err, err)     // *main.MyError <nil>
// Почему <nil>, а не паника: fmt вызывает Error(), тот разыменовывает e.Code
// и паникует на nil-получателе, а fmt ловит панику и подставляет <nil>.
// Если бы Error() не трогал поля (например, return "boom"), напечаталось бы "boom".
// Вот и подвох: в логе nil, а ветка ошибки выполняется.

// Хорошо, вариант 1: возвращать nil явно
func doGood1(ok bool) error {
    if !ok { return &MyError{Code: 500} }
    return nil                // литеральный nil: обе половинки нулевые
}

// Хорошо, вариант 2: если переменная нужна, проверить её перед возвратом
func doGood2(ok bool) error {
    var e *MyError
    if !ok { e = &MyError{Code: 500} }
    if e == nil { return nil }   // e в интерфейс не упаковывается
    return e
}

// Поймать typed nil можно рефлексией, но это лечит симптом
func isNil(i any) bool {
    if i == nil { return true }
    v := reflect.ValueOf(i)
    switch v.Kind() {
    case reflect.Ptr, reflect.Map, reflect.Slice, reflect.Chan, reflect.Func, reflect.Interface:
        return v.IsNil()
    }
    return false
}
// Правильнее вообще не создавать typed nil.

Неявная реализация и проверка на этапе компиляции

В Go нет implements. Тип реализует интерфейс, если его method set содержит все методы интерфейса. Это и есть структурная типизация. Плюсы: можно написать интерфейс после реализации, в том числе для чужого пакета; реализация не зависит от абстракции. Минус: опечатка в имени или сигнатуре метода даёт не «класс не реализует интерфейс», а внезапную ошибку в месте использования, иногда далеко от объявления.

// Идиома: компилятор проверяет, что тип реализует интерфейс
var _ io.Writer      = (*MyWriter)(nil)   // *MyWriter реализует io.Writer
var _ error          = (*MyError)(nil)
var _ sort.Interface = (ByAge)(nil)       // для слайс-типа
var _ Storage        = (*PostgresStore)(nil)

// Создаём типизированный nil нужного типа
// и присваиваем пустой переменной интерфейсного типа.
// Значение никуда не идёт, аллокаций нет: работает только проверка типов.
// Если метода не хватает, компилятор скажет:
//   cannot use (*MyWriter)(nil) as io.Writer value:
//   *MyWriter does not implement io.Writer (missing method Write)

Пустой интерфейс any и type assertion

any — псевдоним для interface{}, добавленный в Go 1.18 (type any = interface{}). Его реализует любой тип, потому что требований ноль. Цена: ты теряешь всю информацию о типе, и вернуть её можно только через рантайм-проверку.

var x any = 42

// 1. Небезопасная форма паникует при несовпадении
n := x.(int)          // 42
// s := x.(string)    // panic: interface conversion: interface {} is int, not string

// 2. Безопасная форма (comma-ok) никогда не паникует
if s, ok := x.(string); ok {
    fmt.Println("строка:", s)
} else {
    fmt.Println("не строка")               // ← сюда: x это int
}

// 3. Type switch ветвится по динамическому типу
switch v := x.(type) {
case nil:
    fmt.Println("nil интерфейс")           // отдельный case для nil
case int:
    fmt.Println("int", v*2)                // ← сюда, печатает: int 84
case string, []byte:
    fmt.Println("текстовое", v)            // а тут v имеет тип any
case error:
    fmt.Println("ошибка", v.Error())       // можно проверять и на интерфейс
case fmt.Stringer:
    fmt.Println("Stringer", v.String())
default:
    fmt.Printf("неизвестный тип %T\n", v)
}
// весь блок при x = 42 печатает:
// не строка
// int 84

Когда any оправдан: границы, где типы принципиально неизвестны (fmt.Println, json.Unmarshal, кэш общего назначения, логгер с произвольными атрибутами). Когда плох: внутри доменной логики. Он выключает проверку типов, добавляет аллокации на упаковку, заставляет писать switch вместо полиморфизма, и с Go 1.18 в большинстве таких мест правильнее дженерики.

Method set: T против *T

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

• Method set типа T — только методы с value receiver.
• Method set типа *T — методы с value receiver и с pointer receiver.

type Speaker interface{ Speak() }

type Dog struct {
    name string
}
func (d *Dog) Speak() { fmt.Println(d.name) }   // POINTER receiver

d := Dog{"Рекс"}
d.Speak()                    // ОК: компилятор пишет (&d).Speak(), d адресуема

// var s Speaker = d         // ошибка компиляции:
//   cannot use d (variable of struct type Dog) as Speaker value in variable
//   declaration: Dog does not implement Speaker (method Speak has pointer receiver)
var s Speaker = &d           // ОК

// Где ещё вылезает: элементы мапы не адресуемы
m := map[string]Dog{"a": {"Рекс"}}
// m["a"].Speak()            // ошибка: cannot call pointer method Speak on Dog

// А элементы слайса адресуемы
sl := []Dog{{"Рекс"}}
sl[0].Speak()                // ОК

// Возвращаемое значение функции не адресуемо
// newDog().Speak()          // ошибка, если newDog() возвращает Dog, а не *Dog

Value receiver или pointer receiver

type Counter struct {
    n int
}
func (c Counter) IncBad()  { c.n++ }    // работает с копией, инкремент теряется
func (c *Counter) Inc()    { c.n++ }    // так правильно

c := Counter{}
c.IncBad(); c.IncBad()
fmt.Println(c.n)          // 0 — классический вопрос «что выведет»
c.Inc(); c.Inc()
fmt.Println(c.n)          // 2

// nil-receiver законен и иногда полезен
type List struct {
    head  *node
    count int
}
func (l *List) Len() int {
    if l == nil { return 0 }    // метод на nil-указателе вызывается нормально:
    return l.count              // паника будет только при обращении к полю
}
var l *List
fmt.Println(l.Len())            // 0, без паники

Exported и unexported

Видимость в Go задаёт регистр первой буквы идентификатора, и работает она на уровне пакета, а не файла или типа. Name виден снаружи пакета, name — только внутри. Это касается всего: типов, функций, методов, полей структур, констант, переменных.

package store

type User struct {
    ID    int      // виден снаружи
    name  string   // виден только внутри пакета store
}
func (u *User) Name() string { return u.name }   // геттер экспортирован
func (u *User) validate() error { return nil }   // приватный метод

// Внутри пакета доступны любые поля любого его типа:
// приватность не «на объект», а «на пакет».
func compare(a, b User) bool { return a.name == b.name }   // ок

Три следствия, которые проверяют:

• JSON и рефлексия видят только экспортированные поля. json.Marshal молча пропустит name, а json.Unmarshal не заполнит его. Отсюда DTO-структуры с экспортированными полями и тегами.
• Встраивание не «отменяет» приватность. Встроив тип из другого пакета, ты получаешь только его экспортированные методы и поля.
• Приватный тип с публичными методами — законная и полезная конструкция: функция возвращает интерфейс, а конкретный тип наружу не виден вообще.

«Принимай интерфейсы, возвращай структуры»

Правило сообщества: accept interfaces, return structs. Смысл двухсторонний.

// Принимай минимальный интерфейс
// Функция объявляет только то, что реально
// использует. Тестируется тривиально:
// подставили strings.Builder или bytes.Buffer.

func Save(w io.Writer, u User) error {
    return json.NewEncoder(w).Encode(u)
}

// А не так:
func SaveBad(f *os.File, u User) error {
    return json.NewEncoder(f).Encode(u)
}
// теперь без файла на диске не протестировать

// Возвращай конкретный тип, структуру
// Вызывающий видит все методы и поля,
// может сам решить, какой интерфейс ему нужен.

func NewStore(db *sql.DB) *Store {
    return &Store{db: db}
}

// А не так:
func NewStoreBad(db *sql.DB) Storage {
    return &Store{db: db}
}
// теперь новый метод Store не виден
// пользователям, и легко создать typed nil

Где объявлять интерфейс: у потребителя

В Java интерфейс объявляют рядом с реализацией и импортируют оба. В Go принято наоборот: интерфейс живёт в пакете, который его использует. Это возможно именно из-за неявной реализации.

// package service — потребитель объявляет ровно то, что ему нужно
type UserGetter interface {
    GetUser(ctx context.Context, id int64) (User, error)
}

type Service struct {
    users UserGetter
}

func New(u UserGetter) *Service { return &Service{users: u} }

// package postgres — реализация ничего не знает про service
type Store struct {
    db *sql.DB
}
func (s *Store) GetUser(ctx context.Context, id int64) (User, error) { /* ... */ }
func (s *Store) SaveUser(ctx context.Context, u User) error          { /* ... */ }
func (s *Store) DeleteUser(ctx context.Context, id int64) error      { /* ... */ }

// main.go — связывание
svc := service.New(postgres.New(db))

Сравнение интерфейсных значений и когда panic

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

var a any = 1
var b any = 1
var c any = int64(1)
var d any = "1"

fmt.Println(a == b)   // true  — одинаковый тип int и одинаковое значение
fmt.Println(a == c)   // false — int != int64, значения даже не сравниваются
fmt.Println(a == d)   // false — разные типы

var s1 any = []int{1}
var s2 any = []int{1}
// fmt.Println(s1 == s2)   // panic: runtime error: comparing uncomparable type []int

// Сравнимость структуры зависит от полей
type P struct {
    X int
}
type B struct {
    S []int
}
var p1, p2 any = P{1}, P{1}
fmt.Println(p1 == p2)      // true
var b1, b2 any = B{}, B{}
// fmt.Println(b1 == b2)   // panic: runtime error: comparing uncomparable type main.B

// Чаще всего сравнивают с nil
var e error
fmt.Println(e == nil)      // true
e = (*MyError)(nil)
fmt.Println(e == nil)      // false — typed nil

Рефлексия и её цена

reflect даёт доступ к тем самым двум половинкам прямо из кода: reflect.TypeOf(x) достаёт _type, reflect.ValueOf(x) — пару «тип + данные». Три закона рефлексии (из блога Роба Пайка):

1. Из интерфейсного значения можно получить reflect.Value.
2. Из reflect.Value можно вернуться к интерфейсному значению (.Interface()).
3. Чтобы менять значение через рефлексию, оно должно быть settable, то есть получено через указатель (reflect.ValueOf(&x).Elem()).

type User struct {
    ID   int    `json:"id" db:"user_id"`
    Name string `json:"name"`
}

u := User{1, "Аня"}
t := reflect.TypeOf(u)
v := reflect.ValueOf(u)

for i := 0; i < t.NumField(); i++ {
    f := t.Field(i)
    fmt.Printf("%s %s тег=%q значение=%v\n",
        f.Name, f.Type, f.Tag.Get("db"), v.Field(i).Interface())
}
// ID int тег="user_id" значение=1
// Name string тег="" значение=Аня

// Менять можно только через указатель
p := reflect.ValueOf(&u).Elem()
p.Field(1).SetString("Боря")    // u == {1 Боря}
// v.Field(1).SetString("X")    // panic: reflect: reflect.Value.SetString using unaddressable value

Что выведет код?

// (A)
type E struct{}
func (e *E) Error() string { return "e" }

func f() error {
    var p *E
    return p
}

func main() {
    err := f()
    fmt.Println(err == nil)
    fmt.Println(err)
    if err != nil {
        fmt.Println("обработка ошибки")
    }
}

// (B)
type A struct {
    n int
}
func (a A) Show()  { fmt.Println("A", a.n) }
func (a *A) Inc()  { a.n++ }

type B struct {
    A
}
func (b B) Show()  { fmt.Println("B", b.n) }

func main() {
    b := B{A{1}}
    b.Show()
    b.A.Show()
    b.Inc()
    b.Show()
    var s interface{ Show() } = b
    s.Show()
}

(A) → false, затем e, затем обработка ошибки (fmt.Printf("%T %v", err, err) дал бы *main.E e). Классический typed nil: в интерфейсе лежит тип *E и данные nil, поэтому err != nil. Печатается именно e, а не <nil>: fmt вызывает Error() на nil-получателе, а этот метод не трогает поля e и спокойно возвращает строку. <nil> вы увидели бы, только если бы Error() разыменовал получателя — тогда он бы паниковал, а fmt перехватил бы панику и подставил <nil>. Оба варианта одинаково коварны: сообщение в логе выглядит безобидно, а ветка ошибки при этом выполняется.

(B) → B 1, A 1, затем B 2, затем B 2. b.Show() берёт перекрытый метод B; b.A.Show() — явно метод A. b.Inc() компилируется как (&b.A).Inc(), потому что b адресуема, и меняет встроенное поле. А вот var s interface{ Show() } = b кладёт в интерфейс копию b: если бы после этого мы вызвали b.Inc(), s.Show() всё равно напечатал бы старое значение.

type Animal struct {
    Name string
}
func (a Animal) Speak() string    { return a.Name + " звучит" }
func (a Animal) Describe() string { return "Я " + a.Speak() }

type Dog struct {
    Animal            // имя поля = имя типа
    Breed string
}
func (d Dog) Speak() string { return d.Name + " гавкает" }   // перекрытие

d := Dog{Animal{"Рекс"}, "лабрадор"}
d.Name          // сахар для d.Animal.Name
d.Speak()       // "Рекс гавкает"  — метод Dog закрыл продвинутый
d.Animal.Speak()// "Рекс звучит"   — явный доступ
d.Describe()    // "Я Рекс звучит", а не "гавкает"

// 1) Декоратор: встроили интерфейс, перекрыли один метод
type LoggingStore struct {
    Storage                    // остальные методы делегируются автоматически
    log *slog.Logger
}
func (s LoggingStore) Get(id string) (User, error) {
    s.log.Info("get", "id", id)
    return s.Storage.Get(id)
}

// 2) Расширяем чужой тип
type Request struct {
    *http.Request
    TraceID string
}

// 3) Общие поля моделей
type Base struct {
    ID        int64
    CreatedAt time.Time
}
type User struct {
    Base
    Email string
}

type eface struct {
    _type *_type
    data  unsafe.Pointer
}
type iface struct {
    tab  *itab
    data unsafe.Pointer
}

type itab struct {
    inter *interfacetype   // какой интерфейс
    _type *_type           // какой конкретный тип
    hash  uint32           // копия _type.hash, ускоряет type switch
    fun   [1]uintptr       // переменной длины: адреса методов
}

var x any = 42       // константа: лежит в read-only данных, аллокации нет
var y any = &s       // указатель кладётся в data напрямую, без аллокации
var z any            // eface{nil, nil}
fmt.Println(unsafe.Sizeof(x))   // 16 — два слова

type MyError struct {
    Code int
}
func (e *MyError) Error() string { return "boom" }

func do() error {
    var e *MyError        // e == nil
    return e              // упаковали (*MyError)(nil) в интерфейс error
}

err := do()
fmt.Println(err == nil)   // false
fmt.Println(err)          // boom — Error() спокойно отработал на nil-получателе,
                          // потому что не трогает поля e. Если бы трогал (e.Code),
                          // он бы паниковал, fmt перехватил бы панику и напечатал <nil>
fmt.Printf("%T\n", err)   // *main.MyError
if err != nil { /* сюда попадём */ }

// 1) Возвращать литеральный nil на успешном пути
func do() error {
    if bad { return &MyError{500} }
    return nil
}

// 2) Если переменная нужна, проверить перед возвратом
func do2() error {
    var e *MyError
    if bad { e = &MyError{500} }
    if e == nil { return nil }
    return e
}

// 3) Не возвращать из функций конкретный тип ошибки
// func parse() (*Result, *ParseError)   // плохо
func parse() (*Result, error)            // хорошо

var _ io.Writer      = (*MyWriter)(nil)   // указатель реализует
var _ error          = (*MyError)(nil)
var _ Storage        = (*PostgresStore)(nil)
var _ fmt.Stringer   = Weekday(0)         // для value receiver — значение
var _ sort.Interface = ByAge(nil)         // для слайс-типа

cannot use (*MyWriter)(nil) as io.Writer value in variable declaration:
	*MyWriter does not implement io.Writer (missing method Write)

// Было (до 1.18):
func Max(a, b any) any { /* type switch, паники, боль */ }

// Стало — дженерики:
func Max[T cmp.Ordered](a, b T) T { if a > b { return a }; return b }

// Было: контейнер на any
type Stack struct {
    items []any
}
// Стало:
type Stack[T any] struct {
    items []T
}

// Было: фиксированный набор вариантов через any
func Handle(v any) { switch v.(type) { case A: ; case B: } }
// Стало: интерфейс с методом — полиморфизм вместо switch
type Handler interface{ Handle() }

var i any = "привет"

s := i.(string)              // "привет"
// n := i.(int)              // panic: interface conversion: interface {} is string, not int

s, ok := i.(string)          // "привет", true — безопасно
n, ok := i.(int)             // 0, false — паники нет

// Assertion к интерфейсу проверяет, реализует ли динамический тип ещё и его
if st, ok := i.(fmt.Stringer); ok { fmt.Println(st.String()) }
                             // ok == false: у string нет метода String(), ничего не напечатается
if rc, ok := r.(io.ReadCloser); ok { defer rc.Close() }

switch v := i.(type) {
case nil:
    // только настоящий nil-интерфейс, typed nil сюда не попадёт
case int:
    fmt.Println(v + 1)          // v имеет тип int
case string:
    fmt.Println(len(v))         // v имеет тип string
case []byte, [][]byte:
    fmt.Println(v)              // а тут v имеет тип any
case error:
    fmt.Println(v.Error())      // можно матчить и на интерфейсы
default:
    fmt.Printf("%T\n", v)
}

// 1) Опциональные интерфейсы, идиома стандартной библиотеки
func Copy(dst io.Writer, src io.Reader) (int64, error) {
    if wt, ok := src.(io.WriterTo); ok { return wt.WriteTo(dst) }  // быстрый путь
    if rf, ok := dst.(io.ReaderFrom); ok { return rf.ReadFrom(src) }
    // медленный путь через буфер
}

// 2) Разбор ошибок, но лучше errors.As
var pathErr *fs.PathError
if errors.As(err, &pathErr) { fmt.Println(pathErr.Path) }   // умеет разворачивать цепочку
if pe, ok := err.(*fs.PathError); ok { }                    // не умеет — только верхний уровень

// 3) Разбор произвольного JSON
var data any
json.Unmarshal(b, &data)
m := data.(map[string]any)      // числа будут float64
n := m["count"].(float64)

type T struct {
    n int
}
func (t T)  Val() {}
func (t *T) Ptr() {}

// method set T  = { Val }
// method set *T = { Val, Ptr }

type I interface{ Ptr() }

var t T
t.Ptr()              // компилируется: сахар для (&t).Ptr(), ведь t адресуема
// var i I = t       // ошибка: T does not implement I (method Ptr has pointer receiver)
var i I = &t         // ОК

m := map[string]T{"a": {}}
// m["a"].Ptr()          // ошибка: cannot call pointer method Ptr on T
v := m["a"]; v.Ptr()     // так — через переменную

sl := []T{{}}
sl[0].Ptr()              // ОК: элемент слайса адресуем

// Обратное направление работает всегда:
p := &T{}
p.Val()                  // сахар для (*p).Val()

type Counter struct {
    n int
}
func (c Counter) IncBad() { c.n++ }     // меняет копию, инкремент теряется
func (c *Counter) Inc()   { c.n++ }     // правильно

c := Counter{}
c.IncBad(); fmt.Println(c.n)   // 0
c.Inc();    fmt.Println(c.n)   // 1

// Мьютекс + value receiver = тихий баг: каждый вызов блокирует свою копию
type Bad struct {
    mu sync.Mutex
    n  int
}
func (b Bad) Lock() { b.mu.Lock() }     // go vet: passes lock by value

package store

type User struct {
    ID   int      // экспортировано
    name string   // нет — видно только внутри пакета store
}
func New() *User            { return &User{} }   // экспортировано
func (u *User) Name() string{ return u.name }    // геттер
func (u *User) validate() error { return nil }   // приватный метод

// Внутри пакета видно всё, включая приватные поля чужих типов этого же пакета:
func eq(a, b User) bool { return a.name == b.name }   // ок

// 1) Приватное поле + функциональные опции вместо публичных полей
type Server struct {
    timeout time.Duration
}
type Option func(*Server)
func WithTimeout(d time.Duration) Option { return func(s *Server){ s.timeout = d } }
func NewServer(opts ...Option) *Server { /* ... */ }

// 2) Приватный тип, публичный интерфейс
type storage struct {
    db *sql.DB
}
func NewStorage(db *sql.DB) Storage { return &storage{db} }  // тип наружу не виден

// 3) Запрет на литерал без имён полей — приватное поле-маркер: новые поля не сломают вызывающих
type Config struct {
    Name string
    _    struct{}   // литерал Config{"x"} без имён полей не скомпилируется вне пакета
}

// Хорошо
func NewStore(db *sql.DB) *Store { return &Store{db: db} }
func Save(w io.Writer, u User) error { return json.NewEncoder(w).Encode(u) }

// Плохо
func NewStore2(db *sql.DB) Storage { return &Store{db: db} }   // скрыли тип
func Save2(f *os.File, u User) error { }                       // прибили к файлу

// package service — потребитель объявляет ровно то, что нужно ему
type UserGetter interface {
    GetUser(ctx context.Context, id int64) (User, error)
}
type Service struct {
    users UserGetter
}
func New(u UserGetter) *Service { return &Service{users: u} }

// package postgres — про service не знает вообще
type Store struct {
    db *sql.DB
}
func (s *Store) GetUser(ctx context.Context, id int64) (User, error) { /* ... */ }
func (s *Store) SaveUser(...) error { /* ... */ }

// main.go — единственное место, где они встречаются
svc := service.New(postgres.New(db))

var a any = 1
var b any = 1
var c any = int64(1)
fmt.Println(a == b)   // true
fmt.Println(a == c)   // false — типы разные, значения даже не сравниваются

var s1 any = []int{1}
var s2 any = []int{1}
// s1 == s2           // panic: runtime error: comparing uncomparable type []int

type P struct {
    X int
}
type B struct {
    S []int
}
var p1, p2 any = P{1}, P{1}
fmt.Println(p1 == p2) // true — структура comparable
var b1, b2 any = B{}, B{}
// b1 == b2           // panic: runtime error: comparing uncomparable type main.B

// 1) Сначала проверить сравнимость
if reflect.TypeOf(a).Comparable() { _ = a == b }

// 2) Глубокое сравнение
reflect.DeepEqual(a, b)          // медленно, но не паникует
cmp.Equal(a, b)                  // go-cmp: стандарт в тестах, diff покажет cmp.Diff

// 3) В дженериках: констрейнт comparable
func Index[T comparable](s []T, v T) int { /* компилятор проверит статически */ }

type User struct {
    ID   int    `json:"id" db:"user_id"`
    Name string `json:"name"`
    age  int    // приватное: рефлексия видит, но не может ни прочитать через
}               // Interface(), ни записать

u := User{1, "Аня", 30}
t, v := reflect.TypeOf(u), reflect.ValueOf(u)
for i := 0; i < t.NumField(); i++ {
    f := t.Field(i)
    fmt.Println(f.Name, f.Type, f.Tag.Get("db"), f.IsExported())
}
// ID int user_id true
// Name string  true
// age int  false

p := reflect.ValueOf(&u).Elem()
p.FieldByName("Name").SetString("Боря")   // ок — settable и экспортировано, u == {1 Боря 30}
// v.FieldByName("Name").SetString("X")
//   panic: reflect: reflect.Value.SetString using unaddressable value
// p.FieldByName("age").SetInt(1)
//   panic: reflect: reflect.Value.SetInt using value obtained using unexported field

1.6Функции, defer, panic/recover

Тема, где почти каждый вопрос сводится к «что выведет код». Проверяют три вещи: что захватывает замыкание, когда вычисляются аргументы defer и как recover связан с раскруткой стека. Всё это про момент времени, а не про синтаксис.

Сначала — где живут вызовы и что значит «выход из функции»

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

1. Стек вызовов и фрейм

Функцию вызвали: под её аргументы, локальные переменные и адрес возврата отводится участок памяти, фрейм (в русских текстах ещё «кадр стека»). Вызовы вложены друг в друга, поэтому фреймы лежат стопкой: каждый новый вызов кладёт свой фрейм сверху, выход из функции его снимает. Стопка и называется стеком вызовов. Отсюда следствие: «выход из функции» не расплывчатое «когда-нибудь потом», а один конкретный момент, после которого всё, что лежало во фрейме, недействительно. Вот в этот момент и вклинивается defer.

2. Раскрутка стека

Раскрутка стека: фреймы снимаются со стопки один за другим. Не по одному return, а подряд, от функции, где случилась беда, к её вызывающему, потом к вызывающему вызывающего, и так далее. Так работает паника. Она не «выбрасывается» куда-то вбок, а последовательно сворачивает стек, выполняя по дороге отложенные вызовы каждого фрейма. Если её никто не остановит, сворачивать станет нечего, и процесс умрёт.

3. Именованные результаты

Результату функции можно дать имя: func f() (err error) вместо func f() error. Такие результаты зовут именованными возвращаемыми значениями. Имя в списке результатов заводит во фрейме обычную переменную, и живёт она до самого конца вызова. Разница не косметическая: defer эту переменную читает и переписывает, а значит, меняет то, что функция в итоге вернёт. На этом держатся три идиомы ниже.

Функции как объекты первого класса

Функция в Go ведёт себя как обычное значение: её можно присвоить переменной, передать аргументом, вернуть из другой функции, положить в структуру, слайс или мапу. Тип функции задаёт её сигнатура: func(int, string) error. Нулевое значение nil, и вызов nil-функции паникует.

// 1. Значение и тип
var fn func(int) int
fmt.Println(fn == nil)          // true
// fn(1)                        // panic: runtime error: invalid memory address or nil pointer dereference
//                              // [signal SIGSEGV: segmentation violation]
fn = func(x int) int { return x * 2 }

// 2. Именованный тип функции: идиома стандартной библиотеки
type HandlerFunc func(http.ResponseWriter, *http.Request)
func (f HandlerFunc) ServeHTTP(w http.ResponseWriter, r *http.Request) { f(w, r) }
// теперь обычная функция реализует http.Handler:
var _ http.Handler = HandlerFunc(myFunc)

// 3. Функция высшего порядка: middleware
func WithLogging(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        start := time.Now()
        next.ServeHTTP(w, r)
        slog.Info("req", "path", r.URL.Path, "dur", time.Since(start))
    })
}

// 4. Функциональные опции: так делают «конструктор с параметрами»
type Option func(*Server)
func WithTimeout(d time.Duration) Option { return func(s *Server){ s.timeout = d } }
func NewServer(addr string, opts ...Option) *Server {
    s := &Server{addr: addr, timeout: 30 * time.Second}   // дефолты
    for _, o := range opts { o(s) }
    return s
}
srv := NewServer(":8080", WithTimeout(5*time.Second))

// 5. Функция в поле структуры: поведение подменяется в тестах без интерфейса
type Client struct {
    doRequest func(*http.Request) (*http.Response, error)
}

type C struct {
    n int
}
func (c C) Get() int { return c.n }

c := C{1}
f := c.Get              // method value: копия c захвачена сейчас
c.n = 99
fmt.Println(f())        // 1, а не 99

g := C.Get              // method expression: func(C) int
fmt.Println(g(c))       // 99

// С pointer receiver захватывается указатель, а не копия:
type D struct {
    n int
}
func (d *D) Get() int { return d.n }
d := D{1}
h := d.Get              // захвачен &d
d.n = 99
fmt.Println(h())        // 99

Замыкания: что именно захватывается

Замыкание: функция, объявленная внутри другой функции и использующая её локальные переменные. Название отсюда: она замыкает на себе кусочек чужой области видимости и уносит его с собой. Внешняя функция давно вернулась, а переменная жива, пока жива функция-замыкание.

Из одного факта выводятся все задачи на эту тему: замыкание захватывает переменную, а не её значение. То есть ссылку на ячейку памяти, а не снимок того, что в ней лежало. Переменная переживает функцию, где объявлена? Тогда компилятор при escape-анализе переносит её в кучу, а замыкание держит на неё указатель. Все замыкания, созданные в одной области видимости, делят одну и ту же ячейку.

func counter() func() int {
    n := 0                 // уедет в кучу: живёт дольше counter()
    return func() int {
        n++                // изменяем ту самую ячейку
        return n
    }
}
c1, c2 := counter(), counter()
fmt.Println(c1(), c1(), c1())   // 1 2 3 — одна ячейка
fmt.Println(c2())               // 1 — у второго замыкания своя ячейка

// Два замыкания из одной области делят одну ячейку
func pair() (func(), func() int) {
    n := 0
    return func(){ n++ }, func() int { return n }
}
inc, get := pair()
inc(); inc()
fmt.Println(get())              // 2

// Классика собеседований
for i := 0; i < 3; i++ {
    go func() { fmt.Print(i, " ") }()
}
time.Sleep(time.Second)
// Go < 1.22: "3 3 3" (обычно) — одна переменная на весь цикл
// Go >= 1.22: "0 1 2" в произвольном порядке — своя переменная на итерацию

// То же с range:
for _, v := range []int{1, 2, 3} {
    go func() { fmt.Print(v, " ") }()
}
// Go < 1.22: "3 3 3"; Go >= 1.22: 1 2 3 в любом порядке

// Как писали до 1.22 (и как всё ещё пишут для совместимости):
for i := 0; i < 3; i++ {
    i := i                       // затеняем: новая переменная на итерацию
    go func() { fmt.Print(i) }()
}
for i := 0; i < 3; i++ {
    go func(i int) { fmt.Print(i) }(i)   // передаём копию параметром
}
// оба варианта печатают 0, 1 и 2 ровно по разу, но в произвольном
// порядке: четыре прогона подряд дали "201", "210", "201", "210"

// Переменная объявлена ВНЕ цикла — семантика прежняя, ловушка осталась
x := 0
for i := 0; i < 3; i++ {
    x = i
    go func(){ fmt.Print(x) }()     // все смотрят в один x
}
// четыре прогона подряд на go1.27 дали "222": горутины стартуют после цикла,
// когда x уже равен 2. Гарантии нет — но именно так это обычно и выглядит.

// Захват элемента слайса по указателю — тоже осталось
var ptrs []*int
for _, v := range []int{1,2,3} { ptrs = append(ptrs, &v) }
// в Go 1.22+ здесь как раз всё хорошо: три разных v.
// А вот так — по-прежнему одна ячейка:
v2 := 0
for _, x := range []int{1,2,3} { v2 = x; ptrs = append(ptrs, &v2) }

Вариативные функции

...T в последнем параметре означает: внутри функции это обычный слайс []T. Компилятор на месте вызова собирает переданные аргументы в новый слайс.

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

Sum()             // 0   — nums == nil (не пустой слайс, а именно nil)
Sum(1, 2, 3)      // 6   — компилятор создал []int{1,2,3}

s := []int{1, 2, 3}
// Sum(s)         // ошибка компиляции:
//                // cannot use s (variable of type []int) as int value in argument to Sum
Sum(s...)         // 6 — передали существующий слайс, новый не создаётся

// При s... слайс не копируется: функция получает тот же массив
func Zero(nums ...int) { for i := range nums { nums[i] = 0 } }
Zero(s...)
fmt.Println(s)    // [0 0 0] — исходный слайс изменён
Zero(1, 2, 3)     // а тут менялся бы временный слайс

// Смешивать нельзя:
// Sum(1, s...)   // ошибка компиляции: too many arguments in call to Sum
//                //                    have (number, []int...)

// Идиома: вариативный интерфейс
func Printf(format string, args ...any)   // каждый аргумент упаковывается в any

defer: механика

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

func demo() {
    for i := 0; i < 3; i++ {
        defer fmt.Print(i, " ")     // аргумент вычислен сразу: 0, 1, 2
    }
}
// вывод: 2 1 0  — LIFO

func demo2() {
    i := 0
    defer fmt.Println("аргумент:", i)              // скопировано 0
    defer func() { fmt.Println("замыкание:", i) }()// прочтёт при выходе
    i = 42
}
// замыкание: 42
// аргумент: 0

// Метод тоже вычисляется сразу, вместе с получателем:
var b bytes.Buffer
defer fmt.Println(b.String())    // "" — String() вызовется сейчас
b.WriteString("текст")
// напечатает пустую строку

// А так правильно:
defer func(){ fmt.Println(b.String()) }()

// Плохо: 100k открытых файлов одновременно
func processAll(paths []string) error {
    for _, p := range paths {
        f, err := os.Open(p)
        if err != nil { return err }
        defer f.Close()          // выполнится только в конце processAll
        process(f)
    }
    return nil
}

// Хорошо, вариант 1: у замыкания своя область видимости
func processAll1(paths []string) error {
    for _, p := range paths {
        err := func() error {
            f, err := os.Open(p)
            if err != nil { return err }
            defer f.Close()      // выполнится на выходе из этой функции
            return process(f)
        }()
        if err != nil { return err }
    }
    return nil
}

// Хорошо, вариант 2: именованная функция нагляднее
func processOne(p string) error {
    f, err := os.Open(p)
    if err != nil { return err }
    defer f.Close()
    return process(f)
}

defer и именованные возвращаемые значения

return x в Go разворачивается в две операции: сначала присвоить x в возвращаемое значение, потом выполнить defer-ы и только потом вернуть управление. Если возвращаемое значение именованное, defer его перепишет: он видит переменную.

// Без имени: defer меняет копию, эффекта нет
func a() int {
    x := 1
    defer func() { x = 99 }()
    return x               // 1
}

// С именем: defer меняет саму возвращаемую переменную
func b() (x int) {
    x = 1
    defer func() { x = 99 }()
    return x               // 99
}

// То же с ошибкой, так чаще всего и делают
func doTx(db *sql.DB) (err error) {
    tx, err := db.Begin()
    if err != nil { return err }
    defer func() {
        if p := recover(); p != nil {
            tx.Rollback()
            panic(p)                       // пробрасываем дальше
        } else if err != nil {
            tx.Rollback()                  // видим ошибку, потому что err именованная
        } else {
            err = tx.Commit()              // и можем вернуть ошибку коммита
        }
    }()
    // ... работа ...
    return nil
}

// Добавляем к ошибке контекст
func readConfig(path string) (err error) {
    defer func() {
        if err != nil { err = fmt.Errorf("readConfig(%s): %w", path, err) }
    }()
    // ... любые return err без обёртки ...
}

// На границе пакета паника становится ошибкой
func Parse(s string) (res AST, err error) {
    defer func() {
        if r := recover(); r != nil {
            err = fmt.Errorf("parse: %v", r)
        }
    }()
    return mustParse(s), nil    // внутри может паниковать
}

Сколько стоит defer

Вопрос «дорогой ли defer» проверяет, читал ли ты release notes. Правильный ответ: раньше был дорогим, с Go 1.14 практически бесплатен в типичном случае. Стоимость менялась три раза, и это хорошая история для собеса.

Три слова из таблицы ниже расшифруем сразу. _defer: служебная запись, которую рантайм заводит на каждый отложенный вызов, там лежит что вызвать, с какими аргументами и кто следующий в списке. Инлайнить: подставлять нужные инструкции прямо в место вызова вместо настоящего вызова функции, обычная оптимизация компилятора. Open-coded defer, дословно «defer, раскрытый в код»: компилятор заранее знает, какие отложенные вызовы есть в функции, и вписывает их перед каждым return под проверку одного бита. Ни записей, ни списка, ни обхода при выходе.

// Замер: go test -bench=. -benchmem
func BenchmarkDirect(b *testing.B) {
    for b.Loop() {              // Go 1.24+: так теперь пишут бенчмарки
        mu.Lock()
        counter++
        mu.Unlock()
    }
}

func BenchmarkDefer(b *testing.B) {
    for b.Loop() {
        func() {
            mu.Lock()
            defer mu.Unlock()   // open-coded: разница в единицы наносекунд
            counter++
        }()
    }
}

panic и recover: механика

panic(v) это не «исключение» в смысле Java/C++. Никакого catch-блока нет, вмешаться можно ровно одним способом: recover() внутри отложенной функции. Механика по шагам:

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

// 1) Не работает: recover не в отложенной функции
func bad1() {
    if r := recover(); r != nil { /* всегда nil */ }
    panic("boom")
}

// 2) Не работает: recover на уровень глубже, чем defer
func helper() { recover() }        // nil
func bad2() {
    defer func() { helper() }()    // helper — не отложенная функция
    panic("boom")
}

// 3) Работает: recover прямо в теле отложенной функции
func good1() (err error) {
    defer func() {
        if r := recover(); r != nil {
            err = fmt.Errorf("recovered: %v", r)
        }
    }()
    panic("boom")
}

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

Что recover НЕ ловит

Часть аварий в Go это вообще не panic, а fatal error рантайма. Их не перехватить ничем, процесс умирает сразу и без раскрутки стека:

• fatal error: concurrent map writes / concurrent map read and map write: гонка на мапе, пойманная встроенной проверкой.
• fatal error: all goroutines are asleep - deadlock!: рантайм видит, что работать некому.
• fatal error: stack overflow: стек упёрся в лимит (по умолчанию 1 ГБ на 64-битных).
• fatal error: out of memory, ошибки в самом рантайме, сбой в CGO-коде.
• os.Exit() вообще не паника, defer-ы не выполняются.
• runtime.Goexit() завершает горутину и выполняет defer-ы, но recover() вернёт nil: паники нет.

Когда panic уместен, а когда нужен error

// Паттерн encoding/json: паника внутри, error снаружи
type parseError struct {
    err error
}

func (p *parser) fail(format string, a ...any) {
    panic(parseError{fmt.Errorf(format, a...)})   // свой тип, чтобы отличать чужие паники
}

func Parse(data []byte) (res Doc, err error) {
    defer func() {
        if r := recover(); r != nil {
            pe, ok := r.(parseError)
            if !ok { panic(r) }        // чужую панику пробрасываем: она про баг, а не про ввод
            err = pe.err
        }
    }()
    p := &parser{data: data}
    return p.parseDoc(), nil           // внутри вызывается fail() на любой глубине
}

Паника в горутине

Самый частый вопрос по теме и самая частая ошибка в проде. Ответ короткий: recover ловит панику только в своей горутине. Стек у каждой горутины свой, раскрутка идёт по нему и до фреймов «родителя» не доходит. Родителя в стековом смысле вообще нет, горутины не вложены.

// Не работает: процесс упадёт
func main() {
    defer func() {
        if r := recover(); r != nil { fmt.Println("поймали:", r) }  // не выполнится
    }()
    go func() { panic("из горутины") }()
    time.Sleep(time.Second)
}
// panic: из горутины ... exit status 2

// Работает: recover внутри той же горутины
func safeGo(fn func()) {
    go func() {
        defer func() {
            if r := recover(); r != nil {
                log.Printf("panic in goroutine: %v\n%s", r, debug.Stack())
            }
        }()
        fn()
    }()
}

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

os.Exit vs panic vs return из main

// Канонический паттерн: os.Exit только в самом конце
func main() {
    if err := run(); err != nil {
        fmt.Fprintln(os.Stderr, "error:", err)
        os.Exit(1)                       // defer-ов здесь уже нет, можно
    }
}

func run() error {
    db, err := sql.Open("pgx", os.Getenv("DSN"))
    if err != nil { return err }
    defer db.Close()                     // выполнится при любом return из run

    shutdown, err := initTracing()
    if err != nil { return err }
    defer shutdown(context.Background())

    ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
    defer stop()

    return serve(ctx, db)
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.7Дженерики

Самая молодая большая фича языка (Go 1.18, март 2022) и самая «модная» тема на собесах: по ней сразу видно, читал ли кандидат хоть что-то за пределами туториалов. Синтаксис знают почти все. Расходятся кандидаты в трёх местах: понимают ли, что констрейнт задаёт множество типов, а не «интерфейс с методами»; знают ли, что Go не делает мономорфизацию и почему из-за этого дженерик-код бывает медленнее обычного; и найдётся ли трезвый ответ на «когда дженерики хуже интерфейсов».

Зачем они вообще появились

До 1.18 у Go было ровно три способа написать «одно и то же для разных типов», и каждый чем-то плох. Дженерики закрывают конкретный, довольно узкий пробел: статически типизированный код, одинаковый по структуре, но разный по типу элементов. Не «ООП» и не «шаблоны на все случаи жизни». Именно это.

Синтаксис: параметры типа

Параметры типа объявляются в квадратных скобках сразу после имени функции или типа. Каждый параметр состоит из имени и констрейнта. Констрейнт обязателен: даже «любой тип» пишется явно как any (это алиас для interface{}, добавленный в 1.18 ради читаемости).

// Дженерик-функция: два параметра типа, оба используются в обычной сигнатуре
func Map[E any, R any](s []E, f func(E) R) []R {
    r := make([]R, 0, len(s))    // R можно использовать как обычный тип
    for _, v := range s {
        r = append(r, f(v))
    }
    return r
}

// Вызов: типы выводятся из аргументов
names := Map([]int{1, 2, 3}, strconv.Itoa)   // []string

// Инстанцируем явно, когда вывести не из чего
parse := Map[string, int]                    // получили обычную func([]string, func(string) int) []int

// Дженерик-тип: параметры типа у объявления типа
type Stack[T any] struct {
    items []T
}

// Методы дженерик-типа перечисляют параметры получателя.
// До Go 1.27 добавить к ним свои параметры типа было нельзя; с 1.27 можно (см. ниже).
func (s *Stack[T]) Push(v T) { s.items = append(s.items, v) }
func (s *Stack[T]) Pop() (T, bool) {
    var zero T                                // нулевое значение параметра типа — только так
    if len(s.items) == 0 {
        return zero, false
    }
    v := s.items[len(s.items)-1]
    s.items = s.items[:len(s.items)-1]
    return v, true
}

// Дженерик-тип всегда используют с аргументами типа
var st Stack[string]                          // ок
// var bad Stack                              // ошибка: cannot use generic type Stack without instantiation

Констрейнты: интерфейс как множество типов

Формулировка, которую стоит держать наготове: в Go 1.18 изменилось само определение интерфейса. Раньше интерфейс задавал множество методов. Теперь он задаёт множество типов, а список методов просто один из способов это множество задать. interface{ Read([]byte) (int, error) } задаёт множество всех типов, у которых есть такой метод. interface{ int | string } перечисляет ровно два типа. Констрейнтом называют интерфейс, поставленный в позицию параметра типа.

Тильда ~: почему без неё всё ломается

int в констрейнте означает ровно тип int, ни строчкой больше. А в реальном коде сплошь и рядом встречаются именованные типы: type UserID int, type Weekday int, type Kilometers float64. Такой тип не удовлетворяет констрейнту int, потому что это другой тип. ~int читается как «любой тип, у которого underlying type совпадает с int» и включает и сам int, и все производные от него именованные типы.

type Strict interface{ int }        // множество = {int}
type Loose  interface{ ~int }       // множество = {int, UserID, Weekday, ...}

type UserID int

func StrictSum[T Strict](xs []T) T { var s T; for _, x := range xs { s += x }; return s }
func LooseSum[T Loose](xs []T)  T { var s T; for _, x := range xs { s += x }; return s }

ids := []UserID{1, 2, 3}
// StrictSum(ids)   // ошибка: UserID does not satisfy Strict (possibly missing ~ for int)
LooseSum(ids)       // ок → UserID(6)

// Ограничение тильды: справа от ~ должен стоять тип, чей underlying — он сам.
// type MyInt = ~int          // нельзя: ~ вне интерфейса
// interface{ ~UserID }       // ошибка: invalid use of ~ (underlying type of UserID is int)

comparable и constraints.Ordered

comparable остаётся единственным встроенным констрейнтом, который не выразить синтаксисом объединения: множество «типов, у которых == определён и не паникует» включает все числа, строки, булевы, указатели, каналы, интерфейсы, а ещё массивы и структуры из таких типов. Набор выходит бесконечный, его задаёт рекурсивное правило. Поэтому он зашит в компилятор.

// comparable нужен там, где значение идёт ключом мапы или сравнивается
func Unique[T comparable](s []T) []T {
    seen := make(map[T]struct{}, len(s))     // ключ мапы обязан быть comparable
    out := make([]T, 0, len(s))
    for _, v := range s {
        if _, ok := seen[v]; !ok {
            seen[v] = struct{}{}
            out = append(out, v)
        }
    }
    return out
}

Unique([]int{1, 1, 2})                       // ок
Unique([]struct {
    A int
}{{1}, {1}})          // ок — структура из comparable полей
// Unique([][]byte{{1}})                     // ошибка: []byte does not satisfy comparable

constraints.Ordered живёт в golang.org/x/exp/constraints, то есть вне стандартной библиотеки, и это осознанное решение. Команда Go решила не фиксировать в stdlib набор «удобных» констрейнтов, пока не станет ясно, какие из них действительно нужны: однажды попав в std, они попадают под гарантию совместимости навсегда. Практический ответ на собесе: «в проде я не тяну x/exp ради трёх строк, объявляю свой Ordered локально, это ровно один интерфейс».

// Это ровно x/exp/constraints, можно скопировать к себе
type Signed   interface{ ~int | ~int8 | ~int16 | ~int32 | ~int64 }
type Unsigned interface{ ~uint | ~uint8 | ~uint16 | ~uint32 | ~uint64 | ~uintptr }
type Integer  interface{ Signed | Unsigned }          // объединение констрейнтов
type Float    interface{ ~float32 | ~float64 }
type Ordered  interface{ Integer | Float | ~string }  // всё, где работают < и >

// Complex в Ordered не входит: комплексные числа не упорядочены.

func Max[T Ordered](a, b T) T { if a > b { return a }; return b }
func Clamp[T Ordered](v, lo, hi T) T {
    if v < lo { return lo }
    if v > hi { return hi }
    return v
}

Собственные констрейнты через интерфейсы

Констрейнт остаётся обычным интерфейсом, поэтому собирать его можно из чего угодно: методов, объединений типов, других констрейнтов. Три рабочих приёма, которые реально встречаются в проде.

// 1. Метод + тип одновременно (пересечение множеств)
type Stringish interface {
    ~string
    Len() int        // тип обязан иметь underlying string и метод Len
}

// 2. Констрейнт «указатель на T»: иначе это не выразить.
//    Классика: функция должна создать значение и вызвать на нём pointer-метод.
type Unmarshaler[T any] interface {
    *T                       // один терм: указатель на T
    json.Unmarshaler
}

func DecodeAll[T any, PT Unmarshaler[T]](raws [][]byte) ([]T, error) {
    out := make([]T, 0, len(raws))
    for _, raw := range raws {
        var v T
        if err := PT(&v).UnmarshalJSON(raw); err != nil {   // &v имеет тип *T = PT
            return nil, err
        }
        out = append(out, v)
    }
    return out, nil
}
// Вызов: DecodeAll[User](raws) — PT выводится из T автоматически

// 3. Констрейнт на «слайс своего типа» сохраняет именованный тип результата
type Slice[E any] interface{ ~[]E }

func Filter[S Slice[E], E any](s S, keep func(E) bool) S {
    out := make(S, 0, len(s))     // тип результата S, а не []E
    for _, v := range s {
        if keep(v) { out = append(out, v) }
    }
    return out
}

type IDs []int
var ids IDs = []int{1, 2, 3}
r := Filter(ids, func(i int) bool { return i > 1 })   // r имеет тип IDs, а не []int

Вывод типов: когда работает и когда нет

Вывод типов в Go намеренно ограничен. Он идёт только «снизу вверх» от типов аргументов (function argument type inference) и дополняется выводом из самих констрейнтов (constraint type inference). Из типа результата, из контекста присваивания и из тела функции Go не выводит ничего, в отличие от Rust или Haskell. Выбор сознательный: так проще, и сообщения об ошибках предсказуемее.

// Классический промах вывода
func New[T any]() *T { return new(T) }
// p := New()          // ошибка: cannot infer T
p := New[User]()       // ок

// Ещё один: reduce, где аккумулятор другого типа
func Reduce[E, A any](s []E, init A, f func(A, E) A) A { ... }
sum := Reduce([]int{1,2,3}, 0, func(a, e int) int { return a + e })   // ок: A выведен из init

// А так не выведется, потому что тип литерала неизвестен до вывода A:
// Reduce([]int{1,2,3}, 0, func(a, e) int { return a + e })  // так нельзя: у литерала функции типы параметров обязательны

// Go 1.21 заметно усилил вывод: теперь работает передача дженерик-функции
// в дженерик-функцию без явных аргументов типа.
res := Map([]int{1,2,3}, strconv.Itoa)      // 1.18+
srt := slices.SortedFunc(maps.Keys(m), cmp.Compare)   // 1.23, вывод через несколько уровней

Дженерики или интерфейсы: аргументы обеих сторон

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

Когда дженерики — плохой выбор

• Слой репозитория / storage. Repository[T] выглядит красиво ровно до первого метода FindByEmail. Дальше начинается либо union-констрейнт из всех сущностей, либо рефлексия для имени таблицы, либо интерфейс сбоку. Выходит хуже, чем три честных репозитория.
• Там, где нужен мок. Подменить T в тесте нельзя: тип фиксируется на этапе компиляции. Границы с внешним миром должны быть интерфейсами.
• Одна-две инстанциации. Дженерик ради двух типов крадёт читаемость, добавляет к размеру бинаря и ничего не даёт. Две функции честнее.
• Union из «всех типов, которые я знаю». Такой констрейнт нельзя расширить снаружи пакета: каждый новый тип означает правку библиотеки. Анти-паттерн, если только множество действительно не замкнуто (например, числовые типы).
• Кодогенерация вместо дизайна. Если сигнатура выглядит как func Do[A, B, C any, F ~func(A) (B, error)](...), читать это будет невозможно, и через полгода перепишут в первую очередь именно её.

Когда дженерики — явно правильный выбор

• Контейнеры и структуры данных: Set[T], Queue[T], OrderedMap[K,V], LRU-кэш, лок-фри очередь.
• Алгоритмы над коллекциями: slices, maps, group-by, chunk, partition.
• Инфраструктурные обёртки: Pool[T] (типобезопасный sync.Pool), Result[T], Optional[T], singleflight с типом.
• Конкурентные примитивы: Fanout[T], типизированный errgroup-воркер, батчер.
• Устранение зеркальных пакетов: там, где раньше писали strings и bytes отдельно.

// Пример, где дженерик даёт настоящую пользу: типобезопасный sync.Pool.
// Без него на каждом Get стоит .(*Buffer), а такой assertion может паниковать.
type Pool[T any] struct {
    p   sync.Pool
    new func() T
}

func NewPool[T any](new func() T) *Pool[T] {
    return &Pool[T]{p: sync.Pool{New: func() any { return new() }}, new: new}
}
func (p *Pool[T]) Get() T   { return p.p.Get().(T) }   // assertion спрятана внутри, наружу — T
func (p *Pool[T]) Put(v T)  { p.p.Put(v) }

// Пример, где дженерик — ошибка: «универсальный репозиторий»
type Repo[T any] interface {
    Get(ctx context.Context, id int64) (T, error)
    Save(ctx context.Context, v T) error
}
// Дальше понадобится ListActive, FindByEmail, UpdateBalance — и абстракция рассыпается.
// Плюс имя таблицы всё равно берут рефлексией или из отдельного метода, так что
// типобезопасность, ради которой всё затевалось, теряется в самом важном месте.

Как это работает под капотом: GC shape stenciling

Классических способов реализовать дженерики ровно два, и оба чего-то стоят. Мономорфизация (C++ templates, Rust): компилятор генерирует отдельную копию машинного кода под каждый набор типов. Скорость максимальная, зато бинарь и время сборки растут взрывом. Стирание типов (Java generics, Go до 1.18 через interface{}): один код, все значения приводятся к общему представлению. Бинарь маленький, зато боксинг, аллокации и косвенные вызовы.

Go выбрал гибрид, «GC shape stenciling». Слово stencil переводится как трафарет: компилятор берёт тело дженерик-функции и «печатает» по нему готовую копию машинного кода; такую копию и называют стенсилом. Печатает он их не по одной на каждый тип, а по одной на каждую GC-форму, то есть на каждую группу типов, которые по размеру и раскладке указателей внутри выглядят для сборщика мусора одинаково. Всё, что у типов из одной группы всё-таки разное (описание типа, адреса методов, itab), передаётся отдельно, скрытым первым аргументом, который называют словарём. Правило группировки из design-документа звучит буквально так:

Что лежит в словаре

Словарём зовут статическую структуру, которую компилятор кладёт в read-only секцию бинаря (по одной на каждую конкретную инстанциацию, не на форму) и передаёт скрытым первым аргументом. Внутри лежит всё, чего стенсил знать не может: он один на много типов.

Пакеты slices и maps

Главный продукт дженериков для повседневного кода. Оба пакета переехали из golang.org/x/exp в стандартную библиотеку в Go 1.21, вместе с пакетом cmp (там живёт cmp.Ordered, cmp.Compare, cmp.Or). В Go 1.23 оба пакета получили вторую волну функций, уже на итераторах.

import ("slices"; "maps"; "cmp")

// ── slices: поиск и сортировка ──────────────────────────────────────
xs := []int{5, 2, 9, 2}

slices.Sort(xs)                       // [2 2 5 9] — pdqsort, без рефлексии
slices.SortStableFunc(users, func(a, b User) int {
    return cmp.Compare(a.Age, b.Age)  // компаратор возвращает -1/0/+1, а не bool
})
i, found := slices.BinarySearch(xs, 5)          // 2, true — только на отсортированном
idx := slices.Index(xs, 9)                      // 3, или -1
ok  := slices.Contains(xs, 2)                   // true
j   := slices.IndexFunc(users, func(u User) bool { return u.Admin })

// ── slices: сравнение и модификация ─────────────────────────────────
slices.Equal([]int{1,2}, []int{1,2})            // true — поэлементно, без reflect
slices.Compare(a, b)                            // лексикографически: -1/0/+1
xs = slices.Compact(xs)                         // убирает подряд идущие дубли: [2 5 9]
xs = slices.Insert(xs, 1, 7, 8)                 // вставляет несколько по индексу
xs = slices.Delete(xs, 1, 3)                    // удаляет полуинтервал [1:3)
slices.Reverse(xs)
c := slices.Clone(xs)                           // поверхностная копия
m := slices.Max(xs)                             // паникует на пустом слайсе
g := slices.Grow(xs, 100)                       // гарантирует cap для 100 доп. элементов
xs = slices.Clip(xs)                            // cap = len: append больше не пишет в общий хвост; массив тот же

// ── maps ────────────────────────────────────────────────────────────
mm := map[string]int{"a": 1, "b": 2}
maps.Clone(mm)                                  // поверхностная копия
maps.Equal(mm, other)                           // сравнивает по значениям
maps.Copy(dst, src)                             // src поверх dst
maps.DeleteFunc(mm, func(k string, v int) bool { return v == 0 })

// ── Go 1.23: итераторы (iter.Seq) ───────────────────────────────────
for k := range maps.Keys(mm) { _ = k }          // maps.Keys теперь возвращает итератор
keys := slices.Sorted(maps.Keys(mm))            // []string{"a","b"} — идиома «ключи по порядку»
for i, v := range slices.All(xs) { _, _ = i, v }
for v := range slices.Values(xs) { _ = v }
back := slices.Backward(xs)                     // итератор в обратном порядке
xs2  := slices.Collect(maps.Values(mm))         // итератор → слайс

Go 1.26 и 1.27: что в дженериках изменилось

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

Go 1.27: у методов появились собственные параметры типа

Годами правильным ответом на собесе было «параметр типа у метода объявить нельзя, выноси в свободную функцию». С Go 1.27 это неверно. Метод обычного или дженерик-типа теперь объявляет свои параметры типа ровно так же, как функция:

type Box struct {
    v []int
}

// Go 1.27: метод объявляет собственный параметр типа T
func (b *Box) MapTo[T any](f func(int) T) []T {
    out := make([]T, 0, len(b.v))
    for _, x := range b.v { out = append(out, f(x)) }
    return out
}

b := &Box{v: []int{1, 2, 3}}
fmt.Println(b.MapTo(func(i int) string { return strconv.Itoa(i * 2) }))  // [2 4 6]

// Работает и для дженерик-типа: получатель перечисляет свои параметры, метод добавляет свои
type Stack[T any] struct {
    items []T
}
func (s *Stack[T]) MapTo[R any](f func(T) R) *Stack[R] {
    out := &Stack[R]{items: make([]R, 0, len(s.items))}
    for _, v := range s.items { out.items = append(out.items, f(v)) }
    return out
}

Пример из стандартной библиотеки есть в math/rand/v2: метод Rand.N() стал дженерик-методом, поэтому r.N(100) возвращает int, а r.N(time.Second) уже time.Duration, без конверсий на месте вызова.

type Mapper interface {
    MapTo[T any](f func(int) T) []T   // ошибка: interface method must have no type parameters
}

Go 1.26: дженерик-тип может ссылаться на себя в собственном констрейнте

Раньше компилятор отвергал «self-referential» констрейнт, когда параметр типа ограничен интерфейсом, параметризованным этим же параметром. С Go 1.26 это легально, и привычный по другим языкам паттерн «тип, который умеет складываться сам с собой» наконец выражается прямо:

// Go 1.26+
type Adder[A Adder[A]] interface{ Add(A) A }

type Num int
func (n Num) Add(o Num) Num { return n + o }

func Sum[A Adder[A]](xs []A) A {
    var acc A
    for _, x := range xs { acc = acc.Add(x) }
    return acc
}
fmt.Println(Sum([]Num{1, 2, 3}))   // 6

Читается это так: «A может быть любым типом, у которого есть метод Add, принимающий и возвращающий этот же самый A». Без самоссылки такой контракт выражался только через any и рантайм-проверки.

Go 1.26: new принимает выражение

Не про дженерики, но про тот же класс неудобств. Раньше new принимал только тип, и чтобы получить указатель на результат выражения, приходилось заводить временную переменную ради &tmp. Теперь можно передать само выражение:

// До 1.26
tmp := compute()
p := &tmp

// Go 1.26+
p := new(compute())     // *T, где T — тип результата compute()

// Особенно заметно на литералах и константах, у которых нельзя взять адрес напрямую:
q := new(42)            // *int
r := new(len(s) * 2)    // *int

Применяют это в опциональных полях структур (Field *int) и в параметрах клиентов облачных API, где половина кода раньше состояла из вызовов самописного помощника func ptr[T any](v T) *T. Такой помощник теперь не нужен.

Go 1.27: вывод типов стал общее

Раньше вывод типов работал главным образом в точке вызова: из аргументов. В 1.27 он обобщён на все контексты, где дженерик-функция присваивается переменной или конвертируется в совместимый тип функции. Практически это значит, что в таких местах реже приходится писать аргументы типа руками: компилятор берёт их из типа приёмника.

Чего дженерики в Go не умеют — и почему

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

// Обход №1 (нужен только до Go 1.27 либо когда метод обязан жить в интерфейсе)
type Stack[T any] struct {
    items []T
}

// func (s *Stack[T]) Map[R any](f func(T) R) *Stack[R]   // до 1.27 не компилировалось,
//                                                        // с 1.27 вполне легально
func MapStack[T, R any](s *Stack[T], f func(T) R) *Stack[R] {
    out := &Stack[R]{items: make([]R, 0, len(s.items))}
    for _, v := range s.items { out.items = append(out.items, f(v)) }
    return out
}

// Обход №2: «специализация» руками, через type switch по any(v)
func Format[T any](v T) string {
    switch x := any(v).(type) {          // конверсия any(v) обязательна
    case time.Time:  return x.Format(time.RFC3339)
    case error:      return x.Error()
    case fmt.Stringer: return x.String()
    default:         return fmt.Sprint(v)
    }
}
// Цена: это рантайм-проверка. Если такой switch занимает всё тело, дженерик тут лишний:
// достаточно обычного func Format(v any) string.

// Обход №3: инвариантность — почему это не баг
type List[T any] struct {
    xs []T
}
var dogs List[*Dog]
// var animals List[*Animal] = dogs      // ошибка, и правильно:
// иначе через animals.Append(&Cat{}) в dogs попал бы кот.

// Функция
func Keys[K comparable, V any](m map[K]V) []K {
    out := make([]K, 0, len(m))
    for k := range m { out = append(out, k) }
    return out
}

// Тип + методы: получатель перечисляет параметры типа, но не вводит новые
type Set[T comparable] struct{ m map[T]struct{} }

func NewSet[T comparable](vs ...T) *Set[T] {
    s := &Set[T]{m: make(map[T]struct{}, len(vs))}
    for _, v := range vs { s.m[v] = struct{}{} }
    return s
}
func (s *Set[T]) Add(v T)          { s.m[v] = struct{}{} }
func (s *Set[T]) Has(v T) bool     { _, ok := s.m[v]; return ok }
func (s *Set[T]) Len() int         { return len(s.m) }

// Нулевое значение параметра типа — через var, *new(T) или именованный результат
func (s *Set[T]) Any() (T, bool) {
    for v := range s.m { return v, true }
    var zero T                       // не nil и не 0, а var zero T
    return zero, false
}

type Number interface{ ~int | ~int64 | ~float64 }

func Sum[T Number](xs []T) T {
    var s T
    for _, x := range xs { s += x }   // + разрешён: он есть у всех типов множества
    return s
}

// А вот так уже нельзя:
type Weird interface{ ~int | ~string }
func Bad[T Weird](a, b T) T {
    return a - b       // ошибка: оператор - не определён для string
    // при этом a + b сработало бы: + есть и у чисел, и у строк
}

type Celsius float64

func SumStrict[T interface{ float64 }](xs []T) T { ... }
func SumLoose [T interface{ ~float64 }](xs []T) T { ... }

temps := []Celsius{36.6, 37.1}
// SumStrict(temps)   // ошибка: Celsius does not satisfy interface{float64}
//                    //         (possibly missing ~ for float64)
SumLoose(temps)       // ок

// Ограничение самой тильды: справа обязан стоять тип, чей underlying — он сам
// interface{ ~Celsius }   // ошибка: invalid use of ~ (underlying type of Celsius is float64)
// Поэтому нельзя написать «любой тип, производный от Celsius».