Частые ошибки при использовании функции append в Go

19 февраля 2026

Автор

Олег Марков

Введение

Функция append в Go кажется простой и понятной. Вы берете срез, добавляете в него элементы и получаете новый срез. Но на практике именно вокруг append возникает множество тонких и неочевидных ошибок.

Смотрите, в этой статье я покажу вам, какие проблемы чаще всего встречаются при работе с append, почему они возникают и как их избегать. Мы разберем влияние длины и емкости среза, поведение при передаче в функции, работу с nil-срезами, ловушки при использовании срезов как "окно" к массиву и ошибки производительности.

Чтобы материал был полезен вам в повседневной разработке, я буду опираться на реальные примеры кода и сопровождать их комментариями и пояснениями.

Как работает append и где начинаются ошибки

Прежде чем разбирать частые ошибки, нужно четко понимать, что делает append.

Краткое напоминание о срезах

Срез в Go — это не просто "динамический массив". Внутри он представляет собой структуру из трех полей:

указатель на область памяти с данными
длина (len)
емкость (cap)

Смотрите, в таком виде можно представить срез концептуально:

// Это не реальный код из стандартной библиотеки, а схема для понимания
type sliceHeader struct {
    Data uintptr // указатель на первый элемент
    Len  int     // длина - сколько элементов уже используется
    Cap  int     // емкость - сколько элементов доступно без перевыделения
}

Функция append работает так:

Если в срезе есть свободная емкость, новые элементы добавляются в ту же область памяти.
Если емкости не хватает, создается новый массив большего размера, туда копируются старые элементы, затем добавляются новые.

Основная ловушка — вы не всегда видите, был ли создан новый массив или данные продолжают лежать в старом. Именно из-за этого появляются "мистические" баги, когда меняется один срез, а неожиданно меняется и другой.

Ошибка 1. Ожидание, что append всегда создает новый массив

Одна из самых частых логических ошибок — считать, что каждый вызов append гарантированно возвращает срез с новой выделенной памятью.

Давайте разберемся на примере:

package main

import "fmt"

func main() {
    base := []int{1, 2, 3}
    a := base[:2] // len = 2, cap = 3
    b := base[:2] // len = 2, cap = 3

    // Добавляем элемент в a
    a = append(a, 100) // внутри еще есть место - cap = 3

    fmt.Println("base:", base) // base: [1 2 100]
    fmt.Println("a:", a)       // a: [1 2 100]
    fmt.Println("b:", b)       // b: [1 2 100] - неожиданно изменился
}

Комментарии по коду:

base := []int{1, 2, 3}
// Для base длина и емкость равны 3

a := base[:2]
// a указывает на тот же underlying array что и base
// len(a) = 2, cap(a) = 3

b := base[:2]
// b тоже указывает на тот же массив

a = append(a, 100)
// Емкость a позволяет разместить еще один элемент без выделения новой памяти
// Поэтому 100 записывается в тот же массив где лежат элементы base и b

Как видите, изменение среза a через append повлияло и на b, и на base. Это не ошибка компилятора, а прямое следствие общих данных.

Как избежать неожиданного совместного изменения

Если вы хотите получить новый независимый срез, нужно явно сделать копию:

aCopy := append([]int(nil), a...)
// Здесь мы создаем новый срез с отдельным массивом
// nil-срез + append гарантирует новое выделение памяти

aCopy = append(aCopy, 100)
// Теперь изменение aCopy не повлияет на a или base

Или, если вы хотите скопировать ровно нужный размер:

aCopy := make([]int, len(a))
copy(aCopy, a)
// aCopy теперь независим, но имеет тот же len

Практическое правило:

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

Ошибка 2. Неочевидное изменение "родительского" среза через под-срез

Часто разработчики используют под-срезы как "окно" к данным. Здесь важно понимать, что любой под-срез до момента перевыделения памяти использует тот же массив.

Давайте посмотрим пример, который часто встречается при обработке данных:

func process(data []int) []int {
    // Берем только первые два элемента для обработки
    sub := data[:2] // len = 2, cap >= 2

    // Модифицируем их
    sub[0] = 10
    sub[1] = 20

    // Добавляем новые элементы
    sub = append(sub, 30, 40)

    return sub
}

