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

Переменная, объявленная в заголовке type switch, получает статический тип, соответствующий конкретному типу в выбранной ветке. Поэтому в ветке с int она имеет тип int, а в ветке с интерфейсом — тип этого интерфейса. Если одна ветка перечисляет несколько типов, переменная сохраняет тип исходного интерфейсного выражения, поскольку единого конкретного типа для неё нет.

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

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

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

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

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

Неверное понимание типа переменной в ветке может привести к ошибкам компиляции, ненужным type assertions или ошибочному ожиданию, что ветка с интерфейсом автоматически превращает значение в конкретный тип.

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

В ветке с одним конкретным типом переменная получает этот тип. Например, после ветки case int она имеет статический тип int, поэтому доступны операции и методы именно int, а не исходного интерфейса.

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

Если в одном case перечислено несколько типов, статический тип переменной остаётся типом выражения, проверяемого в type switch, обычно исходным интерфейсом. Компилятор не может выбрать один конкретный статический тип, потому что во время выполнения возможен любой из перечисленных вариантов.

package main

import "fmt"

type Named interface{ Name() string }
type User struct{}
func (User) Name() string { return "user" }

func show(v any) {
	switch x := v.(type) {
	case int:
		fmt.Println(x + 1)
	case Named:
		fmt.Println(x.Name())
	case int, string:
		fmt.Printf("%T
", x)
	}
}

В первой ветке x имеет тип int, во второй — Named. В третьей ветке x имеет тип исходного выражения any, поэтому компилятор не разрешает использовать его как безусловно int или string.

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

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

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

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

Выбран вариант с отдельными ветками для int и интерфейса обработчика. Он даёт точный статический тип в каждой ветке, позволяет компилятору проверять операции и явно отражает различия поведения. Для неизвестных типов добавляется default, чтобы входные данные не обрабатывались молча.

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

1. Дополнительный вопрос: меняется ли статический тип переменной в ветке default?

Нет. В default переменная получает тип исходного выражения из type switch. Если switch выполняется над значением типа any, переменная в default также имеет тип any. Эта ветка означает отсутствие совпадения с перечисленными case, но не превращает значение в автоматически выведенный конкретный тип.

2. Дополнительный вопрос: что произойдёт со статическим типом переменной в case, содержащем два конкретных типа?

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

3. Дополнительный вопрос: проверяет ли type switch методы статического типа исходной переменной при выборе конкретного case?

Нет. Совпадение конкретного case определяется динамическим типом значения, хранящегося в интерфейсе. Статический тип исходного выражения ограничивает возможность самого type switch, но после успешного совпадения с конкретным типом переменная ветки получает тип этого case и использует его методный набор.