Что есть

• Данные и поведение отдельно: struct хранит состояние, методы объявляются на уровне пакета с указанием receiver'а. Метод можно добавить любому именованному типу своего пакета, включая type Celsius float64.
• Инкапсуляция на уровне пакета: регистр первой буквы. Внутри пакета видно всё.
• Полиморфизм: интерфейсы. Реализация неявная: методы совпали, тип подходит.
• Композиция: встраивание типов с продвижением методов.

Чего нет и чем заменено

Почему авторы отказались от наследования

1. Хрупкий базовый класс. Поправил родителя, и наследники сломались, причём неочевидно; в глубокой иерархии ещё попробуй проследить вызов.
2. Наследование - самая сильная связность. Подкласс зависит от реализации родителя, а не от одного контракта.
3. Ромб. Множественное наследование заставляет придумывать правила разрешения конфликтов; Go объявляет неоднозначность ошибкой компиляции.
4. Композиция гибче. Поведение меняешь подстановкой зависимости, а не переопределением метода.

type Animal struct {
    Name string
}
func (a Animal) Speak() string    { return a.Name + " звучит" }
func (a Animal) Describe() string { return "Я " + a.Speak() }

type Dog struct {
    Animal            // имя поля = имя типа
    Breed string
}
func (d Dog) Speak() string { return d.Name + " гавкает" }   // перекрытие

d := Dog{Animal{"Рекс"}, "лабрадор"}
d.Name          // сахар для d.Animal.Name
d.Speak()       // "Рекс гавкает"  - метод Dog закрыл продвинутый
d.Animal.Speak()// "Рекс звучит"   - явный доступ
d.Describe()    // "Я Рекс звучит", а не "гавкает"

Правила разрешения имени

1. Побеждает меньшая глубина. Метод внешнего типа закрывает продвинутый с глубины 1 и ниже.
2. Ничья на одной глубине - ошибка ambiguous selector, но только в момент обращения к имени. Просто встроить два типа с одинаковым методом можно.
3. Встраивать можно T, *T и интерфейс. Method set зависит от того, что встроено: у struct{ T } продвигаются value-методы T в method set структуры и все методы в method set указателя на неё; у struct{ *T } продвигаются все методы T в оба набора.

Чем это НЕ является

Наследованием. Внутри Animal.Describe receiver имеет тип Animal, и о существовании Dog он ничего не знает: вызов a.Speak() статически связан с Animal.Speak. В Java здесь сработал бы полиморфизм. Это самая частая ошибка приходящих из ООП-языков: пишут «шаблонный метод» через встраивание и получают тихо неправильное поведение.

Где встраивание правда полезно

// 1) Декоратор: встроили интерфейс, перекрыли один метод
type LoggingStore struct {
    Storage                    // остальные методы делегируются автоматически
    log *slog.Logger
}
func (s LoggingStore) Get(id string) (User, error) {
    s.log.Info("get", "id", id)
    return s.Storage.Get(id)
}

// 2) Расширяем чужой тип
type Request struct {
    *http.Request
    TraceID string
}

// 3) Общие поля моделей
type Base struct {
    ID        int64
    CreatedAt time.Time
}
type User struct {
    Base
    Email string
}

type eface struct {
    _type *_type
    data  unsafe.Pointer
}
type iface struct {
    tab  *itab
    data unsafe.Pointer
}

type itab struct {
    inter *interfacetype   // какой интерфейс
    _type *_type           // какой конкретный тип
    hash  uint32           // копия _type.hash, ускоряет type switch
    fun   [1]uintptr       // переменной длины: адреса методов
}

Как происходит вызов

1. Берём i.tab.
2. Берём tab.fun[k], где k - индекс метода, известный на этапе компиляции (методы в itab отсортированы по имени).
3. Вызываем по этому адресу, передав i.data как receiver.

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

Откуда берётся itab

Для статически известной пары (интерфейс, тип) itab создаёт компилятор, и таблица лежит прямо в бинаре. Для динамических случаев (type assertion к интерфейсу) он создаётся в рантайме и кэшируется в глобальной хеш-таблице: по одному на пару, навсегда.

