Структурная типизация: форма — единственное, что сравнивает проверщик

Имена не важны, важны члены

Зачем это знать? Когда вы понимаете, что TypeScript проверяет форму, а не имя, вы перестаёте писать лишние приведения и начинаете проектировать типы, которые естественно компонуются через границы модулей.

Большинство старых типизированных языков номинальны: значение типа Point является Point, только если оно было объявлено таковым. TypeScript структурен (это часто называют «утиной типизацией»: если ходит как утка…). Проверщик сравнивает набор членов, требуемых целью, с тем, что предоставляет источник.

interface Point { x: number; y: number }
interface Vector2D { x: number; y: number }

function length(p: Point): number {
  return Math.hypot(p.x, p.y);
}

const v: Vector2D = { x: 3, y: 4 };
length(v); // ✅ компилируется — у Vector2D есть x и y, значит он по форме и ЕСТЬ Point
//     ^? (parameter) p: Point  — но Vector2D ему удовлетворяет

Point и Vector2D объявлены независимо, не связаны через extends, живут в разных файлах — и всё равно взаимозаменяемы. На значении нет никакого клейма Point во время выполнения; TypeScript полностью стирает типы. Единственный вопрос проверщика: есть ли у источника хотя бы те члены, которых требует цель, с совместимыми типами?

Лишние члены в этом направлении допустимы — у источника может быть больше, чем нужно цели:

const labelled = { x: 1, y: 2, label: "origin" };
length(labelled); // ✅ лишнее `label` игнорируется — x и y по-прежнему есть

В этом вся модель. Тип — это ограничение на форму, а не клуб, в который надо быть принятым.

Единственное место, где он ведёт себя номинально: проверка лишних свойств

Если бы структурная типизация всегда игнорировала лишние свойства, вот это бы компилировалось — а оно нет:

interface Options { width: number; height: number }

function configure(o: Options) { /* ... */ }

configure({ width: 100, height: 50, widht: 10 });
// Error: Object literal may only specify known properties,
//        and 'widht' does not exist in type 'Options'. Did you mean 'width'?

Эта опечатка widht иначе была бы тихо проглочена как безобидное лишнее свойство. Чтобы ловить ровно этот класс ошибок, TypeScript запускает проверку лишних свойств для свежих объектных литералов, присваиваемых напрямую типизированной цели. Литерал «свеж» в момент написания; присвоение его в типизированное место запускает более строгую проверку.

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

const opts = { width: 100, height: 50, widht: 10 };
configure(opts); // ✅ ошибки нет — `opts` это расширенная переменная, а не свежий литерал
//        ^? widht: number — просто лишний, структурно игнорируемый член

Лишние свойства можно разрешить явно через индексную сигнатуру ([key: string]: unknown) или приведением, но дефолт-ловец опечаток обычно — то, что вам нужно.

Функции тоже структурны

Совместимость распространяется и на функции — и тут она тоньше (полные правила вариантности — в юните 03). Функция совместима с другой, если её можно вызвать всюду, где ожидается цель. Главный сюрприз: функция, игнорирующая параметры, подходит туда, где нужна функция с параметрами.

type Handler = (event: { type: string; x: number }) => void;

const log: Handler = () => console.log("clicked"); // ✅ игнорировать аргумент нормально
const partial: Handler = (e: { type: string }) => {}; // ✅ просит меньше, чем ему дают

Обработчик, которому нужно меньше свойств, чем поставляет вызывающий, безопасен — вызывающий передаёт более богатый объект, обработчик читает подмножество. Заглянем вперёд: это направление «нужно меньше, получаю больше» — суть вариантности, которую мы разберём с дженериками в юните 03.

Возвращаем номинальную безопасность намеренно: брендированные типы

У структурной типизации есть реальная цена: UserId и OrderId, оба string, свободно взаимозаменяемы — так что можно передать id заказа туда, где ждали id пользователя, и проверщик промолчит.

type UserId = string;
type OrderId = string;

function loadUser(id: UserId) { /* ... */ }
const order: OrderId = "ord_42";
loadUser(order); // ✅ компилируется — но это настоящий баг

Команды возвращают номинальную безопасность через брендированный тип: пересекают примитив с фантомным маркером, существующим только в системе типов.

type UserId = string & { readonly __brand: "UserId" };
type OrderId = string & { readonly __brand: "OrderId" };

function asUserId(s: string): UserId {
  return s as UserId; // бренд ставится один раз, на доверенной границе
}

function loadUser(id: UserId) { /* ... */ }

const order = "ord_42" as OrderId;
loadUser(order);
// Error: Argument of type 'OrderId' is not assignable to parameter of type 'UserId'.
//   Type 'OrderId' is not assignable to type '{ readonly __brand: "UserId"; }'.

Поле __brand никогда не существует во время выполнения (вы лишь приводите к нему), но структурно у UserId и OrderId теперь разные литеральные типы __brand, поэтому проверщик отклоняет их смешивание. Команды тянутся к этому для типов id, денег/единиц, проверенных-против-сырых строк — везде, где обычный примитив несёт опасную семантику, которую структурная типизация охотно бы проигнорировала.