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

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

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

В Go указатель nil представляет отсутствие значения, но сам по себе не запрещает вызов метода. Такая модель позволяет типу явно определить поведение для отсутствующего получателя, например трактовать nil как пустое состояние или специальный случай.

Подход сохраняет единый синтаксис вызова методов и не требует отдельной конструкции для каждого возможного отсутствующего объекта. Ответственность за безопасную работу с nil остаётся у реализации метода.

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

Если метод вызывается через nil-указатель, разработчик может ошибочно предположить, что паника произойдёт всегда. Обратная ошибка также опасна: безопасный вызов одного метода не означает, что безопасны все методы того же типа.

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

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

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

Метод со значимым получателем устроен иначе: для вызова через указатель нужно получить значение структуры. Если указатель равен nil, это разыменование невозможно, поэтому возникает паника до нормального выполнения метода.

package main

import "fmt"

type Counter struct{ value int }

func (c *Counter) Name() string {
	if c == nil {
		return "пустой"
	}
	return "счётчик"
}

func (c *Counter) Value() int { return c.value }

func main() {
	var c *Counter
	fmt.Println(c.Name()) // пустой
	fmt.Println(c.Value()) // паника
}

Вызов Name безопасен, потому что метод проверяет получатель до обращения к полям. Value сразу читает поле value, поэтому обращение через nil приводит к панике.

Практическое правило: указательный метод может поддерживать nil-получатель только по явному контракту. Если nil недопустим, это лучше зафиксировать документацией и не маскировать ошибку без необходимости.

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

В библиотеке логирования объект конфигурации иногда отсутствует. Рассматривались два варианта: проверять указатель перед каждым вызовом или разрешить nil-получателю метода форматирования возвращать безопасное значение по умолчанию.

Проверка в каждом месте вызова проще для контроля, но увеличивает дублирование и риск пропустить проверку. Поддержка nil внутри метода уменьшает шум и централизует правило, однако требует документировать поведение и покрыть его тестами.

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

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

Можно ли вызвать метод с указательным получателем, если указатель равен nil?

Да, сам факт nil не запрещает вызов. Метод начнёт выполняться, если вызов технически сформирован для указательного получателя; паника появится только при операции, требующей разыменования, если метод не обрабатывает nil явно.

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

Значимый получатель должен быть конкретным значением структуры. При вызове через указатель компилятор должен получить это значение, то есть разыменовать указатель. Для nil такое разыменование невозможно, поэтому выполнение тела метода не является способом безопасно обработать отсутствие значения.

Достаточно ли проверки nil в одном методе, чтобы считать тип безопасным для nil-получателя?

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