Что с данными

data - всегда указатель. Поэтому, когда значение упаковывают в интерфейс, его обычно приходится уводить в кучу (escape). Исключения:

• значение само по себе указатель (*T, map, chan, func) - кладётся напрямую;
• маленькие целые 0..255 берутся из runtime.staticuint64s;
• nil-интерфейс - оба слова нулевые.

var x any = 42       // константа: лежит в read-only данных, аллокации нет
var y any = &s       // указатель кладётся в data напрямую, без аллокации
var z any            // eface{nil, nil}
fmt.Println(unsafe.Sizeof(x))   // 16 - два слова

type MyError struct {
    Code int
}
func (e *MyError) Error() string { return "boom" }

func do() error {
    var e *MyError        // e == nil
    return e              // упаковали (*MyError)(nil) в интерфейс error
}

err := do()
fmt.Println(err == nil)   // false
fmt.Println(err)          // boom - Error() спокойно отработал на nil-получателе,
                          // потому что не трогает поля e. Если бы трогал (e.Code),
                          // он бы паниковал, fmt перехватил бы панику и напечатал <nil>
fmt.Printf("%T\n", err)   // *main.MyError
if err != nil { /* сюда попадём */ }

В интерфейсе лежит {tab: itab(error, *MyError), data: nil}. Сравнение err == nil проверяет оба слова, и первое непустое. Печатается <nil>, потому что Error() на nil-получателе паникует, а fmt ловит эту панику и, увидев нулевой указатель, подставляет <nil>. Отсюда фирменный симптом: в логе написано nil, а ветка ошибки выполняется.

Три источника в реальном коде

1. Функция возвращает конкретный тип ошибки и результат присваивают в error: func parse() *ParseError → var err error = parse().
2. Именованное возвращаемое значение конкретного типа плюс defer, который его трогает.
3. Поле-интерфейс в структуре, куда кладут указатель, который может быть nil (частый случай в конфигурациях и опциях).

Как правильно

// 1) Возвращать литеральный nil на успешном пути
func do() error {
    if bad { return &MyError{500} }
    return nil
}

// 2) Если переменная нужна, проверить перед возвратом
func do2() error {
    var e *MyError
    if bad { e = &MyError{500} }
    if e == nil { return nil }
    return e
}

// 3) Не возвращать из функций конкретный тип ошибки
// func parse() (*Result, *ParseError)   // плохо
func parse() (*Result, error)            // хорошо

Что даёт неявная реализация

• Интерфейс можно написать после реализации, в том числе для чужого пакета, который ты не можешь менять. *os.File реализует твой type Syncer interface{ Sync() error }, ничего об этом не зная.
• Реализация не зависит от абстракции. Пакет postgres не импортирует пакет service, где объявлен интерфейс. Это инверсия зависимостей без boilerplate.
• Интерфейсы получаются маленькими, потому что их пишет потребитель под свою нужду.
• Нет циклических импортов вида «абстракция ↔ реализация».

Цена

• Опечатка в сигнатуре не даёт понятной ошибки «не реализует» рядом с типом. Всплывёт она в месте присваивания, иногда в другом пакете.
• Совпадение имён случайно: тип может «реализовать» интерфейс, не имея такого намерения (в Go это встречается редко, но, например, метод String() нечаянно делает тип fmt.Stringer и меняет вывод в логах).
• Инструментам сложнее показать «кто реализует этот интерфейс», хотя gopls умеет.

Проверка на этапе компиляции

var _ io.Writer      = (*MyWriter)(nil)   // указатель реализует
var _ error          = (*MyError)(nil)
var _ Storage        = (*PostgresStore)(nil)
var _ fmt.Stringer   = Weekday(0)         // для value receiver - значение
var _ sort.Interface = ByAge(nil)         // для слайс-типа