func main() {
    src := []int{1, 2, 3, 4}
    res := process(src)

    fmt.Println("src:", src)
    fmt.Println("res:", res)
}

Разберем, что здесь происходит:

sub := data[:2]
// sub и data смотрят на один и тот же массив
// len(sub) = 2, но cap(sub) скорее всего = 4 (как у data)

sub[0] = 10
sub[1] = 20
// Мы явно меняем data[0] и data[1]

sub = append(sub, 30, 40)
// Так как cap(sub) = 4 и len(sub) = 2, у нас есть место для двух новых элементов
// sub становится срезом длины 4 и использует тот же массив что и data
// В итоге data тоже меняется

Результат может быть таким:

src станет [10 20 30 40]
res будет [10 20 30 40]

Если вы ожидали, что src останется неизменным, это будет неприятным сюрпризом.

Как защитить исходные данные

Если вы не хотите менять исходный срез, есть два распространенных подхода.

Сразу копировать под-срез:

sub := append([]int(nil), data[:2]...)
// sub - независимая копия

Либо явно ограничить емкость под-среза, чтобы любая попытка append привела к выделению нового массива:

sub := data[:2:2]
// Синтаксис [low:high:max]:
// low - начало
// high - конец (len)
// max - cap

// В этом случае len(sub) = 2, cap(sub) = 2
// append(sub, 30, 40) приведет к созданию нового массива

Синтаксис с тремя числами в срезе часто упускают, а он как раз помогает вам управлять тем, будет ли под-срез "растягиваться" в исходный массив или сразу создаст новый.

Ошибка 3. Игнорирование того, что append возвращает новый срез

Еще одна распространенная ошибка — забывать, что append возвращает новый срез, а не изменяет существующий "по месту" в том смысле, как многие привыкли в других языках.

Смотрите, как выглядит типичный баг:

func main() {
    nums := []int{1, 2, 3}

    append(nums, 4) // результат игнорируется

    fmt.Println(nums) // [1 2 3] - 4 нет
}

Комментарии:

nums := []int{1, 2, 3}
// Инициализируем срез

append(nums, 4)
// Мы вызываем append, но не сохраняем результат
// Если массив расширился или даже нет - новый срез нам возвращен, но мы его игнорируем

fmt.Println(nums)
// nums остался старым, без нового элемента

Поэтому всегда запоминайте правило: срез, возвращенный append, нужно присвоить куда-либо:

nums = append(nums, 4)
// Теперь nums ссылается на обновленный срез

Или, если вы передаете срез в функцию, которая его расширяет, не забывайте вернуть новый срез и принять его:

func addElement(s []int, v int) []int {
    s = append(s, v)
    return s
}

func main() {
    nums := []int{1, 2, 3}
    nums = addElement(nums, 4) // важно присвоить
    fmt.Println(nums)          // [1 2 3 4]
}

Ошибка 4. Непонимание поведения append при передаче среза в функцию

Срез — ссылочный тип. Это значит, что при передаче его в функцию вы передаете копию структуры с указателем, длиной и емкостью. Часто разработчики путаются: какие изменения "видны снаружи", а какие нет.

Давайте посмотрим код, который часто вызывает вопросы:

func grow(s []int) {
    s = append(s, 100)
    // Здесь мы ожидаем, что исходный срез увеличится
}

func modify(s []int) {
    if len(s) > 0 {
        s[0] = 999
    }
}

func main() {
    nums := []int{1, 2, 3}

    grow(nums)
    fmt.Println("после grow:", nums) // длина не изменилась

    modify(nums)
    fmt.Println("после modify:", nums) // первый элемент изменен
}

Разбор:

func grow(s []int) {
    s = append(s, 100)
    // Здесь s - локальная копия структуры среза.
    // append может создать новый массив и вернуть новый срез.
    // Мы его присваиваем только локальной переменной s внутри функции.
    // Внешний nums остается прежним.
}

func modify(s []int) {
    s[0] = 999
    // Мы обращаемся к тому же массиву по указателю внутри среза.
    // Поэтому изменение видно снаружи.
}

Вывод:

Изменения элементов среза внутри функции видны снаружи.
Изменения самого среза (len, cap, указатель на массив) — нет, если вы не вернете его и не присвоите обратно.

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

Если вы хотите расширить срез внутри функции, всегда возвращайте его:

func grow(s []int) []int {
    s = append(s, 100)
    return s
}

