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

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

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

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

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

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

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

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

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

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

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

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

Явная квалификация устраняет неоднозначность:

package main

type Left struct{ ID int }
type Right struct{ ID int }
type Item struct {
    Left
    Right
}

func main() {
    var x Item
    x.Left.ID = 1
    x.Right.ID = 2
}

В этом примере обращение x.ID недопустимо, потому что кандидаты Left.ID и Right.ID находятся на одинаковой глубине. Обращения x.Left.ID и x.Right.ID однозначны.

Прямое поле внешней структуры имеет более высокий приоритет, чем продвигаемые поля. Поэтому объявление ID внутри Item сделало бы x.ID ссылкой на это поле, но доступ к x.Left.ID и x.Right.ID всё равно остался бы возможен.

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

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

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

В DTO для аудита команда встроила два типа: один описывает идентификатор пользователя, другой — идентификатор организации. Оба типа содержали поле ID, и после этого обращение к общему record.ID перестало компилироваться.

Рассматривались варианты:

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

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

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

1. Что произойдёт, если одно поле находится непосредственно во внешней структуре, а другое — во встроенном типе?

Победит поле внешней структуры, поскольку оно находится на меньшей глубине. Встроенное поле не удаляется и остаётся доступным через явный путь, например через имя встроенного типа.

Это затенение действует только для короткого селектора. Оно не означает, что внутреннее поле переименовано или заменено: код всё ещё может обратиться к нему явно.

2. Всегда ли одинаковые имена на разных уровнях приводят к ошибке компиляции?

Нет. Ошибка возникает, когда несколько кандидатов находятся на одной минимальной глубине. Если один кандидат ближе, он выбирается, а более глубокий кандидат затеняется.

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

3. Может ли обращение к продвигаемому полю привести к панике во время выполнения?

Да, если путь к нему проходит через встроенное поле-указатель со значением nil. Компилятор может считать селектор корректным, но при фактическом разыменовании указателя программа получит панику.

Поэтому при работе с опционально заполненными встроенными указателями нужно заранее гарантировать их инициализацию либо обращаться к ним явно и проверять на nil. Само отсутствие конфликта имён не защищает от проблемы времени выполнения.