_ - пустой идентификатор, значение никуда не сохраняется и в бинарь не попадает. (*T)(nil) - типизированный nil, аллокации нет. Работает только проверка типов. Сообщение при ошибке максимально конкретное:

cannot use (*MyWriter)(nil) as io.Writer value in variable declaration:
	*MyWriter does not implement io.Writer (missing method Write)

Где оправдан

• Форматирование и логирование: fmt.Println(a ...any), slog.Info(msg, args ...any).
• Сериализация: json.Unmarshal(data, v any) - тип известен только вызывающему.
• Хранилища общего назначения: sync.Map, context.WithValue.
• Плагины и динамические данные: разбор конфигов неизвестной схемы.

Чем плох

1. Нет проверки типов. Ошибка переезжает из компиляции в рантайм: паника при assertion или тихо неверная ветка switch.
2. Аллокации. Упаковка значения в интерфейс обычно уводит его в кучу.
3. Читаемость. Сигнатура func Process(v any) any не говорит ничего.
4. Заражает код. Один any в глубине заставляет писать assertion'ы на всех уровнях выше.
5. Ключи мап и сравнения начинают паниковать на не-comparable типах.

Чем заменить

// Было (до 1.18):
func Max(a, b any) any { /* type switch, паники, боль */ }

// Стало - дженерики:
func Max[T cmp.Ordered](a, b T) T { if a > b { return a }; return b }

// Было: контейнер на any
type Stack struct {
    items []any
}
// Стало:
type Stack[T any] struct {
    items []T
}

// Было: фиксированный набор вариантов через any
func Handle(v any) { switch v.(type) { case A: ; case B: } }
// Стало: интерфейс с методом - полиморфизм вместо switch
type Handler interface{ Handle() }

var i any = "привет"

s := i.(string)              // "привет"
// n := i.(int)              // panic: interface conversion: interface {} is string, not int

s, ok := i.(string)          // "привет", true - безопасно
n, ok := i.(int)             // 0, false - паники нет

// Assertion к интерфейсу проверяет, реализует ли динамический тип ещё и его
if st, ok := i.(fmt.Stringer); ok { fmt.Println(st.String()) }
                             // ok == false: у string нет метода String(), ничего не напечатается
if rc, ok := r.(io.ReadCloser); ok { defer rc.Close() }

Type switch

switch v := i.(type) {
case nil:
    // только настоящий nil-интерфейс, typed nil сюда не попадёт
case int:
    fmt.Println(v + 1)          // v имеет тип int
case string:
    fmt.Println(len(v))         // v имеет тип string
case []byte, [][]byte:
    fmt.Println(v)              // а тут v имеет тип any
case error:
    fmt.Println(v.Error())      // можно матчить и на интерфейсы
default:
    fmt.Printf("%T\n", v)
}

Что важно знать

• Assertion работает только на интерфейсных значениях. x.(T) для конкретного типа - ошибка компиляции. Это не то же самое, что конверсия T(x).
• Порядок case важен, если среди них есть интерфейсы: первый подходящий выигрывает. case error перед case *MyError перехватит всё.
• Несколько типов в одном case - v остаётся интерфейсом.
• switch i.(type) без присваивания тоже валиден, если значение не нужно.
• Стоимость: сравнение указателей на _type плюс, для assertion к интерфейсу, поиск и создание itab. Дёшево, но не бесплатно: в горячем цикле от assertion лучше избавиться архитектурно.

Где применяется в реальном коде

// 1) Опциональные интерфейсы, идиома стандартной библиотеки
func Copy(dst io.Writer, src io.Reader) (int64, error) {
    if wt, ok := src.(io.WriterTo); ok { return wt.WriteTo(dst) }  // быстрый путь
    if rf, ok := dst.(io.ReaderFrom); ok { return rf.ReadFrom(src) }
    // медленный путь через буфер
}

// 2) Разбор ошибок, но лучше errors.As
var pathErr *fs.PathError
if errors.As(err, &pathErr) { fmt.Println(pathErr.Path) }   // умеет разворачивать цепочку
if pe, ok := err.(*fs.PathError); ok { }                    // не умеет - только верхний уровень