func main() {
    nums := []int{1, 2, 3}
    nums = grow(nums) // обязательно присвоить
    fmt.Println(nums) // [1 2 3 100]
}

Иногда используют указатель на срез, но это нужно реже, чем кажется. Например:

func growPtr(s *[]int) {
    *s = append(*s, 100)
}

func main() {
    nums := []int{1, 2, 3}
    growPtr(&nums)
    fmt.Println(nums) // [1 2 3 100]
}

Этот вариант может быть полезен, если вы хотите изменить несколько срезов в разных местах или скрыть детали реализации, но чаще достаточно просто возвращать новый срез из функции.

Ошибка 5. Ожидание, что nil-срезы и пустые срезы ведут себя по-разному с append

В Go есть важное различие между nil-срезом и пустым срезом, но в контексте append это различие обычно не критично. Тем не менее, путаница вокруг этого часто приводит к лишним проверкам и странным условиям.

Смотрите:

var a []int        // nil-срез, len=0, cap=0, a == nil
b := []int{}       // пустой срез, len=0, cap=0, b != nil
c := make([]int, 0) // пустой срез, len=0, cap=0, c != nil

Однако:

a = append(a, 1)
b = append(b, 1)
c = append(c, 1)

Во всех трех случаях результат будет корректным, и вы получите срез длиной 1.

Ошибка здесь часто выглядит так:

if s == nil {
    s = []int{}
}
s = append(s, 1)

Эта проверка просто не нужна, если дальше вы все равно используете append. Он корректно работает и с nil-срезом.

Практический вывод:

Для коллекций, которые создаются "лениво", можно спокойно хранить nil-срез и не бояться паники при append.
Проверка на nil имеет смысл в основном при сериализации, логике API или сравнении значений, но не для безопасной работы append.

Ошибка 6. Использование append для конкатенации срезов без учета емкости и побочных эффектов

Часто нужно объединить два среза. Кажется, что решение проще не бывает:

a := []int{1, 2, 3}
b := []int{4, 5, 6}

a = append(a, b...) // "распаковываем" b

Это рабочий код, но здесь есть две распространенные проблемы:

Возможное изменение "родительского" массива, если a — под-срез другого среза.
Потенциальная лишняя аллокация и копирование, если вы часто конкатенируете срезы в цикле.

Пример скрытого изменения

Давайте посмотрим:

base := []int{1, 2, 3, 4, 5, 6}
a := base[:2] // len = 2, cap = 6
b := []int{100, 200}

a = append(a, b...)

fmt.Println("base:", base)
fmt.Println("a:", a)

Здесь:

a имеет cap = 6, поэтому при добавлении двух элементов не будет нового выделения памяти.
В итоге base частично изменится, даже если вы этого не хотите.

Чтобы гарантировать, что объединение создаст независимый срез, можно заранее выделить нужную емкость:

result := make([]int, 0, len(a)+len(b))
// len = 0, cap = len(a)+len(b)
// Теперь мы точно знаем, что все данные будут в новом массиве

result = append(result, a...)
result = append(result, b...)

Здесь я создаю отдельный срез result, используя make, и заполняю его из a и b. Это помогает лучше контролировать память и избежать неожиданных изменений исходных срезов.

Ошибка производительности при частой конкатенации

Если вы в цикле постоянно делаете:

for _, chunk := range chunks {
    result = append(result, chunk...)
}

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

Более эффективный вариант:

totalLen := 0
for _, chunk := range chunks {
    totalLen += len(chunk) // Считаем общую длину
}

result := make([]int, 0, totalLen)
// Выделяем память один раз

for _, chunk := range chunks {
    result = append(result, chunk...)
}

Так вы существенно снижаете нагрузку на сборщик мусора и время выполнения.

Ошибка 7. Обрезка среза после использования как буфера и удержание лишней памяти

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

Давайте разберемся на примере:

func readData() []byte {
    buf := make([]byte, 0, 1024*1024) // 1 МБ буфер

    // Здесь мы читаем какую-то информацию, но фактически используем, например, 4 КБ
    buf = append(buf, make([]byte, 4*1024)...)

    // Потом решаем вернуть только часть данных
    return buf[:4*1024]
}

Проблема:

Мы возвращаем срез длиной 4 КБ.
Но этот срез все еще держит в памяти массив емкостью 1 МБ.
Если таких срезов будет много, вы получите лишнее потребление памяти.

Чтобы "отпустить" лишнюю емкость, можно сделать явную копию под нужную длину:

func readData() []byte {
    buf := make([]byte, 0, 1024*1024)

    buf = append(buf, make([]byte, 4*1024)...)

    data := make([]byte, len(buf))
    copy(data, buf)
    // Теперь data - новый массив ровно нужного размера

    return data
}

Обратите внимание, как этот фрагмент кода решает задачу:

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

Ошибка 8. Использование append вместо copy при смещении данных

Иногда нужно "сдвинуть" часть среза влево или вправо, например, при удалении элемента из середины. Некоторые пытаются решить это через append, но делают это некорректно.

Частый пример удаления элемента по индексу:

func removeAtWrong(s []int, i int) []int {
    return append(s[:i], s[i+1:]...)
}

Этот код выглядит популярным, и он действительно работает в большинстве случаев, но у него есть два подводных камня:

Если срез "шарится" между несколькими переменными, вы измените данные везде.
Остаток старого массива может содержать "висящие" ссылки на объекты, что влияет на сборку мусора.

Давайте посмотрим пример с разделяемым срезом:

func main() {
    base := []int{1, 2, 3, 4}
    a := base[:]
    b := base[:]

    a = append(a[:1], a[2:]...) // удаляем элемент с индексом 1

    fmt.Println("base:", base)
    fmt.Println("a:", a)
    fmt.Println("b:", b) // тоже изменился
}

Если вы хотите удалить элемент, не затрагивая другие "виды" на те же данные, нужно либо:

Сделать копию до модификации.
Использовать copy, если вы хотите более явный контроль.

Например:

func removeAt(s []int, i int) []int {
    if i < 0 || i >= len(s) {
        return s // или паника, в зависимости от вашей логики
    }

    copy(s[i:], s[i+1:])
    // Мы сдвигаем все элементы после i на одну позицию влево

    s = s[:len(s)-1]
    // Просто укорачиваем срез на один элемент

    return s
}

Смотрите, я использую copy, чтобы явно сместить данные, и только потом уменьшаю длину среза. Это помогает лучше контролировать, что именно происходит в памяти.

Ошибка 9. Паника при append на nil-срезе указателей или структур с неверной инициализацией

Хотя append сам по себе безопасен для nil-срезов, паника может возникать, если элементы, которые вы добавляете, не инициализированы корректно.

Пример:

type Item struct {
    Value int
}

func main() {
    var items []*Item // nil-срез указателей

    // Ошибочно пытаемся присвоить поле до инициализации
    // items[0].Value = 10 // это сразу паника, но иногда ошибка замаскирована

    // Часто ошибка выглядит так - пытаемся переиспользовать неинициализированные элементы
    for i := 0; i < 3; i++ {
        var it *Item
        // забыли сделать it = &Item{}
        items = append(items, it)
    }

    // Позже где-то в коде:
    for _, it := range items {
        _ = it.Value // паника, так как it == nil
    }
}

Здесь проблема не в append, а в том, что в срез добавляются nil-указатели. Но разработчики часто ассоциируют эту панику именно с "магическим" поведением append.

Как этого избежать:

Всегда инициализируйте элементы перед добавлением в срез.
Не полагайтесь на неинициализированные локальные переменные.

Правильный вариант:

for i := 0; i < 3; i++ {
    it := &Item{Value: i}
    items = append(items, it)
}

Ошибка 10. Использование append в многопоточном коде без синхронизации

Срезы не потокобезопасны. Если два горутины одновременно вызывают append на одном и том же срезе, вы легко получите race condition и поврежденные данные.

Давайте посмотрим опасный пример:

var data []int

func worker(wg *sync.WaitGroup) {
    defer wg.Done()
    for i := 0; i < 1000; i++ {
        data = append(data, i) // гонка
    }
}

func main() {
    var wg sync.WaitGroup
    wg.Add(2)

    go worker(&wg)
    go worker(&wg)

    wg.Wait()
}

Здесь:

Две горутины одновременно расширяют один и тот же срез.
Внутри append есть операции по изменению длины и, возможно, перевыделению массива.
Без синхронизации вы получите некорректный результат и потенциальную панику.

