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

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

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

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

До появления обобщений повторно используемый код часто строили на interface{} и проверках динамического типа. Это давало гибкость, но переносило часть ошибок с этапа компиляции на время выполнения.

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

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

Параметр T может быть ограничен интерфейсом, но это не превращает выражение типа T в интерфейсное значение, пригодное для утверждения типа. Ограничение задаёт допустимые типы и доступные операции, а не предоставляет runtime-контейнер с динамическим типом.

Если пытаться использовать assertion напрямую, код не скомпилируется. Если бездумно преобразовывать любое значение к any, можно скрыть ошибку проектирования: проверка станет динамической, а часть преимуществ статической типизации будет потеряна.

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

Сначала значение параметрического типа преобразуют в интерфейсное значение, обычно в any. Затем assertion извлекает значение, если его динамический тип совместим с проверяемым типом.

package main

import "fmt"

func inspect[T any](v T) {
	// v.(string) // ошибка: assertion над параметром типа запрещена
	s, ok := any(v).(string)
	fmt.Println(s, ok)
}

func main() {
	inspect("go")
	inspect(42)
}

Для строки assertion успешен, для числа возвращается ok == false. Сам параметр v остаётся значением типа T; успешная проверка не меняет тип параметра, а только даёт отдельное значение типа string в переменной s.

Даже ограничение интерфейсом не меняет правило: оно разрешает вызывать методы, перечисленные в ограничении, но не разрешает assertion непосредственно над T. Преобразование к any допустимо, однако это сознательный переход от статической работы с ограничением к проверке конкретного runtime-типа.

Проверка с формой value, ok := ... безопасна: при несовпадении типов программа продолжает работу. Форма с одним результатом вызывает панику при неуспехе, поэтому её применяют только при гарантированном типе или после предварительной проверки.

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

В универсальном обработчике событий параметр T обычно обрабатывается через методы ограничения. Но для одного специального типа, например строки, требуется отдельное форматирование.

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

Практичный компромисс — преобразовать значение к any, выполнить безопасную assertion для действительно особого случая, а остальные значения обрабатывать через общий путь. Такой подход сохраняет типобезопасную сигнатуру функции, но ограничивает динамическую часть одним явно обозначенным местом.

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

Делает ли интерфейсное ограничение параметр типа пригодным для assertion?

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

Да. Интерфейсное значение получает динамический тип фактически переданного значения. Поэтому для T, инстанцированного строкой, assertion к string успешна, а для T, инстанцированного числом, — нет. Преобразование не превращает значение в строку и не заставляет assertion использовать ограничение вместо фактического типа.
Меняет ли успешная assertion тип параметра T внутри функции?

Нет. Она создаёт новое значение с типом, указанным в assertion, и не переопределяет T. Остальной код продолжает видеть исходный параметрический тип, поэтому методы и операции для него определяются прежним ограничением, а не результатом конкретной проверки.