// 3) Разбор произвольного JSON
var data any
json.Unmarshal(b, &data)
m := data.(map[string]any)      // числа будут float64
n := m["count"].(float64)

type T struct {
    n int
}
func (t T)  Val() {}
func (t *T) Ptr() {}

// method set T  = { Val }
// method set *T = { Val, Ptr }

type I interface{ Ptr() }

var t T
t.Ptr()              // компилируется: сахар для (&t).Ptr(), ведь t адресуема
// var i I = t       // ошибка: T does not implement I (method Ptr has pointer receiver)
var i I = &t         // ОК

Почему запрет именно на интерфейс, а не на вызов

Вызов t.Ptr() компилятор разрешает, потому что видит переменную и может взять её адрес. А когда значение кладут в интерфейс, оно копируется в кучу, и эта копия не имеет стабильного имени. Разреши Go такое, метод с pointer receiver менял бы копию внутри интерфейса, а не исходную переменную, и мутация терялась бы молча. Go предпочёл ошибку компиляции.

Где ещё срабатывает адресуемость

m := map[string]T{"a": {}}
// m["a"].Ptr()          // ошибка: cannot call pointer method Ptr on T
v := m["a"]; v.Ptr()     // так - через переменную

sl := []T{{}}
sl[0].Ptr()              // ОК: элемент слайса адресуем

// Обратное направление работает всегда:
p := &T{}
p.Val()                  // сахар для (*p).Val()

type Counter struct {
    n int
}
func (c Counter) IncBad() { c.n++ }     // меняет копию, инкремент теряется
func (c *Counter) Inc()   { c.n++ }     // правильно

c := Counter{}
c.IncBad(); fmt.Println(c.n)   // 0
c.Inc();    fmt.Println(c.n)   // 1

// Мьютекс + value receiver = тихий баг: каждый вызов блокирует свою копию
type Bad struct {
    mu sync.Mutex
    n  int
}
func (b Bad) Lock() { b.mu.Lock() }     // go vet: passes lock by value

Аргументы «за value», которые часто забывают

• Копия иногда дешевле, чем разыменование. Для структуры из одного-двух слов копия остаётся в регистрах, а указатель добавляет косвенность и может увести объект в кучу (escape analysis).
• Безопасность. Value receiver гарантирует, что метод не изменит получателя. Для конкурентного кода это ценно само по себе.
• Method set шире. С value receiver и T, и *T удовлетворяют интерфейсу; с pointer receiver - только *T.

Про «копия дорогая» - где граница

Практический порог обычно называют в районе нескольких машинных слов (примерно до 4–5 полей скалярных типов). Но реальный ответ - померить: escape analysis может свести разницу к нулю или, наоборот, указатель заставит объект уехать в кучу и добавит работы GC. Смотри через go build -gcflags='-m' и бенчмарк.

package store

type User struct {
    ID   int      // экспортировано
    name string   // нет - видно только внутри пакета store
}
func New() *User            { return &User{} }   // экспортировано
func (u *User) Name() string{ return u.name }    // геттер
func (u *User) validate() error { return nil }   // приватный метод

// Внутри пакета видно всё, включая приватные поля чужих типов этого же пакета:
func eq(a, b User) bool { return a.name == b.name }   // ок

Что важно знать

• Гранулярность - пакет, а не файл и не тип. Два файла одного пакета видят приватные идентификаторы друг друга.
• Рефлексия видит только экспортированные поля. json.Marshal молча пропустит name, Unmarshal не заполнит. reflect.Value.Field(i).Interface() для приватного поля паникует.
• Регистр смотрится по первой руне, и это Unicode: Имя - экспортировано (заглавная кириллическая), _x и имя - нет.
• Приватный тип с публичными методами - законно и полезно: функция возвращает интерфейс, конкретный тип наружу не виден.
• internal/ - второй механизм: пакет внутри a/b/internal/c импортируется только из поддерева a/b. Экспортированные имена там всё равно недоступны снаружи.

