#fundamentals

Интерфейсы в Go: неявность, itab и ловушка nil

Интерфейсы в Go удовлетворяются неявно, состоят из пары (тип, значение) и потому таят знаменитую ловушку: интерфейс с типизированным nil внутри сам НЕ равен nil. Разбираем маленькие интерфейсы, «accept interfaces, return structs», внутреннее устройство (itab), type assertions/switch и почему nil-интерфейс — не то, чем кажется

Интерфейсы — центральный механизм абстракции в Go, и почти всё в нём сделано не так, как в языках с явным implements. Тип удовлетворяет интерфейсу молча, без единой строчки объявления связи; сам интерфейс внутри — это пара «тип плюс значение», и из этой пары растёт знаменитая ловушка nil, на которой спотыкались все. А заодно — устойчивый миф, что «вызов через интерфейс дорогой»: на деле компилятор часто девиртуализирует его до прямого вызова, и цена появляется только на настоящих полиморфных call-site.

Это первая статья мини-серии «Основы Go вглубь» — трёх разборов узлов базового языка, где ошибаются чаще всего: интерфейсы, обработка ошибок (там nil-ловушка проявляется в самом болезненном виде) и срезы с мапами. Это не полный курс основ, а ключевые ловушки. Тесно связаны дженерики — constraints это тоже интерфейсы. Числа ниже сняты на конкретном стенде (go1.26.3, windows/amd64); воспроизводимость — часть материала, снимайте у себя.

Схема «Go interface value: пара из двух слов»: слот TYPE (_type: size/ptrdata/hash/…) и слот VALUE (указатель на данные) ведут к таблице методов itab; справа — ловушка nil-интерфейса: при типизированном nil внутри «interface ≠ nil» (type ≠ nil ⇒ interface ≠ nil); внизу — столбики стоимости диспетчеризации: direct ≈0.48, devirtualized ≈0.49, via itab ≈1.9 ns

В статье

Неявное удовлетворение

В Java или C# связь типа с интерфейсом объявляется явно: class File implements Reader. В Go такого оператора нет. Тип удовлетворяет интерфейсу автоматически, как только у него есть все нужные методы с нужными сигнатурами:

type Stringer interface {
	String() string
}

// Point нигде не заявляет, что реализует Stringer.
// Он им становится просто потому, что у него есть метод String().
type Point struct{ X, Y int }

func (p Point) String() string {
	return fmt.Sprintf("(%d, %d)", p.X, p.Y)
}

func describe(s Stringer) string { return s.String() }

// describe(Point{1, 2}) компилируется — Point удовлетворяет Stringer.

Это структурная типизация, проверяемая на этапе компиляции. «Утиная типизация» — но статическая: если у Point не окажется String() string, программа не соберётся, а не упадёт в рантайме, как в динамических языках.

Из неявности следует главное архитектурное правило Go, часто формулируемое как интерфейс объявляет потребитель, а не поставщик. Пакет, который использует абстракцию, определяет минимальный интерфейс под свою нужду; пакет, который реализует конкретный тип, вообще не обязан знать об этом интерфейсе. Отсюда — отсутствие циклических зависимостей между «интерфейсным» и «реализующим» пакетами и возможность задним числом ввести абстракцию над чужим типом, не трогая его код.

Это переворачивает привычку из языков с явным implements, где интерфейс живёт рядом с реализацией и «принадлежит» ей. В Go нормально, когда один и тот же конкретный тип удовлетворяет десятку интерфейсов, о большинстве которых его автор никогда не слышал: каждый потребитель вырезал ровно тот срез поведения, который ему нужен. Мысль «сначала опишу интерфейс, потом под него напишу тип» здесь обычно вредна — интерфейс появляется в точке использования и настолько узкий, насколько позволяет вызывающий код.

Проверить удовлетворение явно, на этапе компиляции, можно идиомой «assertion в никуда» — она ничего не стоит в рантайме и служит документацией/страховкой:

// Если *File перестанет удовлетворять io.Reader — не соберётся.
var _ io.Reader = (*File)(nil)

Маленькие интерфейсы: accept interfaces, return structs

Каноничные интерфейсы стандартной библиотеки — крошечные. io.Reader и io.Writer — по одному методу:

type Reader interface {
	Read(p []byte) (n int, err error)
}

