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

nil-указатель — это корректное нулевое значение указательного типа, не содержащее адреса объекта. Его можно сравнивать с nil, передавать и присваивать. Паника возникает при разыменовании такого указателя, потому что программе требуется получить данные по отсутствующему адресу.

package main

import "fmt"

type Item struct {
    Value int
}

func main() {
    var p *Item
    fmt.Println(p == nil) // true
    // fmt.Println(p.Value) // panic: nil pointer dereference

    p = &Item{Value: 10}
    fmt.Println(p.Value) // 10
}

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

Указатели в Go нужны для явного обращения к объекту, передачи изменяемого состояния и представления отсутствующего значения. Для каждого указательного типа nil является нулевым значением, поэтому указатель можно объявить без немедленного выделения объекта.

Язык не скрывает операцию разыменования: обращение к полю через указатель или чтение по нему требует существующего объекта. Это позволяет отличать безопасную проверку наличия значения от попытки использовать отсутствующий объект.

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

Нулевой указатель часто появляется как результат необязательного значения, поиска объекта или ошибки инициализации. Если передать его дальше без проверки и обратиться к полю либо вызвать операцию, требующую объекта, выполнение завершится паникой.

Сама проверка p == nil безопасна, потому что она сравнивает значение указателя как таковое и не обращается к памяти объекта. Важно не путать это с проверкой интерфейса: интерфейс может содержать ненулевой интерфейсный дескриптор, внутри которого находится nil-указатель.

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

Указатель хранит либо адрес значения, либо специальное нулевое состояние nil. Сравнение с nil проверяет именно это состояние и не требует разыменования.

При обращении к p.Value Go сначала должен получить объект, на который указывает p, а затем поле Value. Если p равен nil, объекта нет, поэтому рантайм вызывает панику из-за обращения через нулевой указатель.

Разыменование не следует путать с передачей самого указателя. Нулевой указатель можно вернуть из функции, сохранить в структуре или использовать как признак отсутствия результата, если контракт API это допускает.

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

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

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

Сервис ищет пользователя и возвращает указатель на структуру. Если пользователь не найден, функция возвращает nil. Обработчик без проверки сразу обращается к полю профиля, из-за чего редкий сценарий отсутствия данных превращается в панику.

Можно вернуть структуру-значение с нулевыми полями. Это устраняет nil-проверки, но смешивает отсутствие пользователя с реально существующим пользователем, у которого поля имеют нулевые значения.

Можно вернуть указатель и ошибку. Такой вариант явно разделяет успешный результат и отсутствие данных; его минус — вызывающий код обязан обработать оба результата. Для сервисного API выбран именно этот подход: перед использованием результата проверяется ошибка, а затем указатель считается ненулевым согласно контракту функции. В результате отсутствие записи становится штатным ответом, а не аварийным завершением.

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

1. Может ли nil-указатель быть полем структуры и оставаться корректным?

Да. Хранение nil-указателя само по себе безопасно: это обычное нулевое значение поля. Паника появляется только при операции, которая требует объекта по этому указателю, например при чтении поля или явном разыменовании.

2. Почему интерфейс с nil-указателем может быть не равен nil?

Интерфейсное значение концептуально содержит динамический тип и динамическое значение. Если в него помещён указатель определённого типа со значением nil, динамический тип уже присутствует, поэтому сам интерфейс обычно не равен nil. Для корректной проверки нужно учитывать семантику конкретного API, а не полагаться только на сравнение интерфейса с nil.

3. Всегда ли проверка указателя на nil устраняет риск паники?

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