Как решить:

Использовать мьютекс:

var (
    data []int
    mu   sync.Mutex
)

func worker(wg *sync.WaitGroup) {
    defer wg.Done()
    for i := 0; i < 1000; i++ {
        mu.Lock()
        data = append(data, i)
        mu.Unlock()
    }
}

Или лучше — собирать локальные результаты в каждом потоке, а потом объединить их:

func worker(local *[]int, wg *sync.WaitGroup) {
    defer wg.Done()
    for i := 0; i < 1000; i++ {
        *local = append(*local, i) // безопасно, срез локальный для горутины
    }
}

func main() {
    var wg sync.WaitGroup

    a := make([]int, 0, 1000)
    b := make([]int, 0, 1000)

    wg.Add(2)
    go worker(&a, &wg)
    go worker(&b, &wg)
    wg.Wait()

    // После завершения горутин объединяем
    data := make([]int, 0, len(a)+len(b))
    data = append(data, a...)
    data = append(data, b...)
}

Такой подход проще, безопаснее и чаще эффективнее.

Практические рекомендации по безопасному использованию append

Соберем в одном месте правила, которые помогут вам реже допускать ошибки:

1. Всегда присваивайте результат append

s = append(s, v)        // правильно
append(s, v)            // ошибка, если вы ждете изменения s

2. Будьте осторожны с под-срезами

Если вы делаете срез от другого:

Понимайте, что cap под-среза может быть больше его len.
Если не хотите, чтобы append менял исходный массив, либо ограничьте емкость среза через [low:high:max], либо сделайте копию.

sub := data[:n:n]               // ограничиваем емкость
safe := append([]T(nil), sub...) // создаем независимую копию

3. Не бойтесь nil-срезов

Нет нужды специально инициализировать их перед append:

var s []int
s = append(s, 1) // безопасно

4. Планируйте емкость при больших объемах

Если вы заранее знаете примерно, сколько элементов будет, используйте make с емкостью:

s := make([]int, 0, expectedCount)

Так вы уменьшите количество аллокаций и ускорите программу.

5. Внимательно относитесь к многопоточности

Никогда не вызывайте append из нескольких горутин над одним и тем же срезом без синхронизации или без разделения данных.

Заключение

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

Основные источники ошибок:

непонимание того, что срез — это "окно" к массиву, которое может расширяться
игнорирование того, что append может как переиспользовать существующий массив, так и выделять новый
забывание, что append всегда возвращает новый срез, который нужно присваивать
неправильные ожидания при передаче среза в функцию
невнимательность к емкости и влиянию под-срезов на исходные данные

Если вы будете помнить про len, cap и общий underlying array, то большинство "мистических" багов перестанут быть мистическими, а работа с append станет предсказуемой. Старайтесь явно управлять емкостью там, где важна производительность, и не злоупотребляйте разделяемыми под-срезами, если вам нужна четкая изоляция данных.

Частозадаваемые технические вопросы по теме статьи и ответы на них

Как понять, создал ли append новый массив или использовал старый

Померяйте адрес первого элемента до и после append:

fmt.Printf("%p\n", &s[0])
s = append(s, 1)
fmt.Printf("%p\n", &s[0])
// Если адрес изменился - был создан новый массив

Также можно следить за cap: если len превышает старую cap, точно была новая аллокация.

Когда нужно использовать указатель на срез вместо возврата среза из функции

Указатель на срез имеет смысл, если:

вы хотите, чтобы функция могла "обнулить" срез (присвоить nil)
вы передаете структуру с несколькими срезами и хотите изменять их все "по месту"
вы реализуете API, ожидающее именно *[]T

В остальных случаях проще и чище возвращать новый срез.

Почему иногда после append элементы "пропадают" или становятся нулями

Чаще всего причина в том, что вы переиспользуете один и тот же срез как буфер и потом обрезаете его, а затем снова записываете поверх него. Проверьте, не берете ли вы под-срез от уже модифицированного среза и не храните ли его где-то еще.

Как эффективно добавлять элементы в начало среза с append

append не оптимизирован для добавления в начало. Типичный прием:

s = append([]T{v}, s...)
// но это создает новый массив и копирует все элементы

// Более эффективный вариант - работать с кольцевым буфером или двусвязным списком,
// если нужно часто добавлять в начало.