Идиомы вокруг видимости

// 1) Приватное поле + функциональные опции вместо публичных полей
type Server struct {
    timeout time.Duration
}
type Option func(*Server)
func WithTimeout(d time.Duration) Option { return func(s *Server){ s.timeout = d } }
func NewServer(opts ...Option) *Server { /* ... */ }

// 2) Приватный тип, публичный интерфейс
type storage struct {
    db *sql.DB
}
func NewStorage(db *sql.DB) Storage { return &storage{db} }  // тип наружу не виден

// 3) Запрет на литерал без имён полей - приватное поле-маркер: новые поля не сломают вызывающих
type Config struct {
    Name string
    _    struct{}   // литерал Config{"x"} без имён полей не скомпилируется вне пакета
}

Почему принимать интерфейс

• Функция объявляет минимум требований: io.Writer вместо *os.File. В тесте подставишь bytes.Buffer, в проде туда пойдёт файл, сокет или gzip-обёртка.
• Пропадает зависимость от конкретного пакета, а значит, легче ломать циклы импортов.
• Интерфейс документирует контракт: видно, что именно функции нужно.

Почему возвращать структуру

• Вызывающий видит все методы и поля и сам решает, какая абстракция ему нужна. Вернув интерфейс, ты навязываешь свой выбор и скрываешь остальное.
• Новый метод у конкретного типа ничего не ломает. Новый метод в интерфейсе ломает все реализации.
• Возврат интерфейса - прямой путь к typed nil, если внутри вернуть (*T)(nil).
• Конкретный тип позволяет компилятору инлайнить и девиртуализировать вызовы.

// Хорошо
func NewStore(db *sql.DB) *Store { return &Store{db: db} }
func Save(w io.Writer, u User) error { return json.NewEncoder(w).Encode(u) }

// Плохо
func NewStore2(db *sql.DB) Storage { return &Store{db: db} }   // скрыли тип
func Save2(f *os.File, u User) error { }                       // прибили к файлу

Когда правило нарушают осознанно

1. Фабрика с несколькими реализациями: func NewCache(cfg) Cache возвращает то Redis, то in-memory, так что тип известен только в рантайме.
2. Конкретный тип принципиально приватный - тогда наружу отдают интерфейс.
3. Стандартная библиотека так делает: net.Listen отдаёт net.Listener, sql.DB.Begin - *sql.Tx (тут как раз структура). То есть даже stdlib выбирает по ситуации.

// package service - потребитель объявляет ровно то, что нужно ему
type UserGetter interface {
    GetUser(ctx context.Context, id int64) (User, error)
}
type Service struct {
    users UserGetter
}
func New(u UserGetter) *Service { return &Service{users: u} }

// package postgres - про service не знает вообще
type Store struct {
    db *sql.DB
}
func (s *Store) GetUser(ctx context.Context, id int64) (User, error) { /* ... */ }
func (s *Store) SaveUser(...) error { /* ... */ }

// main.go - единственное место, где они встречаются
svc := service.New(postgres.New(db))

Что это даёт

1. Правильное направление зависимостей. Доменный пакет не импортирует пакет с инфраструктурой. Это Dependency Inversion Principle, только бесплатный: реализация-то структурная.
2. Маленькие интерфейсы. Потребителю нужен один метод, он и объявит интерфейс с одним методом. «The bigger the interface, the weaker the abstraction» (Роб Пайк).
3. Простые моки. Мок на один метод пишется руками за минуту; мок на 20-методовый интерфейс генерируют и никто не читает.
4. Нет циклических импортов между слоем абстракции и слоем реализации.
5. Реализацию можно свободно расширять: новый метод у *Store ничего не ломает, потому что интерфейсы объявлены отдельно.

Когда интерфейс всё-таки живёт у реализации

• Контракт для внешнего мира: io.Reader, error, http.Handler, sort.Interface - это интерфейсы, которые реализуют чужие типы, и объявить их у каждого потребителя было бы абсурдом.
• Плагинная архитектура: пакет определяет точку расширения, и десятки внешних реализаций подключаются к ней.
• Несколько реализаций внутри одного пакета, между которыми переключаются конфигом.

