Интерфейсы: неявное удовлетворение, ловушка typed-nil и цена косвенности

Неявное удовлетворение: контракт, который никто не подписывает

Тип в Go удовлетворяет интерфейс, просто имея методы — без ключевого слова implements, без декларации, без импорта. Если у вашей структуры есть Read(p []byte) (int, error), она — io.Reader, даже если io никогда не импортировался, а интерфейс написан годами позже. Это структурная типизация с проверкой на этапе компиляции, и она переворачивает стрелку зависимости: потребитель определяет интерфейс, который ему нужен, а любой производитель, который случайно подходит, — подходит. Вы можете объявить однометодный интерфейс в своём пакете — и типы стандартной библиотеки уже его удовлетворяют: абстракция задним числом натягивается на чужой код без единого изменения в нём. Поскольку никто не декларирует намерение, идиома «обещаю, что этот тип удовлетворяет тот интерфейс, завали сборку, если нет» — compile-time-утверждение:

type Store interface {
    Get(ctx context.Context, key string) ([]byte, error)
}

// Compile-time доказательство: *RedisStore удовлетворяет Store. Ничего не стоит в рантайме.
var _ Store = (*RedisStore)(nil)

Пара (тип, значение) — и ловушка typed-nil

Под капотом интерфейсное значение — два машинных слова (16 байт на 64-битной платформе): указатель на метаданные типа и методов — itab (interface table, таблица интерфейса), хранящий конкретный тип и разрешённые адреса методов, — и указатель на данные. Присваивание конкретного значения интерфейсу заполняет оба слова. Это представление объясняет всё странное в интерфейсах. Равенство сравнивает оба слова. Утверждение типа читает слово типа. И ловушка из вступления: интерфейс равен nil, только когда оба слова nil. Положите nil *HealthError в error — слово типа заполнится (*HealthError), слово данных останется nil, и сам интерфейс не nil:

type HealthError struct{ Reason string }

func (e *HealthError) Error() string { return e.Reason }

func check() *HealthError {
    return nil // здоровый путь: nil-указатель КОНКРЕТНОГО типа
}

func main() {
    var err error = check()         // (тип=*HealthError, данные=nil)
    fmt.Println(err == nil)         // false — слово типа заполнено!
    fmt.Printf("%#v\n", err)        // (*main.HealthError)(nil) — вот улика
}

Правило, которое это предотвращает: функции, которые могут отказать, возвращают интерфейсный тип error, и никогда — конкретный указательный тип ошибки. Внутри возвращайте литеральный nil, а не возможно-nil типизированную переменную. Когда дебажите «ненулевой nil», %#v (или %T) обнажает слово типа, которое прячет %v. Это не баг компилятора, который нужно обойти, — это прямое следствие двухсловного представления, и стоит увидеть пару, как поведение становится единственно возможным.

Маленькие интерфейсы и «принимай интерфейсы, возвращай структуры»

Как понять, когда вводить интерфейс и каким его делать? Стандартная библиотека отвечает на это последовательно: у самых используемых интерфейсов один метод: io.Reader, io.Writer, fmt.Stringer. Это намеренно — чем больше интерфейс, тем слабее абстракция. Однометодный интерфейс удовлетворяется сотнями типов и компонуется в большие (io.ReadWriteCloser — три встроенных однометодных интерфейса); двенадцатиметодный удовлетворяется ровно одной структурой плюс моком, который вы для неё написали, — а значит, это не абстракция, это заголовочный файл. Парное правило: принимай интерфейсы, возвращай структуры. Параметры с типами маленьких интерфейсов просят минимальную способность — берите io.Reader, а не *os.File, и функция заработает на файлах, сетевых соединениях, буферах и тестовых строках одинаково. Возвраты с конкретными типами сохраняют полный набор методов и оставляют вызывающим решать, что абстрагировать; возврат интерфейса прячет методы, которые могут понадобиться, и замораживает ваш API вокруг сегодняшней догадки. (Известное исключение: возвращайте интерфейс error — почему он обязателен, см. предыдущий раздел.)

// Запрашивает минимум, работает с любым читаемым источником.
func CountLines(r io.Reader) (int, error) { ... }

// Возвращает конкретный тип: вызывающие получают полный API *Parser
// и могут сами присвоить его любому интерфейсу, который определят.
func NewParser(opts ...Option) *Parser { ... }

Переключатели типов — инструмент инспекции, когда одно значение может быть несколькими вещами: switch v := x.(type) ветвится по динамическому типу и связывает v с правильным статическим типом в каждой ветке. Идиоматично для декодирования протоколов и проверки способностей (реализует ли этот io.Writer ещё и Flusher?); запах — когда растущий switch по вашим собственным типам подменяет то, что должно было быть методом интерфейса.

Что стоит косвенность — и когда это важно

Вызов через интерфейс — динамическая диспетчеризация: загрузить адрес метода из itab, прыгнуть. Сам вызов — пара наносекунд, близко к прямому, и редко является проблемой. Настоящие издержки — второго порядка. Блокируется инлайнинг: компилятор не может встроить вызываемого, которого не может идентифицировать, поэтому однострочный геттер за интерфейсом остаётся настоящим вызовом, и всё, что инлайнинг разблокировал бы (свёртка констант, удаление мёртвого кода, значения в регистрах), отключено. Побег в кучу: помещение значения в интерфейс, как правило, вынуждает аллоцировать его в куче, потому что слово данных интерфейса хранит указатель — передайте int как interface{} в горячем цикле, и вы можете аллоцировать на каждой итерации: это давление на GC, а не просто наносекунды. Честные числа: прямой вызов ~1–2 нс, интерфейсный ~2–4 нс, но потерянный инлайн плюс вынужденная аллокация превращают бесплатную операцию в ~25–50 нс с амортизацией GC — разница в 10–30× в самых горячих циклах и ничто вне их. Компилятор девиртуализует, когда может доказать конкретный тип (а profile-guided optimization, Go 1.21+, девиртуализует горячие вызовы по продакшен-профилям), но рассчитывать на это через границы пакетов не стоит. Инженерная позиция: проектируйте интерфейсы на архитектурных швах — хранилище, транспорт, часы, — где частота вызовов per-request, а поэлементные горячие пути (кодеки, парсеры, тугие циклы по миллионам элементов) держите конкретными или дженериковыми; и измеряйте профилировщиком, прежде чем сплющивать любую абстракцию во имя скорости.