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

Успех утверждения типа к другому интерфейсу определяется динамическим типом значения, хранящегося внутри исходного интерфейса. Утверждение успешно, если методовый набор этого динамического типа удовлетворяет целевому интерфейсу; статический тип переменной сам по себе результат не определяет.

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

Интерфейсы в Go позволяют отделить код, использующий поведение, от конкретной реализации. Однако иногда вызывающей стороне требуется проверить наличие дополнительной способности объекта или передать его в API, ожидающий более узкий интерфейс.

Для этого существуют type assertions и проверки дополнительных интерфейсов. Они сохраняют слабую связанность основного кода, но позволяют безопасно использовать специальные возможности конкретной реализации.

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

Переменная интерфейсного типа содержит не только значение, но и сведения о его динамическом типе. Ошибка возникает, когда разработчик смотрит только на объявленный тип переменной и предполагает, что именно он определяет результат утверждения.

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

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

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

Безопасная форма возвращает значение и признак успеха. Если проверка не прошла, признак равен false, а программа не завершается паникой.

package main

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

type Flusher interface {
	Flush() error
}

func flushIfSupported(r Reader) {
	f, ok := r.(Flusher)
	if ok {
		_ = f.Flush()
	}
}

Здесь статический тип параметра — Reader, но проверяется фактический тип объекта, переданного в r. Если этот тип реализует Flusher, утверждение успешно; наличие у переменной статического типа Reader метода Flush не требуется.

Прямое утверждение без проверки результата уместно только при гарантии контракта: при несовпадении динамического типа оно вызывает панику. Форма с признаком успеха безопаснее, но требует явно определить поведение для объекта без нужной способности.

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

Generics не заменяют type assertions полностью. Параметр типа полезен, когда типовая связь известна на этапе компиляции, а assertion нужен, когда решение зависит от фактического типа значения во время выполнения.

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

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

Можно было добавить Flush в базовый интерфейс, но тогда пришлось бы искусственно реализовывать этот метод или отбрасывать подходящие типы. Можно было использовать отражение, однако оно сложнее, менее типобезопасно и хуже выражает намерение.

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

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

Меняет ли утверждение типа исходное значение?

Нет. Type assertion не преобразует объект и не добавляет ему методы. Она извлекает значение из интерфейса после проверки того, что его динамический тип соответствует целевому типу или интерфейсу.
Можно ли утверждать интерфейс к более узкому интерфейсу, если статический тип исходной переменной его не реализует?

Да, если исходное значение само является интерфейсом и его динамический тип реализует целевой интерфейс. Статический тип описывает гарантии, доступные без проверки, а assertion проверяет более конкретное свойство фактического значения во время выполнения.
Чем утверждение к интерфейсу отличается от утверждения к конкретному типу?

При утверждении к интерфейсу проверяется совместимость динамического типа с методом целевого интерфейса. При утверждении к конкретному типу проверяется соответствие именно этому типу; другой тип с теми же методами результат не даст.

Поэтому утверждение к интерфейсу подходит для проверки способности объекта, а утверждение к конкретному типу — когда требуется доступ к его конкретному представлению или дополнительным методам, которых нет в интерфейсе.