var a any = 1
var b any = 1
var c any = int64(1)
fmt.Println(a == b)   // true
fmt.Println(a == c)   // false - типы разные, значения даже не сравниваются

var s1 any = []int{1}
var s2 any = []int{1}
// s1 == s2           // panic: runtime error: comparing uncomparable type []int

type P struct {
    X int
}
type B struct {
    S []int
}
var p1, p2 any = P{1}, P{1}
fmt.Println(p1 == p2) // true - структура comparable
var b1, b2 any = B{}, B{}
// b1 == b2           // panic: runtime error: comparing uncomparable type main.B

Почему компилятор это не ловит

Потому что статически он видит только интерфейсный тип. Что окажется внутри, выяснится в рантайме. Сравнение двух конкретных слайсов (s1 == s2 для []int) компилятор запрещает сразу, а сравнение интерфейсов запретить не может.

Где всплывает неожиданно

• map[any]V - при вставке ключа с не-comparable типом: hash of unhashable type.
• errors.Is - внутри сравнивает через ==. Ошибка-структура со слайсом внутри уронит проверку. Поэтому кастомные ошибки делают указателями или реализуют метод Is(error) bool.
• Сравнение в тестах: if got != want для any. Нужен reflect.DeepEqual или go-cmp.
• slices.Contains для []any, sync.Map с такими ключами.

Как сравнивать безопасно

// 1) Сначала проверить сравнимость
if reflect.TypeOf(a).Comparable() { _ = a == b }

// 2) Глубокое сравнение
reflect.DeepEqual(a, b)          // медленно, но не паникует
cmp.Equal(a, b)                  // go-cmp: стандарт в тестах, diff покажет cmp.Diff

// 3) В дженериках: констрейнт comparable
func Index[T comparable](s []T, v T) int { /* компилятор проверит статически */ }

Три закона рефлексии

1. Из интерфейсного значения можно получить reflect.Value.
2. Из reflect.Value можно вернуться в интерфейс - .Interface().
3. Чтобы менять значение, оно должно быть settable: получено через указатель (reflect.ValueOf(&x).Elem()) и относиться к экспортированному полю.

type User struct {
    ID   int    `json:"id" db:"user_id"`
    Name string `json:"name"`
    age  int    // приватное: рефлексия видит, но не может ни прочитать через
}               // Interface(), ни записать

u := User{1, "Аня", 30}
t, v := reflect.TypeOf(u), reflect.ValueOf(u)
for i := 0; i < t.NumField(); i++ {
    f := t.Field(i)
    fmt.Println(f.Name, f.Type, f.Tag.Get("db"), f.IsExported())
}
// ID int user_id true
// Name string  true
// age int  false

p := reflect.ValueOf(&u).Elem()
p.FieldByName("Name").SetString("Боря")   // ок - settable и экспортировано, u == {1 Боря 30}
// v.FieldByName("Name").SetString("X")
//   panic: reflect: reflect.Value.SetString using unaddressable value
// p.FieldByName("age").SetInt(1)
//   panic: reflect: reflect.Value.SetInt using value obtained using unexported field

Цена

Где применяется

• encoding/json, encoding/xml, gopkg.in/yaml - маршалинг по тегам структур.
• database/sql - Scan в произвольные указатели; ORM целиком.
• text/template, html/template - доступ к полям по имени.
• fmt - %v, %+v, %#v.
• sort.Slice - reflect.Swapper; reflect.DeepEqual; валидаторы, DI-контейнеры, мок-генераторы.

Когда не надо

В горячем пути и там, где типы известны. С Go 1.18 большую часть задач, ради которых раньше брали рефлексию (контейнеры, утилиты над коллекциями), закрывают дженерики: статически и без накладных расходов. Если рефлексия нужна ради сериализации и стала узким местом, переходят на кодогенерацию: easyjson, protobuf, sqlc, go generate.