Что происходит при добавлении элементов за пределы ёмкости slice?

Пример

package main

import "fmt"

func main() {
	s := make([]int, 3, 3) // len=3, cap=3
	s[0], s[1], s[2] = 1, 2, 3

	// append превышает cap=3 -> выделяется новый массив
	s2 := append(s, 4)

	fmt.Printf("s:  ptr=%p len=%d cap=%d val=%v\n", &s[0], len(s), cap(s), s)
	fmt.Printf("s2: ptr=%p len=%d cap=%d val=%v\n", &s2[0], len(s2), cap(s2), s2)
	// s2 указывает на ДРУГОЙ массив!

	s2[0] = 99
	fmt.Println("s[0]:", s[0])  // 1 — s не изменился
	fmt.Println("s2[0]:", s2[0]) // 99
}

Что происходит при append за пределами ёмкости

Когда вы вызываете append и новый элемент не помещается в текущую ёмкость (len == cap), рантайм Go выполняет следующие шаги:

1. Выделяет новый массив большего размера.
2. Копирует все существующие элементы в новый массив.
3. Добавляет новый элемент.
4. Возвращает новый slice-заголовок (новый указатель, новую ёмкость).

Исходный slice остаётся неизменным и указывает на старый массив.

Стратегия роста ёмкости

До Go 1.18: если cap < 1024, ёмкость удваивается; иначе растёт на 25%.
С Go 1.18+: используется плавная формула, которая постепенно уменьшает коэффициент роста по мере увеличения slice, что снижает потребление памяти.

Скрытое разделение памяти

a := make([]int, 3, 5) // len=3, cap=5 — есть запас
a[0], a[1], a[2] = 1, 2, 3

b := append(a, 4) // cap не превышена — b и a ДЕЛЯТ массив!
b[0] = 99
fmt.Println(a[0]) // 99! Мутация b изменила a

Это классическая ловушка: если после append не было перевыделения, слайсы делят один и тот же backing array.

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

// Явно ограничить cap при нарезке
sub := original[1:3:3] // len=2, cap=2 (third index)
// теперь append на sub всегда выделит новый массив

// Или явно скопировать
copy := append([]int{}, original...)

Предварительное выделение

// Если знаете итоговый размер — выделяйте заранее
result := make([]int, 0, len(input))
for _, v := range input {
	result = append(result, transform(v))
}
// Ноль перевыделений

Подводные камни

• Игнорирование возвращаемого значения append: append(s, x) без присваивания — наиболее частая ошибка; Go не ругается, но данные теряются.
• Скрытое разделение backing array между двумя слайсами: мутация через один меняет другой без очевидной причины.
• Передача slice в функцию и append внутри: если произошло перевыделение, вызывающий код не видит новый slice.
• Циклы с append без pre-allocation на больших входах создают O(log N) перевыделений и копирований.
• Три-индексный срез a[lo:hi:max] существует именно для ограничения cap, но редко используется на практике, что приводит к неожиданным разделениям.
• После масштабного append старый массив удерживается в памяти, пока жив хотя бы один slice, указывающий на него — риск утечки памяти.
• Начиная с Go 1.18 стратегия роста изменилась, поэтому код, полагающийся на точный размер cap после append, сломается на новых версиях.

• Давать ответ про append за пределами capacity slice только на уровне определения, не показывая поведение в реальном приложении.
• Игнорировать границы ответственности вокруг темы «append за пределами capacity slice»: кто отменяет работу, кто владеет ресурсом и где формируется ответ клиенту.
• Не связывать append за пределами capacity slice с observability, тестированием или безопасностью, когда это влияет на продакшен-поведение.

• Точно объясняет, что именно делает append за пределами capacity slice и где это используется в Go-коде.
• Связывает append за пределами capacity slice с корректным lifecycle запроса, отменой, конкурентностью или конфигурацией сервера там, где это уместно.
• Не изобретает API и опирается на реальные контракты официальной документации.