type Writer interface {
	Write(p []byte) (n int, err error)
}

Чем меньше интерфейс, тем больше типов ему удовлетворяют и тем шире он переиспользуется. io.Reader реализуют файлы, сетевые соединения, буферы, gzip-декодеры, HTTP-тела — и любую функцию поверх io.Reader можно скормить каждому из них. Большой «толстый» интерфейс, наоборот, требует от реализации десяток методов, сужает круг подходящих типов и намертво связывает потребителя с конкретной формой.

Отсюда идиома accept interfaces, return structs: функция принимает узкий интерфейс (берёт ровно то, что использует), но возвращает конкретный тип (даёт вызывающему всё, а не урезанный контракт).

// Принимает io.Reader — подойдёт файл, сеть, bytes.Buffer, что угодно.
// Возвращает *Parser — вызывающий получает полный тип, не обрубок.
func NewParser(src io.Reader) *Parser {
	return &Parser{r: bufio.NewReader(src)}
}

Возврат интерфейса вместо конкретного типа почти всегда преждевременен: он прячет от вызывающего реальные возможности, мешает добавлять методы без слома контракта и часто приводит к nil-ловушке из следующего раздела. Интерфейс уместно возвращать, когда набор реализаций действительно открыт (например, error), — но и тогда стоит взвесить.

Обратная сторона — interface pollution, ранняя интерфейсизация. Заводить интерфейс «на будущее», когда реализация ровно одна и мокать её незачем, — это лишний слой косвенности без выгоды: он не абстрагирует ничего, зато размывает навигацию по коду и мешает инлайну. Практика Go — вводить интерфейс, когда появился второй потребитель или вторая реализация, а не авансом. Интерфейс с одним-единственным методом-геттером под каждый метод структуры — типичный симптом переусердствования.

Если потребителю всё-таки нужно несколько поведений сразу, их комбинируют из мелких интерфейсов, а не пишут один большой (см. встраивание).

Устройство под капотом: (тип, значение) и itab

Значение интерфейса — это всегда пара из двух машинных слов: дескриптор динамического типа и указатель на данные. Но устроены две разновидности по-разному.

Пустой интерфейс any (он же interface{}) не содержит методов. Его runtime-представление — структура eface: указатель на дескриптор типа (*_type) и указатель на данные.

// runtime, упрощённо
type eface struct {
	_type *_type         // какой конкретный тип лежит внутри
	data  unsafe.Pointer // указатель на само значение
}

Непустой интерфейс (с методами) представлен структурой iface, где первое слово — не голый тип, а указатель на itab (interface table):

// runtime, упрощённо
type iface struct {
	tab  *itab          // itab: (тип интерфейса, конкретный тип) + методы
	data unsafe.Pointer // указатель на значение
}

type itab struct {
	// ... тип интерфейса, конкретный тип, хеш ...
	fun [1]uintptr // массив указателей на методы конкретного типа
}

itab — это связка «конкретный тип ↔ интерфейс»: она хранит дескрипторы обоих типов и, главное, fun — таблицу указателей на реализации методов интерфейса для данного конкретного типа. Именно через fun[i] идёт динамический вызов. itab-ы уникальны для каждой пары (интерфейс, конкретный тип), вычисляются рантаймом лениво при первом присваивании и кешируются — так что построение таблицы не повторяется на каждый вызов.

