Краткий ответ

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

Исторический контекст

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

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

Постановка проблемы

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

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

Подробное решение

Нулевой срез имеет значение nil. Пустой ненулевой срез можно получить, например, через создание среза нулевой длины или литерал пустого среза. В обоих случаях len и cap равны нулю, а range не выполнит ни одной итерации.

package main

import "fmt"

func main() {
	var a []int
	b := make([]int, 0)

	fmt.Println(a == nil, b == nil)
	fmt.Println(len(a), len(b), cap(a), cap(b))
	a = append(a, 1)
	b = append(b, 1)
	fmt.Println(a, b)
}

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

Различие видно через s == nil. Для сравнения содержимого обычно используют len, поэлементное сравнение или специализированные средства, например slices.Equal; оно не предназначено для различения nil и пустого среза, поскольку оба не содержат элементов.

В JSON стандартная сериализация обычно представляет nil-срез как null, а пустой ненулевой срез — как []. Поэтому выбор состояния может быть частью контракта API. Если контракт не различает эти состояния, перед возвратом результата иногда намеренно нормализуют nil к пустому срезу, но делать это без требования не нужно.

Ситуация из практики

Сервис возвращает список предупреждений в HTTP-ответе. При отсутствии предупреждений внутренний код оставляет срез nil, и клиент получает null, хотя контракт требует всегда массив.

Вариант с безусловной инициализацией пустого среза во всех функциях делает формат предсказуемым, но добавляет шум и может смешать внутреннюю семантику «данных нет» с внешним требованием API. Вариант с передачей nil наружу проще, но нарушает контракт и вынуждает клиентов обрабатывать два формата.

Рациональное решение — хранить nil-срез внутри, если он естественно возникает как нулевое значение, а на границе сериализации явно преобразовывать его в пустой срез, когда API требует []. Так сохраняется простота внутренней логики и единый внешний формат.

Что кандидаты часто упускают

**Можно ли добавлять элементы в nil-срез?

Да. Nil-срез является допустимым аргументом append; результатом станет срез с добавленными элементами. Нельзя полагаться на сохранение исходной переменной без присваивания результата, потому что append может вернуть новый дескриптор и выделить новый массив.

**Всегда ли пустой срез отличается от nil-среза по выделенной памяти?

Нет. Пустой ненулевой срез имеет ненулевое значение самого среза, но это не означает, что под его элементы уже выделена отдельная память. При нулевой ёмкости хранилище элементов может отсутствовать. Семантическое различие определяется значением среза и проверкой на nil, а не гарантированным наличием массива.

**Почему проверка nil-среза важна при возврате результата функции?

Она позволяет различать отсутствие результата и корректный пустой результат. Это влияет на сериализацию, паттерны вроде «значение плюс признак наличия» и некоторые тесты. Если такое различие не является частью контракта, тесты и API лучше строить на содержимом и длине, иначе реализация может получить лишнюю, несущественную зависимость от способа создания среза.