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

Практически: массивы берут для фиксированных структур (хеши [32]byte, UUID [16]byte, ключи мап, стековые буферы), слайсы во всём остальном. Массив почти всегда живёт внутри слайса или структуры, а не сам по себе.

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

Инварианты

• 0 <= len <= cap. Нарушить нельзя: make([]int, 5, 3) не скомпилируется.
• Индексация проверяется по len: s[len(s)] → паника index out of range.
• Нарезка проверяется по cap: s[:cap(s)] легально и «воскрешает» элементы за пределом len; s[:cap(s)+1] → паника slice bounds out of range.
• cap считается от начала окна до конца массива, а не от начала массива. Поэтому у s[2:] cap меньше, чем у s.

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)[:]          // +  экзотика: массив в куче + слайс на него

Почему преаллокация важна

Каждое перевыделение это mallocgc плюс memmove всего содержимого. Наполняешь слайс из 10 000 элементов без ёмкости, получаешь около 20 аллокаций и суммарно около 20 000 скопированных элементов; вдобавок промежуточные массивы становятся мусором и дают работу GC. С make([]T, 0, n) будет одна аллокация и ноль копирований.

// Типичная разница на бенчмарке (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]

Почему так

В функции появляется своя переменная s, копия заголовка. Запись s[0] = 100 идёт по указателю в общий массив, поэтому видна всем. А s = append(...) и s = nil меняют только локальную копию заголовка, которая умирает вместе с кадром функции.

Три способа отдать изменённый слайс наружу

1. Вернуть его. Идиоматично, так устроен сам append: func add(s []int, v int) []int.
2. Передать *[]T, когда возврат неудобен (пишешь интерфейс, заполняешь через колбэк).
3. Передать буфер и вернуть срез его же: паттерн AppendXxx(dst []byte, ...) []byte из стандартной библиотеки (strconv.AppendInt, time.Time.AppendFormat). Вызывающий владеет памятью, аллокаций ноль.

Алгоритм

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

Как менялась стратегия

Новая формула даёт множитель, который плавно спадает: примерно 1.75x при cap 256, 1.5x при 512, 1.44x при 1024 и приближается к 1.25x на больших размерах. Меняли ради того, чтобы убрать разрыв: раньше слайс на 1023 элемента рос вдвое, а на 1025 всего на четверть, и профиль потребления памяти скакал.

Округление до size class

Посчитанный newcap рантайм умножает на sizeof(T) и округляет вверх до ближайшего класса размеров аллокатора Go (8, 16, 24, 32, 48, 64, 80, 96, 112, 128, 144…). Разницу он возвращает обратно в cap. Поэтому в реальности видишь cap 848 вместо 640 и cap 8 вместо 6, а прогрессии для []byte, []int и []struct{...} отличаются.

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 - разные массивы

Почему это опасно на практике

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

Как правильно писать такие функции

1. Не мутировать вход без явного контракта. Нужна модификация, работай с копией: s = slices.Clone(in).
2. Если функция обязана только дописывать, верни результат и обяжи вызывающего присвоить (s = f(s)), как делает сам append.
3. Отдаёшь наружу подслайс, обрезай cap: return buf[:n:n] или slices.Clip.
4. Документируй в комментарии: «функция может изменить элементы аргумента». Это часть контракта.

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]

s2 это окно внутри массива s1. Первая запись очевидна. Вторая главный подвох: append пишет в первую ячейку за пределом len, но внутри cap, а эта ячейка принадлежит s1. Ни ошибки, ни предупреждения, просто данные соседа заменились.

Когда s1 НЕ изменится

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])    // то же самое, читаемее

Что делает Unmarshal со слайсом

Декодер сначала пытается переиспользовать переданную память: выставляет len = 0 и добавляет элементы через append (в коде encoding/json это growSlice/переиспользование v.SetLen). Пока cap хватает, новый массив не выделяется, элементы ложатся в тот же буфер. Когда входной массив короче, чем len слайса, декодер просто укорачивает длину через SetLen. Хвост он не зануляет, старые элементы так и остаются в массиве (проверено на go1.27 и с GOEXPERIMENT=nojsonv2).

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,
// а старые элементы остаются лежать в массиве.

А если во входном JSON элементов больше, чем cap подслайса (в примере больше 70), декодер выделит новый массив, скопирует туда и дальше будет писать уже в него. Тогда s1 пострадает частично: первые 70 элементов затрутся, остальные уйдут в новую память.