graph LR subgraph eface["eface — any"] E1["_type → *_type"] E2["data → значение"] end subgraph iface["iface — интерфейс с методами"] I1["tab → *itab"] I2["data → значение"] end I1 --> TAB["itab:
тип интерфейса
конкретный тип
fun[] → методы"] 

graph LR
    subgraph eface["eface — any"]
        E1["_type → *_type"]
        E2["data → значение"]
    end
    subgraph iface["iface — интерфейс с методами"]
        I1["tab → *itab"]
        I2["data → значение"]
    end
    I1 --> TAB["itab:
тип интерфейса
конкретный тип
fun[] → методы"]
Два слова интерфейса: eface (any) держит тип напрямую, iface (с методами) — через itab с таблицей методов fun

Два практических следствия из этой раскладки:

  • Поле data — это указатель. Если в интерфейс кладут значение-тип (не указатель), значение может уехать в кучу (escape), и в data попадёт указатель на него — это боксинг, потенциальный источник аллокаций при работе с any. Уедет ли значение в кучу в конкретном случае, решает escape-анализ; проверяйте go build -gcflags=-m и бенч с -benchmem. Кладя в интерфейс указатель (*T), само преобразование в интерфейс никуда не девается (пара «тип + data» всё равно формируется), но отдельной аллокации на боксинг обычно нет: в data кладётся сам указатель, копировать значение в кучу не нужно.
  • Интерфейс «пуст» (равен nil) тогда и только тогда, когда оба слова нулевые. Отсюда — ловушка следующего раздела.

Ловушка nil-интерфейса

Самое важное в этой статье. Раз интерфейс — пара (тип, значение), то interface == nil истинно только когда обе части нулевые: и дескриптор типа, и указатель на данные. Стоит записать в интерфейс типизированный указатель — пусть даже нулевой, — как часть «тип» становится ненулевой, и весь интерфейс перестаёт быть nil.

Стенд (сверено на go1.26.3) показывает это в лоб:

type T struct{}

func main() {
	var p *T = nil
	fmt.Println(p == nil) // true  — сам указатель нулевой

	var i interface{} = p
	fmt.Println(i == nil) // false — внутри лежит (*T, nil): тип НЕ пуст

	var e any // ничего не присвоено
	fmt.Println(e == nil) // true  — обе части нулевые
}

Правило, которое стоит запомнить дословно: если тип внутри интерфейса не nil, то и интерфейс не nil — независимо от того, что указатель на данные нулевой. nil-интерфейс — это отсутствие типа, а не «тип есть, но значение нулевое».

Самое коварное проявление — с error. Классический баг: функция возвращает конкретный *MyError, а сигнатура — error:

type MyError struct{ Code int }

func (e *MyError) Error() string { return fmt.Sprintf("code %d", e.Code) }

// ПЛОХО: возвращаем конкретный тип-указатель.
func do() *MyError {
	// ... всё хорошо, ошибки нет ...
	return nil // это (*MyError)(nil)
}

func caller() {
	var err error = do() // в интерфейс кладётся (*MyError, nil)
	if err != nil {
		// СРАБАТЫВАЕТ, хотя ошибки на самом деле нет!
		// Печатать сам err тут вдвойне опасно: Error() вызовется на nil-приёмнике
		// (внутри — e.Code) и упадёт nil-разыменованием; fmt это перехватит и
		// вместо текста напечатает %!v(PANIC=...). Поэтому просто фиксируем факт:
		fmt.Println("вошли в ветку обработки ошибки, хотя do() вернул nil")
	}
}

do() вернул нулевой *MyError, но при присваивании в error интерфейс получил ненулевую часть-тип (*MyError), поэтому err != nil истинно — и ветка обработки ошибки выполняется на пустом месте. Детально этот сценарий (и почему функции, возвращающие ошибку, должны возвращать именно error, а не конкретный тип) разобран в статье про обработку ошибок; межъязыковой контекст — в error handling across languages.

Как не попадаться:

  • Возвращайте error, а не конкретный *MyError. Тогда возврат «ошибки нет» — это return nil, где nil присваивается интерфейсу и обе части нулевые.
  • Возвращайте nil литералом, а не типизированной переменной. Опасно return err, где err объявлена как *MyError и осталась нулевой; безопасно return nil.
  • Если помогающая функция всё же отдаёт конкретный тип-указатель, приводите к error осознанно и проверяйте сам указатель на nil до возврата.

Второй сюрприз того же корня — сравнение интерфейсов через ==. Интерфейсные значения сравнимы: равны, если совпадают и динамический тип, и динамическое значение. Но если внутри лежит несравнимый тип (слайс, карта, функция), сравнение не даёт false, а паникует в рантайме:

var a any = []int{1}
var b any = []int{1}
_ = a == b // panic: runtime error: comparing uncomparable type []int

Это же роняет использование интерфейса как ключа карты (map[any]V) при вставке значения несравнимого типа — та же паника на этапе хеширования. Компилятор пропускает это, потому что типы статически — any, а несравнимость проявляется только по фактическому содержимому в рантайме. Практика: не сравнивайте интерфейсы и не кладите их в ключи карты, если внутрь может попасть слайс/карта/функция; когда нужно сравнить такие значения, используйте reflect.DeepEqual.

Стоимость диспетчеризации

Вокруг интерфейсов живёт миф «вызов через интерфейс дорогой, избегайте в горячем пути». Реальность тоньше. Бенч стенда (go1.26.3, windows/amd64; порядок величин, снимайте у себя):

Вызов Время Что происходит
Прямой вызов метода конкретного типа ~0.48 ns/op Обычный статический вызов, кандидат на инлайн
Интерфейс с одним статически известным типом ~0.49 ns/op Компилятор часто девиртуализирует до прямого
Полиморфный call-site (несколько типов) ~1.9 ns/op Настоящий itab-вызов, инлайна нет

Форма бенча, снимающего эти числа, — три параллельных цикла, разница лишь в том, через что идёт вызов:

type Shape interface{ Area() float64 }

type Circle struct{ R float64 }

func (c *Circle) Area() float64 { return 3.14159 * c.R * c.R }

// Прямой вызов: тип статически известен, кандидат на инлайн.
func BenchmarkDirect(b *testing.B) {
	c := &Circle{R: 2}
	for i := 0; i < b.N; i++ {
		sink = c.Area()
	}
}

// Мономорфный интерфейс: за s всегда один тип — компилятор часто девиртуализирует.
func BenchmarkMono(b *testing.B) {
	var s Shape = &Circle{R: 2}
	for i := 0; i < b.N; i++ {
		sink = s.Area()
	}
}

Полиморфный вариант отличается тем, что в s по очереди попадают разные конкретные типы (*Circle, *Square, …) — компилятору нечего девиртуализировать, и остаётся честный вызов через itab.fun.

Три вывода:

  • Если в конкретной точке компилятор видит, что за интерфейсом стоит один конкретный тип, он часто проводит девиртуализацию — заменяет косвенный вызов через itab.fun прямым вызовом реализации (и тогда возможен инлайн). Это оптимизация компилятора, а не гарантия языка: на другой версии Go или в другой точке она может и не сработать. Поэтому «интерфейс с одним типом» практически неотличим от прямого вызова: ~0.49 против ~0.48 ns/op.
  • Настоящая цена появляется на полиморфном call-site, где в одну переменную интерфейса реально попадают разные типы: девиртуализировать нечего, идёт косвенный вызов через таблицу методов, инлайн невозможен — отсюда ~1.9 ns/op, порядка ×4 к прямому вызову.
  • Аллокаций — 0 во всех трёх случаях, потому что в интерфейс кладутся указатели. Боксинг (и, значит, аллокации) возник бы, если бы в интерфейс клали крупные value-типы — см. устройство itab.

Практический смысл: интерфейс не «автоматически дорогой». В мономорфных местах он часто почти бесплатен — если компилятор девиртуализировал вызов (это стоит подтверждать бенчем, а не принимать на веру), — а несколько наносекунд полиморфного вызова значимы лишь в очень горячих циклах — там, где это действительно упирается в стену, применяют мономорфизацию через дженерики или разворачивают тип явно. Оптимизировать интерфейсы «на всякий случай» — преждевременно; профилируйте.

Type assertion и type switch

Достать конкретный тип обратно из интерфейса позволяет type assertion. У неё две формы, и в проде почти всегда нужна вторая:

var r io.Reader = os.Stdin

// Опасная форма: паника, если r не *os.File.
f := r.(*os.File)

// Безопасная (comma-ok): ok == false вместо паники.
f, ok := r.(*os.File)
if ok {
	_ = f.Name()
}

Форма v, ok := x.(T) никогда не паникует: при несовпадении ok == false, а v получает нулевое значение типа T. Когда проверяют несколько вариантов — используют type switch:

func format(v any) string {
	switch x := v.(type) {
	case nil:
		return "nil"
	case int:
		return strconv.Itoa(x)
	case string:
		return x
	case fmt.Stringer: // можно ветвиться и по интерфейсу
		return x.String()
	default:
		return fmt.Sprintf("%v", x)
	}
}

Внутри каждой ветки x уже имеет соответствующий статический тип. Ветка case nil ловит именно nil-интерфейс (обе части нулевые) — удобная деталь.

Когда это код-смелл. Type assertion/switch — легитимный инструмент для нескольких сценариев: обработка any на границе (десериализация, fmt), проверка опциональных возможностей типа (if c, ok := x.(io.Closer); ok { c.Close() }), разбор дерева ошибок. Но если type switch ветвится по своим же доменным типам, реализующим общий интерфейс, — это, как правило, обход полиморфизма: логику стоило положить методом в сам интерфейс. Длинный switch по конкретным типам, который приходится править при каждом новом типе, — сигнал, что абстракция сломана.

Встраивание интерфейсов

Интерфейсы композируются встраиванием: больший интерфейс собирается из меньших, перечисляя их в теле. Так io.ReadWriter — просто объединение Reader и Writer:

type ReadWriter interface {
	Reader // встроенный интерфейс
	Writer
}
// Эквивалентно интерфейсу с методами Read и Write.
// Любой тип с обоими методами удовлетворяет ReadWriter автоматически.

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

// Оборачиваем любой Reader, переопределяя только Read; остальное
// (если бы интерфейс был шире) делегировалось бы встроенному значению.
type countingReader struct {
	io.Reader     // встроенный интерфейс — источник методов
	n         int // сколько байт прочитано
}

func (c *countingReader) Read(p []byte) (int, error) {
	k, err := c.Reader.Read(p) // вызов реализации оборачиваемого
	c.n += k
	return k, err
}

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

Демо и версии

  • Код: живой стенд digital-cookbook/go-fundamentals/interfaces/. Нил-ловушка воспроизводится в cmd/nil-interface (тот самый контраст p == nil → true, i == nil → false, var e any == nil → true); бенч диспетчеризации меряет прямой/мономорфный/полиморфный вызовы. Код в тексте — выжимки.
  • Числа (~0.48 / ~0.49 / ~1.9 ns/op, 0 аллокаций) сняты на go1.26.3, windows/amd64 и приведены как порядок величин — девиртуализация и инлайнинг зависят от версии компилятора и площадки, поэтому снимайте бенч у себя (go test -bench . -benchmem).
  • Версии: сами языковые конструкции в примерах простые и работают начиная с Go 1.18 (тогда появился алиас any для interface{}; constraints в дженериках — это те же интерфейсы, но в роли type sets, смежная тема разобрана в дженериках). При этом модуль стенда объявляет go 1.25 — воспроизвести его дословно старым тулчейном не выйдет: это версия сборки, а не требование к идеям кода. Хотите собрать под старый Go — перенесите нужный файл в отдельный модуль с подходящей директивой go.
  • Сиблинги мини-серии «Основы Go вглубь»: срезы и мапы изнутри. Смежное: обработка ошибок (nil-ловушка в бою), паттерны конкурентности (интерфейсы в дизайне API).

Документация и первоисточники

Читайте также

Слайсы и карты в Go: внутренности и подводные камни

Слайсы и карты в Go: внутренности и подводные камни

Слайс — это заголовок (указатель, длина, ёмкость) над общим backing-массивом, и отсюда растут коварные баги: append молча перезаписывает «соседа», nil и пустой слайс не одно и то же. Карты рандомизируют порядок обхода и роняют процесс при конкурентной записи. Разбираем внутренности и подводные камни на живых примерах
#fundamentals
Обработка ошибок в Go: значения, обёртки, паники

Обработка ошибок в Go: значения, обёртки, паники

Ошибки в Go — обычные значения, а не исключения: их возвращают, оборачивают через %w, проверяют errors.Is/As сквозь цепочку и объединяют errors.Join. Разбираем sentinel и типизированные ошибки, когда уместны panic/recover, и знаменитый баг «типизированный nil в error != nil»
#fundamentals
Redis вглубь: структуры данных и их внутренние кодировки

Redis вглубь: структуры данных и их внутренние кодировки

Redis — не «строковый кэш», а сервер структур данных. Разбираем strings/hashes/lists/sets/zsets/streams и то, что скрыто под ними: внутренние кодировки (listpack, intset, skiplist, quicklist) и правила переключения между компактным и «большим» представлением. Честно: когда какая структура уместна и во что она обходится по памяти и по времени.
#redis #unicode #fundamentals

Обсуждение в Telegram

Присоединиться →

Комментарии