// Начало, 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) })

Про зануление

Если элементы это указатели, интерфейсы, строки, слайсы, мапы или структуры с такими полями, «удалённое» значение остаётся в массиве между len и cap и держится сборщиком мусора. Поэтому в аккуратном коде ячейку явно обнуляют. slices.Delete с Go 1.22 делает это сам.

Что именно происходит

1. s = s[1:] двигает array вперёд на один элемент и уменьшает len и cap. Освободившаяся ячейка в начале никуда не девается, она часть того же выделенного блока памяти.
2. append расходует остаток cap. Через cap итераций запас кончается и вызывается growslice: аллокация нового массива и копирование len элементов.
3. Старый массив после этого становится мусором целиком, но только в момент роста. До этого он живёт полностью, включая уже «удалённые» элементы в начале.
4. Если элементы указатели, всё, на что они ссылались, тоже остаётся живым. Это утечка уже не 8 байт на элемент, а целых объектов.

// Проверим на деле
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
}

Аллокатор Go выделяет объект одним куском в span; сборщик отмечает живым весь объект, если на него есть хоть один указатель. «Частичное» освобождение невозможно в принципе. То же со строками: substr := bigString[10:20] удерживает всю большую строку.

Третий индекс - про другое

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 остались нулями

Особенности

• Перекрытие безопасно: под капотом memmove, а не memcpy. copy(s, s[1:]) корректно сдвигает влево.
• Специальный случай copy(dst []byte, src string) язык разрешает: строка не конвертируется в []byte и аллокации не происходит.
• Типы должны совпадать (с точностью до алиасов элементов); copy([]int, []int64) не скомпилируется.
• Копирование поверхностное: у []*T скопируются указатели, объекты останутся общими.
• С Go 1.21 есть slices.Clone(s): внутри append(s[:0:0], s...), возвращает новый слайс той же длины.

// Идиома «клонировать»: три эквивалентных варианта
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() }   // бесполезно: инкрементим копию

Время жизни указателя

• Элемент слайса адресуем, элемент мапы нет. Причина ровно в этом: мапа переселяет элементы при росте, слайс не переселяет (переезжает целиком, но старая память остаётся валидной).
• Указатель удерживает весь массив от сборки, ещё один канал утечки.
• С Go 1.22 переменная цикла своя на каждой итерации, поэтому &v в range перестал давать «один адрес на всех». Но это по-прежнему адрес копии, а не элемента: семантика не изменилась, изменилось только время жизни.

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":[]}

Почему append работает с nil

append смотрит только на len и cap. У nil-слайса они нулевые, значит сразу идёт ветка growslice, которая выделяет новый массив и возвращает новый заголовок. Указатель nil никогда не разыменовывается, потому что копировать нечего. Та же логика в copy(nil, src): вернёт 0 без паники.

Где разница реально важна

• JSON-контракты: null вместо [] ломает клиентов. Лечится так: инициализировать out := []T{} в DTO или ставить omitempty (тогда поля не будет вовсе).
• reflect.DeepEqual считает их разными, поэтому тесты на nil/пустой падают. slices.Equal считает равными.
• Protobuf/gRPC: repeated-поля приходят как nil, если элементов нет.

Почему запрещено

• Побайтовое сравнение заголовков сравнивало бы адреса, а не данные. Почти всегда не то, чего ждёт человек, и вдобавок непереносимо.
• Поэлементное сравнение это O(n) под видом оператора ==, который во всех остальных местах языка стоит O(1). Go принципиально не прячет дорогие операции за короткий синтаксис.
• Слайсы бывают циклическими (s[0] содержит s через any), и «глубокое» сравнение потребовало бы обнаружения циклов в рантайме.
• Следствие того же ограничения: слайс не может быть ключом мапы и не удовлетворяет comparable.

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 исчерпан - новый массив только у этой строки

Многомерный массив - это другое

[3][4]int это настоящий двумерный массив: 12 int подряд, одно значение, копируется целиком, comparable. [][]int это слайс из трёх заголовков, каждый из которых указывает куда-то ещё. Разница в памяти: [3][4]int занимает 96 байт одним куском, [][]int берёт 24 байта заголовка + 3 × 24 байта заголовков строк + 3 × 32 байта данных, и всё это в разных местах кучи.

Плоское представление - быстрый и правильный способ

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]
}